Re: The HTML q element can sometimes be useful. Discuss.

> On Apr 27, 2016, at 01:20, ishida@w3.org wrote:
> 
> I figured it would be good to start a thread where we can address the wider questions that kept popping up on the other thread that was focused on the styling in the HTML5 rendering section.
> 
> Here we get to put pros and cons for the existence of the q element, suggestions for improving it, advice about when to not use it, ideas about what's needed above and beyond it, etc.  I think CSS styling of quotes is probably in scope too, since it's hard to talk about the markup without the styling support.
> 
> It may help to limit the scope, however, just to *actual quotations*, rather than all the other things people stick 'quote marks' around, just in order to prevent a situation of herding cats.
> 
> So please reply to this. It's likely to be a long thread with diverse opinions. That's ok, but please try not to make unsubstantiated assertions.  Please use examples where you can, to help people get your point. And please be kind to other thread participants.
> 
> I'll contribute some ideas later when i can carve out some time. I do have some concerns.  At some point, i'll try to summarise the pros, cons and suggestions.


Needing to style something is not necessarily a proof that some semantic element is needed, but it is at least strong evidence.

Quotes are often italicized or made to stand out in one way or another. If rendered to a speech medium this is a good place to change voice, or to do something like "@media speech { q::before { content: "quote" } }". If we didn't have a q element, we'd often see <span class=quote> in markup.

This makes it different from a hypothetical sentence element. Just like quotes, sentence are semantically meaningful pieces of content. However, even though we don't have a sentence element, and we hardly ever see <span class=sentence> in markup.

In addition to styling, this is also reinforced by the fact that switching language for a quote isn't that rare, while switching language for a sentence that isn't a quote or in a separate paragraph or some other containing element doesn't happen all that much.

So since we're mostly going to mark up quotes anyway, we might as well have a standard element for it rather than everybody using their span soup. And going through a document programmatically to extract quotes is also not a crazy thing to do, so here as well, dedicated markup helps.

The question of punctuation is more tricky.

Like quotes, one could imagine generating the punctuation for a hypothetical sentence element.

  sentence::after {content: ". "}
  sentence:lang(ja)::after {content: "。"}

But nobody does this. Maybe generating the punctuation for quote is just as silly, and we don't see it because we're all too used to the q element. However, I don't think so. Unlike sentence ending periods, quotation marks do change based on the styling of the document (more so for blockquote than for q, but still).

All in all it is pretty clear to me that there should be an element for quotes, and that it should be possible to change what the quotation marks with css. I think this leaves basically two possibilities:

(1) What we have today:
  Markup:
    <q>something someone said</q>
  UA stylysheet:
    q::before {content: open-quote}
    q::after {content: close-quote}

(2) Some other elements where quotes are in the markup, but identified so that you can replace them.
  Markup:
    <quote><oq>“</oq>something someone said<cq>”</cq></quote>
  UA stylesheet: nothing

In both cases, you can in css remove the quotation marks or replace them. I think the meaningful differences are:

(a) Is it important to have quotation marks if the markup is rendered without any styling at all? If yes, and if we assume that such a css-incapable UA would know enough about HTML to tell apart block level elements from inline elements (otherwise the whole thing is mostly unusable), but not enough to know that the q element needs quotation marks, (2) is the way to go.

(b) If it is not practical to write css rules that will generate the right type of quotation marks most of the time, authors will need to turn off (q::before, q::after {content:none} ) the automatic quotation mark generation and write the punctuation in the markup instead, in which case they might as well use (2).

If (a) and (b) aren't issues, (1) is as capable as (2), and much less verbose.

I am somewhat sympathetical to (a), but not to (b), as I believe it is perfectly practical to write in the UA stylesheet rules that will generate appropriate quotation marks in most situations (see the other thread for what these rules should be).

We could provide some backward compatible hybrid solution that lets authors mix and match as they feel is appropriate:

Markup:
    <quote><oq>“</oq><q>something someone said</q><cq>”</cq></quote>
    <q>something someone said</q>
UA stylesheet:
  q::before {content: open-quote}
  q::after {content: close-quote}
  quote > q::before, quote > q::after { content: none }

However, I doubt many people care about (a) in practice, or that many people have issues with the quotes provided by the browser on the q element, so I suspect this markup pattern would not see much usage. I could be wrong though.

 - Florian

Received on Wednesday, 27 April 2016 01:29:07 UTC