(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 from comment #9)

I think this is a duplicate of the WONTFIX bug 16206. And I really don't
think we should do this unless somebody is writing a spec for the entirety
of the values and multiple browsers are agreeing to implement that spec, and
there's substantial review agreeing that the spec is correct.

Even if we think the way <q> works isn't a great design, given that both webkit and blink already implement localized open/close quotation marks, depending on the lang attribute (e.g. see example in bug 1560311 comment 3, which displays with various localized marks in both Safari and Chrome), I think we should do the same for better interoperability.

Regarding a spec, there's a clear source of data available in CLDR; we should simply use that.

One question regarding mapping the lang attribute: AFAICT, this would mean that an element with lang=xx gets a new initial value for quotes, overriding any inherited value for the property. So a document like

<div style="quotes: '<' '>';">
    <div lang="ja">Japanese <q>quotes</q></div>
</div>

would render Japanese quote marks. Is that correct? Is it desirable, or should the explicit quotes property on the parent <div> inherit "through" the presence of the lang attribute and continue to apply to the <q> within the lang=ja content?

Or is there a way we can map the lang attribute to a quotes value only if it has not been explicitly set by an ancestor?

Hmm, looking at https://html.spec.whatwg.org/multipage/rendering.html#quotes I see that it lists rules such as

:root:lang(ja), :not(:lang(ja)) > :lang(ja) { quotes: '\300c' '\300d' '\300e' '\300f' } /* 「 」 『 』 */

which implies that the example in comment 11 should indeed render Japanese "bracket" quotes around the <q> element.

There are still some open questions regarding how <q> should deal with language (use quote marks based on the lang of the <q> element vs its parent?); see https://github.com/whatwg/html/issues/3636. However, regardless of how that gets resolved, I think we should go ahead with implementing lang-based quote marks based on CLDR data, so that at least straightforward cases behave as expected, and more consistently with other browsers.

To try and move this forward, I've created a set of WPT reftests based on the i18n group's "language responsiveness" tests at https://w3c.github.io/i18n-tests/results/the-q-element.html; currently we fail a bunch of these (we only pass those where the language-specific quotes happen to match our default quote marks). I also have a patch series that implements CLDR-based language-specific quote marks, which makes these tests pass.

Depends on D36426

Depends on D36427

Depends on D36428

Jonathan, if my review comment in https://phabricator.services.mozilla.com/D36429 makes sense to you, I'd be happy to write a more formal proposal to the CSS working group, and I think the patch would become much simpler.

We can actually implement the blink behavior pretty straight-forwardly without waiting to discuss what the name of the new value would be (and you can still use it via quotes: initial from an author's perspective). We'd just need to replace the initial quotes computed value for a default-constructed ArcSlice, and make sure that serializes to the empty string. That should be web compatible (since it's what WebKit and Blink do), and forwards-compatible with whatever resolution the CSS WG comes up with.

Also, that means that the right way to implement the quotes reset that I discussed with Jen Simmons and Fantasai last CSSWG F2F would just be [lang] { quotes: initial } (or [lang] { quotes: auto / whatever } if we expose that magic initial value to content).

Yes, this sounds like a good way forward. If you can put a proposal to the WG, that'd be great - thanks.

The issue was resolved to add auto.

OK, sounds good. I took a stab at revising the patch here to add auto, and it seems to behave as expected; most likely could be a lot more idiomatic, especially on the rust/style-system side of things, as I really don't know what I'm doing there, so feedback welcome!

Also added a few tests for nested quotes etc.

Depends on D36429

Backed out 5 changesets (Bug 1421938) for causing a bustage in /builds/worker/workspace/build/src/intl/locale/cldr-quotes.inc:21:448 CLOSED TREE

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=255318089&repo=autoland&lineNumber=13452

https://treeherder.mozilla.org/#/jobs?repo=autoland&fromchange=fb8fbe6000f3ae72051a961f880f4a54299bf885&selectedJob=255318089

Re-landing with fix for the warnings-as-errors bustage.

Separately, :gandalf wondered on irc whether we could use ICU to retrieve the localized quotation marks, rather than the static CLDR-derived data here. That may be a good option (simpler maintenance), though might be a bit more expensive. I'll look into it and potentially file a followup if it seems worthwhile.

Backed out 5 changesets (Bug 1421938) for bustages in /builds/worker/workspace/build/src/layout/base/nsQuoteList.cpp CLOSED TREE

https://treeherder.mozilla.org/#/jobs?repo=autoland&fromchange=44bdb6882218741af78e5bd5e7a892fa984c40bf&searchStr=linux%2Cx64%2Cdebug%2Cbuild-linux64-base-toolchains-clang%2Fdebug%2C%28bbc%29&selectedJob=255370380

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=255370380&repo=autoland&lineNumber=24008

https://hg.mozilla.org/mozilla-central/rev/0d506ceb820f
https://hg.mozilla.org/mozilla-central/rev/44d239e5d236
https://hg.mozilla.org/mozilla-central/rev/66e4974b9a8c
https://hg.mozilla.org/mozilla-central/rev/b7e1b4dd94c6
https://hg.mozilla.org/mozilla-central/rev/4e0eb2a76b0f

I've had a go at documenting this; see https://github.com/mdn/sprints/issues/2101#issuecomment-530782716 for the full details.

I am a bit unsure as to whether I got this right, as the results seem strange; a review would be much appreciated. Thanks!

Looks reasonable to me; what do you feel is strange? (Just the fact that the other browsers have auto behavior yet don't recognize the value? That's known, and I expect in due course they'll add it.)

Basically, the auto value is a recent addition to the spec, and I don't think any other browsers have actually updated to support it yet, but they "magically" behave that way by default anyway. See https://github.com/w3c/csswg-drafts/issues/4074 for background.

(In reply to Jonathan Kew (:jfkthame) from comment #35)

Looks reasonable to me; what do you feel is strange? (Just the fact that the other browsers have auto behavior yet don't recognize the value? That's known, and I expect in due course they'll add it.)

Basically, the auto value is a recent addition to the spec, and I don't think any other browsers have actually updated to support it yet, but they "magically" behave that way by default anyway. See https://github.com/w3c/csswg-drafts/issues/4074 for background.

Yeah, basically it just felt a bit weird to me, as I've never explicitly thought about this kind of situation before, but I guess it's not the first time its happened. I'm glad I got it right ;-)

Thanks for the review and explanation - this is really helpful.