W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: HTML version issue summary?

From: David Hyatt <hyatt@apple.com>
Date: Tue, 24 Apr 2007 17:16:58 -0700
Message-Id: <C3B78230-3B2C-49A6-9A24-B767C32552E5@apple.com>
Cc: public-html@w3.org
To: Dan Connolly <connolly@w3.org>

Here is my opinion.

(1) I do not think it is realistic to expect IE to fold HTML5 into  
existing Web content.  We have had so many problems just with  
Dashboard in OS X with the new WebKit.  The widgets are coded with so  
many assumptions about the behavior of Tiger's WebKit that many  
seemingly harmless changes that we make have broken them.  The  
situation is so bad that we've even talked about keeping the old  
WebKit around and having Dashboard widgets opt in to the new WebKit  
through a flag in their plists.

Think about that for a second.  This is DASHBOARD: a small percentage  
of Web content on an OS with a small market share percentage.  We're  
talking about a tiny pocket of Web content here, and already we're  
having huge headaches trying to make sure we don't break these  
widgets too badly.

I can't even imagine the versioning problems IE will face if they  
change any of their existing HTML behavior.  It is simply naive and  
foolish to expect IE to be able to add these new features to existing  
content.  Anyone who proposes this has absolutely no concept of what  
it means to be backwards-compatible and to not break the Web.

Just because working with 95-99% of the Web is good enough for  
alternative browsers like Safari, Mozilla, and Opera does not mean it  
is good enough for IE.  Currently they work with 100%, and asking  
them to make breaking changes to deliberately be less compatible,  
even if that amounts to < 1% of the Web, is patently ridiculous.

(2) I think it's poor design not to include specific version numbers  
to identify which spec an author wrote the content for.  Even if we  
never use the version number for anything, even if alternative  
browsers support HTML5, even if the doctype says HTML3.2, etc., it's  
still good language design to identify the specific language  
version.  I would like the version string to be:

  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5.0//EN">

thus specifically identifying 5.0 in case we decide to do a 5.1, 5.2,  
etc..

(3) I think browsers should be allowed to support HTML5 without any  
opt-in switches if they choose to.  Obviously alternative browsers  
can more easily support HTML5 without requiring a 5.0 doctype or a  
specific opt-in mechanism, and the spec should not prohibit that.

(4) I think IE's opt-in should be independent of DOCTYPE until such  
time as they are confident that they have HTML5.0 fully implemented  
and supported.  Then one could imagine the doctype being used as the  
opt-in.

(5) I do not think the spec should attempt to say how browsers opt in  
to HTML5.  Microsoft should be allowed to design their own mechanism  
for this.

(6) I think XHTML is a red herring.  Realistically opt-in support for  
HTML5 is an IE problem, and we can cross the compound document bridge  
when Microsoft decides to add support for the XHTML MIME type.   
Everyone who does support XHTML will obviously just support HTML5  
features as part of XHTML support.  Let Microsoft decide how they  
want to opt in to an XHTML world when they implement support for it.   
It's not our business to try to tell them how they should do that.

(7) I think .innerHTML is a red herring.  All parsing happens in the  
context of some document, so knowledge of versions/opt-in will be  
present.  This happens today already with inline style attributes  
(where a browser has to know whether the fragment is in quirks/strict  
mode even when parsing in order to decide whether CSS will be lax or  
not).

dave
(hyatt@apple.com)

On Apr 24, 2007, at 3:47 PM, Dan Connolly wrote:

>
> In his message of Mon, 23 Apr 2007 13:10:47 -0700,
> David Hyatt says he has very different views
> from those of Ian Hickson on the topic of versioning.
>
> This topic is large enough that I'm reluctant to
> try to treat it as one issue (in
> my issue list scratchpad http://www.w3.org/html/wg/il16
> it sorta sits under "TAG liaison").
> But perhaps it's worth a shot.
>
> David, would you please offer a summary of the issue
> as you see it so far? I suppose others are welcome
> to offer summaries too, but I'm particularly
> interested in David's take.
>
> Ian's message of 18 Apr surveys a few points
> in the design space that led up to the choice
> of <!DOCTYPE html>. I recommend it to anyone
> who hasn't managed to read it so far.
> http://www.w3.org/mid/Pine.LNX. 
> 4.62.0704180913450.17772@dhalsim.dreamhost.com
>
> I think discussion of a version attribute is novel
> with respect to the designs summarized there.
>
> Syntax involving comments have also been
> mentioned. (Yes, it's ugly, but it still merits
> consideration.)
>
> I particularly appreciate the sort of test-driven
> approach to the thread in which that message appears...
>
> A Concrete Example for the HTML Versioning Debate
> http://www.w3.org/mid/ 
> da131fde0704172121j2fea8cf3va210f3412769f1b9@mail.gmail.com
>
> By Jeff Schiller's own admission, the example there is contrived.
> I'm very interested in examples that are not contrived; i.e
> examples where both sides of the issue grant that it's an
> interesting case to consider, though their opinions on how
> the case should be treated may differ. My favorite form of
> working group decision includes concrete test cases of this sort.
>
> I think it's useful for a summary to include discussion
> of design principles such as "Don't Break The Web" and
> others in the Compatibility section of the wiki topic.
>  http://esw.w3.org/topic/HTML/ProposedDesignPrinciples
>
> I'm also interested in any objective, testable requirements
> available in this design space. I think
> Chris Wilson's "Versioning and html[5]" essay includes
> some requirements involving deployed content, but I haven't
> been able to crystallize them in my mind.
> http://lists.w3.org/Archives/Public/public-html/2007Apr/0612.html
>
> Working in this sort of background justification would be very
> valuable, but if it's too much trouble, then don't bother.
>
> But please do tell us which designs you've considered and which
> ones you think are good ways to proceed.
>
>
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>
>
Received on Wednesday, 25 April 2007 00:17:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:43 UTC