HTML 5: common practice vs. good practice
By the way it’s documenting current browser practices, the HTML 5 specification may inadvertently be encouraging bad web development practices.
One of the big reasons for a lot of the junk that’s currently planned in HTML 5 is that new user agents developed in the future should be able to reasonably handle preexisting content on the Web. The HTML 5 specification will describe what browsers are currently doing with a lot of content which maybe wasn’t considered part of a standard before now, and future web browsers would only have to follow the HTML 5 specification in order to handle much of the legacy content on the Web.
I do recognize the need for this. However, I don’t think this idea is being delivered properly. If we aren’t careful, web developers will end up looking at things like the font and embed elements and say, “Well hey, they’re here, they’re standard, why not use them?” I don’t care how many times you say in the specification that authors shouldn’t use them, if people receive even the slightest hint that they’re considered standard, they will.
What I feel needs to happen is a much more clear and physical separation between the parts of the standard meant only for browsers rendering legacy content and the parts meant for web developers following good practices. I’m not sure if I’d go as far as publishing two separate and complimentary standards, but I feel that the legacy stuff should at least be isolated into its own major section of the specification with a fat heading something along the lines of “Crap that browsers support for legacy reasons”. None of this legacy content should pass a webpage validation, and it should be made perfectly clear that use of those features on new webpages is a violation of the standard.
But I somehow have a feeling that this won’t happen. Even the current Web Applications 1.0 specification says that WYSIWYG editors are allowed to use font tags in their output. It mentions nothing to dissuade the use of the embed element even though common uses like Flash can be done purely through an object element in all of today’s major browsers. The specification generally carries an attitude of “if it’s out there right now, it’s valid” which I think will end up only encouraging bad practices and resulting in a lot more problems in the future.
April 30th, 2007 at 10:53 UTC
I agree, but I’m not sure what can be done about this now. Seems like all the major players think this is the way forwards…
Posted using Mozilla Firefox 2.0.0.3 on Windows.
May 4th, 2007 at 09:09 UTC
The existence of deprecated tags such as font & embed does rather feel like legalising theft to reduce crime rates.
Personally, I think backwards compatibility needs broken. When something’s bent into shape to serve a different purpose (such as the semantic change to existing elements) it isn’t as effective as a start-from-scratch solution.
HTML needs to lose some legacy.
Posted using Mozilla Firefox 2.0.0.3 on Windows.
May 5th, 2007 at 07:03 UTC
Well said, I fully agree. I don’t understand why so many seem so opposed to making a clear distinction between what developers may use and what browsers should understand.
Posted using Safari 419.3 on Macintosh.
May 5th, 2007 at 11:31 UTC
What I think a lot of folks apparently aren’t understanding about HTML5 is that it’s:
A) Describing what an HTM5 conformant User Agent must be able to do, which is render HTML5-conformant documents, and also describe how the UA should handle legacy content.
B) Describe what an HTML5 conformant DOCUMENT is. Try actually sending some of your W3C-Validated docs through the X(HTML5) Conformance Checker and you’ll find it’s actually a lot stricter than you might expect.
Just because an HTML5 UA must support tag soup and deprecated elements (or 95+% of the existing web would be “broken”), that doesn’t mean that these things are going to be allowed in HTML5-conforming DOCUMENTS.
AFAIK, the only currently deprecated element allowed in an HTML5-conformant document is MENU. HTML5 UA’s on the other hand must be able to render ALL deprecated elements.
Seriously, how many of you would use a browser that wouldn’t render deprecated elements or tag soup (i.e the vast majority of existing documents on the web)?
A large portion of the HTML5 WAI spec is devoted to standardizing how a User Agent calling itself HTML5-conformant must handle these existing documents…something that hasn’t really ever been done before in an HTML spec.
Unfortunately, it’s a bit difficult when reading the WA1 spec to understand at first what refers to HTML5-conformant documents and what refers to HTML5-conformant User Agents.
I know it’s taken me multiple readings and asking several questions on the whatwg IRC channel for it to sink in.
Posted using Mozilla Firefox 3.0a on Windows.
May 5th, 2007 at 12:16 UTC
Hmm…forgot about EMBED. Without having read the reasoning for allowing EMBED in HTML5-compliant documents (even if only allowed when wrapped within a FIGURE element), I have to say I’d tend to agree with you on this one. Of course UA’s should still support it.
FWIW, note that the FONT element exception for documents created by WSIWYG editors doesn’t allow most of the old attributes…only the STYLE attribute.
Posted using Mozilla Firefox 3.0a on Windows.