Default styling for q element

[xfq]

Users expect default quotation marks around quotes to conform to the conventions of a particular language. For example, en-US typically uses “ ...”, whereas in Greek text a user may expect to see «...».

In a multilingual document, the quotation marks are part of the surrounding context, and don’t depend on the language of the quoted text (I've omitted the final period of the sentence, since the location of the period is irrelevant to the issue at hand):

But Lucy replied: “Embrassez George de ma part”

If we were to add the subquote, publishers would expect to see that use English quotation marks too, unless we specifically wanted to reproduce the text being quoted exactly as it looked in the original. So we’d normally expect to see:

But Lucy replied: “Embrassez George de ma part et dites-lui, ‘Embrouille’”

instead of French quotation marks.

The i18n WG would like to propose that the version of the quotation marks should be set according to the language indicated on the html tag, and not according to the language of the quoted text.

Currently, there are two sets of tests produced by the i18n WG:

1. https://w3c.github.io/i18n-tests/results/the-q-element.html
2. https://www.w3.org/International/tests/repo/results/the-q-element.en.html

The first one tests the proposed behavior above, and the second one tests the behavior/rendering currently specified in the WHATWG HTML Standard.

It seems that there're no tests about <q> in WPT at the moment:

• https://github.com/w3c/web-platform-tests/tree/master/html/semantics/text-level-semantics/the-q-element
• https://github.com/w3c/web-platform-tests/tree/master/html/rendering/non-replaced-elements/quotes

I'd be happy to port one of the tests above to WPT, preferably the first one.

---

For more information:

• https://w3c.github.io/i18n-drafts/questions/qa-the-q-element.en
• https://www.w3.org/2018/04/19-i18n-minutes.html#item03

[annevk]

The i18n WG would like to propose that the version of the quotation marks should be set according to the language indicated on the html tag, and not according to the language of the quoted text.

Well, that's not exactly what the rendering section does. I suspect the problem you are seeing is when the q element itself has a lang/xml:lang attribute. In that case you get the wrong result, but if you have a large section in different language that also contains some quotes, the current rendering rules seems preferable over just checking the root element.

I wonder if :root:lang(CODE), :not(:lang(CODE)) > :not(q):lang(CODE) (note the addition of :not(q)) would not be a better solution?

Also, it seems most browsers align with HTML today so this would be a breaking change to some extent? That might be acceptable though since it should strictly speaking improve things and it's unlikely to actually break sites.

[r12a]

I wonder if :root:lang(CODE), :not(:lang(CODE)) > :not(q):lang(CODE) (note the addition of :not(q)) would not be a better solution?

I agree that it would be useful to allow for more than just detection of root element for default quote setting, and i think this suggestion may work for the top level of quotes. (I assume that if there's no lang on html but there is one lower down the hierarchy that this would still kick in?)

For nested quotes such as

But Lucy replied: “Embrassez George de ma part et dites-lui, ‘Embrouille’”

I think there may be 2 possible strategies:

1. add another selector to keep the quotes the same around Embrouille.
2. decide that in the default case it's ok for the quotes to change around Embrouille and leave as is (this produces the effect of reproducing the quotes as in the original source, rather than changing to match the outer context).

[annevk]

(A comma in a selector is a logical OR, so yes.)

How would my selector not have the desired effect on your nested quotes scenario? If you have <q>Something: <q>Whoa</q></q> the selector would not apply so quotes would not be changed. You would need a more contrived example. (And your example even seems simpler than that, as the nested <q> is not a different language.)

[r12a]

And your example even seems simpler than that, as the nested is not a different language.

Ah, yes, you're right. Sorry. That then.

[aphillips]

The I18N WG actioned me with replying on this issue, basically to say that we'd like to proceed with what's described above. Please let us know if you'd like to discuss or let me know if you'd like to attend a teleconference to discussion. [I18N-ACTION-716]

[domenic]

I think the main issue in changing anything here is gathering implementer interest. Has the WG reached out to any implementers?

[xfq]

Link to minutes: https://www.w3.org/2018/05/10-i18n-minutes.html#item05

The WG has not reached out to any implementer yet.

Complete shot in the dark: @ericwilligers and @SimonSapin, any comment on this proposal?

[frivoal]

Link to a historical but fairly detailed thread on that topic (whole thread, not just initial email):
https://lists.w3.org/Archives/Public/www-international/2016AprJun/0008.html

In particular, it includes a suggestion by myself that the following pattern may be a good way to style <q> elements:

:lang(en) > *:not(q *) { quotes: "“" "”" "‘" "’" }
:lang(fr-CA) > *:not(q *) { quotes: "« " " »" "‹ " " ›" } 

[frivoal]

This email probably best summarizes my position:
https://lists.w3.org/Archives/Public/www-international/2016AprJun/0090.html

[r12a]

fwiw, this url shows the whole thread pointed to by @frivoal
https://www.w3.org/Mail/flatten/index?subject=Expected+behaviour+of+quotation+marks&list=www-international

[xfq]

Here's the demo written by @frivoal: https://jsbin.com/savatoqala/edit?html,css,output

[frivoal]

@xfq Thanks, I had forgotten about that one. Note about the demo: The selector syntax that it uses is only supported in Safari (and Vivliostyle) as of today as far as I know.

[fantasai]

:where(:root:lang(en), [lang]:lang(en))) { curly quotes }
:where(:root:lang(fr), [lang]:lang(fr))) { guillemots}
:where(:root:lang(zh), [lang]:lang(zh))) { brackets }
q { quotes: inherit; }

I think that should mostly work as intended?

Whatever selectors are being used here, they shouldn't be difficult to evaluate. So we have to take that into consideration. Florian's selectors are pretty expensive.

[frivoal]

Nice. This gives the same result, based on using simpler (and faster) selectors. I hadn't thought of undoing part of an overbroad selector using inheritance.

That sounds like the right solution.

[annevk]

@fantasai that would only work if we also discouraged xml:lang usage.

[fantasai]

@annevk OK, there, I fixed it. :)

@namespace xml "http://www.w3.org/XML/1998/namespace";
:where(:root:lang(en), [lang]:lang(en), [xml|lang]:lang(en))) { curly quotes }
:where(:root:lang(fr), [lang]:lang(fr), [xml|lang]:lang(fr))) { guillemots}
:where(:root:lang(zh), [lang]:lang(zh), [xml|lang]:lang(fr))) { brackets }
q { quotes: inherit; }

[himorin]

Note: W3C i18n WG closed our tracker with actions taken satisfactory. (please not remove i18n-needs-resolution label which is used by our bot and tracking system)