Re: HTML version issue summary?

David Hyatt wrote:
> On Apr 24, 2007, at 7:43 PM, Matthew Raymond wrote:
>> David Hyatt wrote:
>>> You would still have to worry about older browser versions even when
>>> HTML5 support started to emerge.  If you only care about browsers
>>> that fully support HTML5, then you'd just use the HTML5 doctype/
>>> version and let versions of IE that haven't opted in using the
>>> doctype switch get your "older HTML4" version (along with older
>>> versions of Safari, Firefox, etc.)
>>
>>    That's not acceptable. It's the equivalent of opting into "really
>> standards mode", except that it only works for one browser version. If
>> other browser vendors reach a reasonable level of HTML5 support before
>> IE, all pages written for those browsers will have to use the IE  
>> opt-in switch to get the best rendering for HTML5 rendering available
>> in IE even if their pages work fine on other browsers.
> 
> And that's unacceptable why? As I said before, this is obviously  
> hypothetical anyway.  IE might only ship with HTML5 once MSFT could  
> safely use the version string.

   Microsoft can safely use <!DOCTYPE HTML> as a version switch for now,
and we can add versions later with a |version| attribute if we need to.
The problem I see is that future IE version will continue to tie things
like CSS and DOM/Javascript bugs to specific HTML versions and never
actually resolve those bugs for standards-compliant content of a
particular version. For instance, if I author an HTML 4.01 page right
now using the various table display modes in CSS 2.1, will any version
of Internet Explorer _EVER_ support that page correctly??? Or will I be
forced to reauthor the document for a new version of HTML? Why would I
want to perpetuate a situation where pages that were written for the
most recent standards at the time of authoring may never render or
function correctly in browsers produced by the largest browser vendor?

> And if they ship with their own form
> of opt-in and don't honor your HTML5 doctype, so what?

   The problem is that the switch doesn't really mean that the page is
standards compliant. It was standards compliant without the proprietary
switch. In fact, because the switch is proprietary, it may not even say
anything about "standards", so we end up with documents devoid of the
switch getting the wrong rendering and functionality, while documents
with the switch have markups that says something like this...

| <!--[hmode=5-R8]-->
| <html>

   ...Which tells you nothing if you don't know what it is, and may
provoke standards-trained-but-IE-ignorant developers to remove it.

> Older
> browsers wouldn't honor it either, so you'd obviously have to be  
> prepared to provide a useful rendering anyway.

   Netscape Navigator 4.x doesn't honor my CSS, but I don't pretend that
I'm okay with IE rendering my pages like NN4. And yes, I do check some
of my pages against NN4 to ensure that the page content remains
accessible in extreme legacy situations.

   Internet Explorer has unfortunately created a situation where HTML
versions are tied to rendering and functionality that are related more
to CSS and scripting than to the actual markup. Rather than promote this
by giving them a permanent version hook mechanism, we should be giving
them a mechanism that both allows pure standards-based documents to have
the best support available while allowing bug compatibility modes that
are clearly identified and specific to a user agent rather than a spec.

>>    A page written correctly for HTML5 that doesn't have an explicit
>> opt-in for a particular bug compatibility mode should be rendered with
>> the user agent's best attempt at HTML5 standards mode. Otherwise,  
>> people will be forced to use custom opt-ins (possibly multiple opt-ins)
>> just to get their page working on multiple browsers.
> 
> Possibly, yes.  Realistically we're only talking about IE though.

   The Dashboard example expressed earlier didn't give me that
impression. In theory, any widget-supporting environment could need
special opt-in bug compatibility modes.

Received on Wednesday, 25 April 2007 10:26:07 UTC