- From: Chris Wilson <Chris.Wilson@microsoft.com>
- Date: Wed, 29 Oct 2008 15:59:33 -0700
- To: Ben Millard <cerbera@projectcerbera.com>, "L. David Baron" <dbaron@dbaron.org>
- CC: HTML WG <public-html@w3.org>
Ben Millard [mailto:cerbera@projectcerbera.com] wrote: >As for the way this thread has developed...I guess there's not much the IE >team can take away from it at the moment. Maybe I can help that? Indeed. :) >B. Basic punctuation is generated by at least Firefox and Opera but not by >IE<8: > <http://www.webdevout.net/browser-support#html> > > Quotes are generated by the Windows build I have of Lynx, too. ...and _are_, by the way, in case I haven't been clear about this, generated by IE8 (as of beta 2, I think). Including language specificity. >C. Generated quotes can be altered from CSS by at least Firefox and Opera (I >tested Firefox 2.0.0.17 and Opera 9.60) but the default characters they >generate are different: > <http://meyerweb.com/eric/css/tests/css2/sec12-04-01.htm> > <http://lists.w3.org/Archives/Public/public-html/2008Oct/0103.html> Yes. Generated quotes can be altered from CSS in IE8 as well. We appear to match Firefox 3 behavior on Eric's tests, to be specific - that is, we use non-ASCII quotes by default. >D. Firefox makes a token effort to support one non-Enlish language in one >localisation: > <http://lists.w3.org/Archives/Public/public-html/2008Oct/0102.html> We do better than that. I'd have to look up precisely how broad it is, but we recognize a set of lang values. >F. Punctuation differs between languages and some major languages have >pretty funky rules (to an English eye, anyway): > <http://lists.w3.org/Archives/Public/www-style/2006Sep/0141.html> We don't, of course, try to address the "quote before or after trailing punctuation" problem, or the "wrapped lines" problem - because we're based on CSS quote styling, and it can't do those IIUC. >G. Punctuation differs within the same language: > (David Baron described the disagreements he's come across within English >and German at the HTMLWG meeting last week, which are only 2 of the many >languages published on the web.) > <http://lists.w3.org/Archives/Public/public-html/2007Apr/0105.html> > <http://lists.w3.org/Archives/Public/public-html/2008Oct/0155.html> Hmm. I'm not sure I see the discrepancies there. It's certainly complex. Is there no Swiss German lang value, vs. German? >I. XHTML 2 makes generation of punctuation on its <q> element a MUST NOT: > <http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.8.> I don't think XHTML is a particularly good directive example for what we should do in HTML5. >J. XHTML 2's decision was (reportedly) due to the high volume of requests >from authors who do not want <q> to generate punctuation: > <http://lists.w3.org/Archives/Public/www-style/2007Apr/0116.html> Hmm. I'd have preferred actual references, but a good pointed anyway. >P. Dropping <q> might not be such a bad thing, since it has never been fully >implemented and perhaps shouldn't have been introduced to HTML in the first >place: > <http://lists.w3.org/Archives/Public/public-html/2007Apr/0122.html> Perhaps. Would everyone (aka top four engines) remove it from their engines then? >Q. Changing the behaviour of <q> may be unacceptable to HTML5 implementors: > <http://lists.w3.org/Archives/Public/public-html/2007Apr/0091.html> As in, specifying that <q> should not auto-quote may be unacceptable. Perhaps Maciej could weigh in on that. >R. If IE8 ships with <q> and </q> generating punctuation, at least 3 of the >main browser engines will be doing that. It's quite likely we WILL ship IE8 with <q> and </q> generating punctuation, since that's what HTML4.01 said we should do, and it's awfully late in the cycle to pull out now. If there's a solid reason for it, we might be able to, but I would think that building an implementation that's (mostly, modulo the choice of default quote characters in English and the international language support) interoperable across the 4 most popular engines would be the best thing to do (= ship auto-generating quotes). >It seems to me that <q> is made more useful and more implementable by no >longer generating punctuation automatically. More useful, I think, is debatable either way (and I mean that; I don't see a clear winner. Personally, I'd be more likely to use <q> if it quotes automatically, but that's me.) More implementable? Well, we've already implemented in IE8, and all the other browsers would be removing support (i.e. work, and causing back-compat delta that they may or may not care about.) >* It's impossible to fully internationalise the generation of punctuation on ><q>. I'm not sure I buy this as an argument. Technically, it appears correct, but you can definitely (imo) hit the bulk of use cases. > Punctuation conventions are inconsistent even within the same language. Still a little iffy on that one. Unless you mean the punctuation vs. quote order in British English vs. American English. >* <q> is rarely used, so changing it breaks only a small amount of content. >(Perhaps even that is too much, though.) It is rare. >* Authors are comfortable and familiar with doing their own punctuation for >other phrase elements. Well, yes, <q> was unique in HTML 4.01. >* Letting authors choose punctuation avoids problems with >internationalisation and editorial style. And they can still do that, by overriding the styles (or choosing SPAN, if they're worried about Lynx.) >* <q> is as useful for styling quoted text as any other phrase or formatting >element. (Colour, italics and so forth.) Or less so, perhaps. >* <q> lets quoted text be styled differently from other text whilst using >compact markup and a straightforwards CSS selector in an external >stylesheet. (As opposed to, say, <span class> or <font style>.) Yes. And it has a semantic meaning. I'd still personally be inclined to keep the HTML 4.01 behavior. It's overrideable for complex cases, and it gives good useful behavior in a large bulk of cases. Thanks, Ben, for such a great capture of where we are on this. It was very helpful. -Chris
Received on Wednesday, 29 October 2008 22:59:36 UTC