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