W3C home > Mailing lists > Public > public-html@w3.org > January 2009

Re: ISSUE-54: doctype-legacy-compat

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 16 Jan 2009 05:55:32 -0800
Cc: Jirka Kosek <jirka@kosek.cz>, HTML WG <public-html@w3.org>
Message-id: <26A53D19-5808-4EA3-91B0-03B3868C7DB5@apple.com>
To: Sam Ruby <rubys@us.ibm.com>

On Jan 16, 2009, at 4:14 AM, Sam Ruby wrote:

> Jirka Kosek <jirka@kosek.cz> wrote on 01/09/2009 04:53:21 AM:
> >
> > Sam Ruby wrote:
> >
> > > The suggestion was made that the name of this doctype be changed  
> from
> > > xslt-compat to legacy-compat.  Expressing support for this idea  
> were
> > > hsivonen, DanC, anne, gsnedders, smedero, and myself.  (Note: I  
> believe
> > > that Julian was also OK with this idea too, but didn't manage to  
> scribe
> > > that)
> > >
> > > Any objections?
> >
> > I'm fine with this change. It's good that XSLT and other "legacy"
> > content producer are satisfied. Let's move on something more  
> interesting ;-)
> There are two problems preventing moving on.
> First, we have an editor who did not participate in yesterday's  
> call, nor in the call the week before it, has chosen to Warnock[1]  
> this thread, has indicated that he does not and will not follow  
> consensus[2], and doesn't carry tracker items[3].
I would not expect Ian to object to the change proposed above, but  
since it amounts to minor aesthetic fiddling, I would not expect it to  
get high priority. I would not even think it particularly reasonable  
for the chairs to ask him to make this issue his top priority, given  
its relative importance.
> Second, Chris Wilson has indicated[4] that he is not happy with  
> legacy-compat, and at that point we no longer have consensus.
> From a technical perspective, here is my understanding of the  
> problem.  The following string is the smallest and simplest string  
> that will trigger standards compatibility mode in all browsers  
> (there was some confusion over this, but that was resolved[5]) and  
> can be produced by all known tools.
> <!DOCTYPE html "">
> If the goal was to promote a single DOCTYPE, this would be it.
> One possible objection is that the above DOCTYPE contains three  
> unnecessary characters, and by promoting a least common denominator  
> approach, we are penalizing everybody in order to accommodate a  
> relative few.
> One solution to that is to make those three characters optional.   
> Optional quotes are not without precedent within HTML, but some want  
> to go further and make the string pejorative[6] in order to  
> discourage its use.
> The current editor's draft follows[7] the pejorative approach,  
> singling out XSLT in a way that may be inappropriate[8].  The only  
> alternative proposed which does not single out any specific tool,  
> namely "legacy-compat", may be confusing[9].
> Going forward, I would appreciate it if everybody with an opinion on  
> the subject would weigh in on which of the following options they  
> could live with:
> 1) Single DOCTYPE, with a null quoted string
I would not support <!DOCTYPE html ""> as the sole doctype because it  
triggers quirks mode in some browsers. I would not support <!DOCTYPE  
html PUBLIC ""> as the sole doctype because it is extremely error- 
prone, as demonstrated by the many times it was misstated as <!DOCTYPE  
html ""> in the course of these discussions.
> 2) DOCTYPE with an optional null quoted string
I have the same objections based on either triggering quirks mode or  
error-proneness, depending on which doctype was actually meant. But my  
objections are not quite as strong, since it would at least be allowed  
to use a doctype that is concise, isn't error-prone, and triggers  
standards mode.

> 3) Two DOCTYPES: one "preferred" with no quoted string, and one  
> "pejorative" with the value "legacy-compat".
> 4) Two DOCTYPES: one with no quoted string, and one with a value of  
> "XSLT-compat" that should not be used unless the document is  
> generated from XSLT.
I could live with either of these. I would prefer 4, unless someone  
can cite specific examples of non-XSLT tools that cannot output <! 
DOCTYPE html> but could output <!DOCTYPE html PUBLIC "legacy-compat">.
> Note the way I phrased this.  "could live with".  This is not a  
> question of "prefer" vs "not happy with".  I'm looking for actual  
> reasons to actively exclude any of the above options.  Furthermore,  
> if you want to indicate why you can not live with an option, I would  
> expect that you would be able to explain why.
> And, yes, I fully realize that by asking people to express their  
> opinions in this way I am coming right up on the edge of what Ian  
> refers to as quite the extreme example of spec design by  
> committee[10].
It seems to me the differences among the options you presented are  
primarily aesthetic. Group-wide "could live with" seems like a very  
poor criterion to apply to aesthetic judgments. Unless there is a  
practical, non-aesthetic problem with option 4, I suggest we stick  
with that and skip the bikeshedding exercise.


> - Sam Ruby
> [1] http://en.wikipedia.org/wiki/Warnocked
> [2] http://intertwingly.net/blog/2008/11/20/Half-Full#c1227317561
> [3] http://krijnhoetmer.nl/irc-logs/html-wg/20090115#l-476
> [4] http://krijnhoetmer.nl/irc-logs/html-wg/20090115#l-702
> [5] http://krijnhoetmer.nl/irc-logs/html-wg/20090108#l-843
> [6] http://krijnhoetmer.nl/irc-logs/html-wg/20090115#l-705
> [7] http://www.whatwg.org/specs/web-apps/current-work/#doctype-legacy-string
> [8] http://www.w3.org/Bugs/Public/show_bug.cgi?id=6336
> [9] http://krijnhoetmer.nl/irc-logs/html-wg/20090115#l-701
> [10] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5803#c21

Received on Friday, 16 January 2009 13:56:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:41 UTC