<q> omnibus

I've gone back to basically what HTML4 says: the <q> element introduces 
quotation punctuation at the style level; if you want to put quote marks 
into the document itself, then don't use the <q> element.

Some key e-mails on the topic are quoted below (with comments from me). 
There was a lot of discussion on the subject. While I read every e-mail 
carefully, I haven't replied to every comment below. If you think I missed 
a key point, please do raise it again.


On Fri, 24 Oct 2008, Chris Wilson wrote:
>
> I'd like to suggest a different strategy for <q>.  I'm not comfortable 
> with a strategy that directly says you must break the only required 
> rendering rule in HTML4.01 in order to be compliant with HTML5.  I 
> believe we should pick one of the following options: 1) it should either 
> be removed, 2) required to quote, knowing there are nesting/locale 
> problems, 3) required to quote unless the immediately contained 
> characters are quote characters, allowing locale-specific or 
> nesting-specific author choice, 4) nest automatically with an attribute 
> to control quoting, or 5) (my least favorite option) leave it ambiguous.

I've picked 2, since all the browsers are doing that anyway. Authors will 
be able to control the quote characters from the style sheet.


On Fri, 24 Oct 2008, Sam Kuper wrote:
> 
> Suppose I am marking up content which contains a phrase that is 
> definitely a quotation, yet the author has only remembered to include 
> the opening quotation mark. In order to preserve what the author has 
> written, I must be able to override any rule that would by default 
> append a quotation mark to the quote (or alternatively, specify a rule 
> that only puts a quotation mark at the beginning of the quote).

Why wouldn't you just fix the markup?

In any case, CSS allows you to control quotes on a case-by-case basis.


> Another thought: shouldn't the rules be expressed in CSS? They do 
> represent a 'style' of punctuation, after all.

They are expressed in CSS.


On Fri, 24 Oct 2008, Justin James wrote:
> 
> I feel VERY uncomfortable with the idea of an HTML element that 
> specifies a particular presentation in a manner that only makes sense in 
> certain languages (not every locale will have a quotation mark 
> character, but authors will come to expect the <q> element to render 
> it). If I am reading this idea wrong, please let me know!

I've made the spec be clear that you don't have to use <q> if you don't 
want to.



On Sat, 25 Oct 2008, Sam Kuper wrote:
> 
> This sounds essentially reasonable to me. How about having HTML 5 
> specify the default CSS quotes property for every language in RFC 3066 
> (or, alternatively, should another RFC (or suchlike) be started for the 
> purpose of specifying these), so that HTML 5 can reference it)?

This might be a good idea for the rendering section. Any volunteers?


> On another note, I advise everyone here who hasn't read it previously to 
> read the following article: http://www.alistapart.com/articles/qtag . 
> Basically, it explains how to handle the kind of mess we should be 
> trying - in HTML5 - to head off at the pass.

This seems to be a non-issue since the whole discussion started because 
IE8 will apparently support <q> and 'quotes'.


On Wed, 29 Oct 2008, Daniel Glazman wrote:
> 
> Why would I need a computer-related spec to define what has been living 
> in the print world for ages? It's not HTML's task to do that, IMHO. It's 
> our national standard body's duty that_already_ has specs for printed 
> material to include the unicodes for the chars they're listing, period.

The question is whether implementors are more likely to do a good job if 
they are provided with the answers for every locale or whether they'll do 
a better job if they have to research every locale themselves.


On Sat, 25 Oct 2008, Ben Boyle wrote:
> 
> I've never understood why quotation marks got special treatment. All 
> other punctuation has to be included in the content (before applying 
> markup and styling). Since HTML4 established it that way, I'd rather see 
> it deprecated in HTML5. Beyond that, I have no opinion on how UAs are 
> instructed to parse it.

I've made it clear that use of <q> isn't required.


> Let me explain why I don't find q useful (why I think it could be 
> deprecated).
> 
> I could author this:
> <q lang="en">Hello world</q>
> 
> And I could change the language:
> <q lang="fr">Hello world</q>
> 
> If all worked to spec, the rendered quotation marks would change. But to 
> do this I had to change the language attribute. I also should have 
> translated the text to 'Bonjour world' (according to babelfish[1]) ... 
> because this will not automatically occur. If I'm already doing all 
> that, I might as well embed the quote characters and change them too. 
> The q element is not giving me (the author) a great deal of value.

The value is that you can change the kinds of quote marks from the style 
sheet, e.g. making them coloured, or omitting them and making the text 
italics, or whatnot.


> A passing suggestion: why not just define some entities... like &oquo; 
> "an opening quote, based on the current language" and &cquo; for closing 
> quotes. Let them be used wherever, without worrying about the element. 
> (Yeah, I hear someone mentioning 'nested quotations' already). If we're 
> delving this deep into quotations, might as well define the markup for 
> poems and everything else documents could conceivably contain. I mean, 
> imho, this q stuff is tending towards the esoteric.

<q> seems easier to make work than entities.


On Sat, 25 Oct 2008, Preston L. Bannister wrote:
>
> Have to admit, the <q> tag is one of favorites. Since it has no 
> meaningful overt use (because of past IE), it makes a handy container 
> for data to be transformed to something else by script. Short tags trim 
> a bit from the processing needed on the server, and fewer bits on the 
> wire (both always a good thing). Adds up for complex structures. So <q> 
> ends up quite useful (in conjunction with script), only because it has 
> no use (in HTML).
> 
> Makes me wish there more valid useless short tags.

Using defined tags in a way that doesn't match what the spec says is not 
valid. It's just tricking the validator into lying to you.


On Sun, 26 Oct 2008, Ben Boyle wrote:
> 
> Taken to its fullest extent, this thinking leads to fully describing 
> language grammar. Please excuse my crude example below, and I understand 
> you are not proposing this. (But I can't help following through on the 
> thinking and arriving at this conclusion)
>
> <p>
>   <sentence>
>     <phrases conjunction="and">
>       <phrase>
>         <subject>This</subject>
>         <stuff>is a</stuff>
>         <adj>seductive</adj>
>         <n>notion</n>
>       <phrase>it would be <n>convenient</n> if it <v>held</v>
> <n>true</n> <adv>generally</adv></phrase>
>   </sentence>
>   ...
> </p>
> 
> I am certain there is a place for this in the world. I think HTML is in 
> a pretty good space. Table markup is fantastic - there's no punctuation 
> for tables btw. List markup is another, where bullets/numbers, and 
> that's proven itself so useful I would not change it.

The difference is that people haven't wanted to style their nouns 
differently. They have wanted to style their quotes differently.


On Sun, 26 Oct 2008, Sam Kuper wrote:
> 
> A use case I've experienced is when an editorial decision is made to 
> change all quotes on a site from being single quotes on the first level 
> of nesting to double quotes on the next level, etc, to the other way 
> around - double on the outside, single on the next level in, etc.
> 
> This is a royal PITA to change without the <q> element.

Indeed; this is one of the main use cases for <q> IMHO.


On Wed, 29 Oct 2008, Ben Millard wrote:
> 
> [...great summary...]

Thanks for that, it's very helpful.


> It seems to me that <q> is made more useful and more implementable by no 
> longer generating punctuation automatically.

In general I would agree; that's why we had removed punctuation generation 
in HTML5 before. But with IE8 implementing quotes, this changes matters.


> * It's impossible to fully internationalise the generation of 
> punctuation on <q>.

I don't think we need to _fully_ internationalize it, though.


> Given the range of editorial and international convention, I think the 
> spec should allow punctuation anywhere in and around <q>. In particular, 
> I wouldn't want speechmarks to change style but I probably would want 
> terminal punctuation within the quoted text to do so:
> 
>    The officer gave chase. "<q>Oi! Stop right there!</q>" she bellowed.

I've disallowed this since the UA is to generate the punctuation marks.


Big thanks for the in-depth study, too. That data is very useful.


On Wed, 5 Nov 2008, Ben Millard wrote:
> 
> With IE8 doing different things for some selection of languages, the 
> "language-sensitive" aspect will not be interoperable.
> 
> If HTML5 is to make <q> generate quote marks, it will need to specify 
> what UAs are supposed to do:
> 
> * I imagine specifying and implementing <q> to generate quote marks for 
> every language used on the web would be impractical.
>
> * If we say it always generates English quotes, that's hardly fulfilling 
> the goal of internationalisation.
>
> * If we enshrine one convention in each of 5 major languages, that may 
> not be an 80% solution. (It only solves a portion of the cases in each 
> of a portion of the languages used on the web.)

We can do the top 40 languages and hit about 99% of the Web, which isn't 
bad. It's something for the rendering section. Something to ask the i18n 
group for help with, maybe? Is anyone here following from i18n?


> As the uptake of <q> is so low and the market leading browser doesn't 
> generate quotes, now seems like the least damaging time make <q> more 
> useful for authors. We could score several goals with one ball by 
> removing the automatic generation of quotation marks on <q>:
> 
> * Simplifies the UA requirements, especially for internationalisation.
> * Removes a point of low interoperability from the web.
> * <q> becomes consistent with other phrase-level elements.
> * More predictable for authors to use (works like <b>, <em> and so on).
> * Authors can continue current practice of writing quotation marks
> themselves but can now use <q> for styling quoted text more easily.
> * <q cite> provides cross-referencing without the quote mark side-effect.

I'm not convinced that without the quote marks, anyone cares. If they 
did, <q> would probably be in wider use.

It may be that even with the quote marks, they don't care, but we haven't 
tested that one yet.


On Sat, 12 Apr 2008, fantasai wrote:
> Ian Hickson wrote:
> > Summary: I've made the spec require that any punctuation for <q> be included
> > inside the element; I've added examples for <q>.
> > ...
> > > How would you define CSS pseudo-elements for open and close quotes in such
> > > a way that they would be implementable and would not match apostrophes and
> > > would correctly differentiate between open and close quotes in languages
> > > that use the same character for opening and closing and in languages that
> > > invert the direction of guillemets compared to French?
> > 
> > I would introduce two pseudo-elements, ::quote-start and ::quote-end, which
> > match one or more characters with the Quotation_Mark property (as per
> > Unicode PropList) found at the start or end of an element, if such text is a
> > direct child of the element (skipping White_Space characters).
> > 
> > I've started this idea down the path of the CSS working group.
> 
> Please send a message with your proposal to www-style for discussion and 
> CC www-international. (We use the wiki to track issues, not as a 
> substitute for mailing list discussion. Also, it would be important to 
> have i18n people involved since punctuation styles vary across languages 
> and I'm not sure Unicode's Quotation_Mark property is adequate.)

Since this is no longer an issue, I have not sent this request.


On Wed, 23 Apr 2008, Leif Halvard Silli wrote:
> 
> On the background of what HTML 4 says about this, should the new 
> formulation be taken to mean only that it is now *permitted* to add 
> quotemarks yourself, or should it mean that it is required to do so, if 
> you want quote-marks?

It's now not allowed at all if you use <q>.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 30 November 2008 08:32:40 UTC