W3C home > Mailing lists > Public > public-html@w3.org > October 2008

RE: <q>

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>
Message-ID: <D12127075745E648BBC075EF46983E171D12DBD050@TK5-EXMBX-W603v.wingroup.windeploy.ntdev.microsoft.com>

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
>    <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 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
>    <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
>   <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

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.

Received on Wednesday, 29 October 2008 22:59:36 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC