[css-content] Quote character choice must depend on surrounding language, not language of the quotation

2.4.1. Specifying quotes with the quotes property
https://drafts.csswg.org/css-content/#quotes-property

auto
A typographically appropriate used value for quotes is automatically chosen by the UA based on the content language of the element and/or its parent.

Note: The Unicode Common Locale Data Repository [CLDR] maintains information on typographically appropriate quotation marks. UAs can use other sources of information as well, particularly as typographic preferences can vary; however it is encouraged to submit any improvements to Unicode so that the entire software ecosystem can benefit.

The i18n WG raised an issue related to the Rendering section of the HTML spec because current implementations choose quote marks based on the language of the quotation, rather than the language of the surrounding text. This is wrong, and needs to be fixed.

It is noticeable when the language of the quotation is different from that of the surrounding text. See these tests:

Since the HTML spec is now to have that section removed (due to introduction of the auto value for the quotes property), we need this requirement to be made clear in the CSS spec.

[Note, btw, that contrary to the request at the start of the HTML thread mentioned above (https://github.com/whatwg/html/issues/3636), it is important to base the choice of quotes on the language of the immediately surrounding text, not the language of the html tag (as is made clearer further down the discussion thread).]

It would also help to include a note showing how content authors can make their styling produce the correct results (since it's far from straightforward, and it will no longer be possible to point to examples in the HTML spec).

Language-depeendent quote marks generated with quotes:auto should be …

Bug 1751940 - Language-depeendent quote marks generated with quotes:a…

Language-depeendent quote marks generated with quotes:auto should be …

HTMLQuoteElement quote delimiters should be based on lang of parent

Revert "HTMLQuoteElement quote delimiters should be based on lang of …

Update first-letter-with-quote.html

Bug 1774859 [wpt PR 34485] - HTMLQuoteElement quote delimiters should…

Bug 1776084 [wpt PR 34539] - Revert "HTMLQuoteElement quote delimiter…

Bug 1774859 [wpt PR 34485] - HTMLQuoteElement quote delimiters should…

Bug 1776084 [wpt PR 34539] - Revert "HTMLQuoteElement quote delimiter…

QuoteContentData pseudo_style should use parent lang to create Layout…

[css-content-3] 'quotes: auto' resolves lang against the parent #5478

[css-content-3] Define 'match-parent' for 'quotes' #5478

@r12a

OK, I pushed some edits for this. There's actually two approaches we can take for match-parent:

Compute to a set of strings, inherit as such.
Essentially compute to "auto, but for this language", and inherit as such. Like alternatively you could implement as "look up the tree until we find a non-match-parent value and grab the content language from that element", but it's probably easier to just inherit it as a package deal. Idk if I should note that trick in the spec or not...

Anyway, I took the second option (resolve at used-value time only) because it's more consistent with how auto works. But would appreciate WG review. 8b2623c

@r12a Currently auto resolves on each element it's used, it's just now changed to look at the parent instead of the element itself. To get the behavior you have in the last example (Mais Lucy répondit: «Give George my love and tell him, ‹Muddle›».) you'd need to spec q q { quotes: match-parent; }. Do you think we should do this by default or is e.g. (Mais Lucy répondit: «Give George my love and tell him, “Muddle”».) a reasonable default?

Currently auto resolves on each element it's used, it's just now changed to look at the parent instead of the element itself. To get the behavior you have in the last example (Mais Lucy répondit: «Give George my love and tell him, ‹Muddle›».) you'd need to spec q q { quotes: match-parent; }. Do you think we should do this by default or is e.g. (Mais Lucy répondit: «Give George my love and tell him, “Muddle”».) a reasonable default?

No, no. Keeping the same style of quote marks for embedded quotes is what i'm asking for in many of my previous comments in this thread, and as the default. Everything i've seen indicates that the internal quotes should be consistent with the external quotes. I therefore don't see “Muddle” as a reasonable default. It should be ‹Muddle›. hth

Also, what happens if you have more than one set of embedded quotes – rare, i grant you, but probably not something to ignore.

I also find myself wondering why auto should be the default setting, since match-parent (where parent means the context outside the outermost quotes) is really what we need by default. It seems to me that the auto setting should produce that most of the time anyway – i hope it will not turn into something that allows browsers to continue doing the wrong thing as they have been doing so far.

@r12a

@r12a match-parent won't do the right thing as an initial value because it maps the element's language to a quotation mark system and then inherit with that choice locked--which by default means it'll take the language from the root element (which is the outermost element), map it to a quotation mark system, and trace that system that through the whole document tree. That won't do the right thing in a lot of cases.

@r12a

you'd need to spec q q { quotes: match-parent; }

I think we'd need q * { quotes: match-parent; } in the UA stylesheet to get the behavior @r12a wants, and I cannot think (at least not yet) of another way to achieve the same result. Should we do that?

I think i had misread the meaning of auto. Tell me if i'm right in thinking that if the default situation is

q { quotes: auto; }
q * { quotes: match-parent; }

then Mais Lucy répondit: «Give George my love and tell him, ‹Muddle›». would come out as expected, even if there was a third or fourth embedded level, and even if the languages of each embedded level change. That is, the quotes for the top level are set by the language outside the top level (auto), but the quote marks for any embedded levels simply match the quotes used in the top level, regardless of language. (And of course the actual quote characters can vary according to the level, eg. single or double guillemets, but they always match the quotes one would use in the language of the text outside the top level.)

If that's so, then this may be a useful approach for dealing with the q element, but content authors will need to know/remember to use the two lines of CSS for any non-q elements if they hack it themselves. That's a bit of a concern.

Tell me if i'm right […]

By my understanding, yes, that is correct.

So, as discussed on a recent i18n call, the above discussion is wrong, because content: open-quote (resp. content: close-quote) is not used on the q element, but on ::before (resp. ::after), which are children of the q element.

So what we would need to get the desired behavior is:

a quotes: match-parent or quotes: parent or parent-language or quotes: context (to be bikesheded) value which computes to (and therefore inherits as) a set of strings describing the appropriate type of quotes based on the content language of the parent element

Adding this to the user agent stylesheet

q { quotes: parent-language; }
q q { quotes: inherit; }

With that in place, the pre-existing ua stylesheet rules

q::before { content: open-quote; }
q::after { content: close-quote; }

would do what i18n expects.

quotes: auto could go back to computing to a set of strings describing the appropriate type of quotes based on the content language of the current element. This would not be used by q, but could be useful in other contexts, such as blockquote elements, which authors could opt into styling either with auto or parent-language. Alternatively, if resolving based on the current element's language that's considered useless in all contexts, auto can be the name we use for the parent-language

@1

This issue was discussed in a meeting.

No actions or resolutions

View the transcript

#5478
Issue 5478 [css-content] Quote character choice must depend on surrounding language, not language of the quotation (by r12a) [css-content-3] [Closed Accepted by CSSWG Resolution] [i18n-needs-resolution] [Agenda+ i18n]
fantasai: it's been edited and I haven't republished the draft yet
florian: does that include that part needs to go into the UA style sheet, or just the mechanics of it?
florian: make the initial value do the right thing, or make the UA style sheet do the right thing?
fantasai: the only way to do that automatically would be to make the value of the quote property to depend on @@
… without a separate selector I don't think it's possible to get it to do the right thing
… that brings up a question of the selectors might not be the most efficient
florian: @@1
fantasai: if what you're trying to do is as soon as you hit a q element then you lock it down you could do it on any child
<fantasai> q > * { quotes: match-parent; }
xfq: do you mean the author should specify this?
r12a: that's the thing I'm arguing against
… I don't think the author needs to remember or find out how to make the default expectation
… and it should happen by default
<fantasai> q { quote: auto-compute-me-now; } /* iherits as string value */
r12a: whether that happens because we put something in a style sheet or whether that happens because the initial value
florian: do you think browsers will be happier with @@?
fantasai: I don't know
florian: but you're probably reasonably well-positioned to ask people who would know
xfq: @@
r12a: it's not supposed to respond to changes in languages further down
fantasai: it's because if you set the initial value to a value on the root element and it computes on the root element rather than inheriting the auto
… from what I understand, you don't want either of these behaviours
florian: and I think the thing with a selector in the UA style sheet does give us the right behaviour
… it's just not the kind of thing we typically want to
xfq: what's the next step?
fantasai: we can go back to browser vendors and ask them which approach they want to take here
florian: can we agree on a UA style sheet rule that is the most performant and acceptable we can think of
… that gives us the behaviour we want and then we tell the browsers are you either willing to implement this or do you have another suggestion?
florian: you want the first q element in the hierarchy
… lock down every descendant of it
fantasai: right now we have match-parent, but instead of computing against the parent's language it computes against your own language
… which is match-self
<fantasai>

Some text more text inner text

fantasai: so we have this, what you want here is you want French quotations all the way through
r12a: yeah
florian: the auto keyword means that you pick a quotation system based on the content language of the parent
… so exactly what we want on the first q element
fantasai: instead of saying it matches the same quotation mark system as the parent, we want a keyword that computes against the parent
… you can't do that as initial value because it breaks stuff
florian: effectively that's kind of what match-parent does
… match-parent gets that string from above, while auto doesn't and re-resolves it everywhere
fantasai: what are impls do currently is a good question
florian: they do the wrong thing
<fantasai> auto = resolve against the current element's language
<fantasai> (and inherit as 'auto', so re-resolve on each element)
<fantasai> match-parent = resolve against the parent eleent's langauge
<fantasai> (and inherit as that string, so don't re-resolve)
florian: when do you ever want to resolve against the current element's language?
fantasai: @@
florian: from my point of view, the way you have it specified now, is precisely the behaviour you want
… as far as the q element is concerned
florian: what do you want for blockquote?
florian: possibly the same, but I'm not sure
r12a: I don't think a blockquote is the same thing as a q element
… I'm just thinking off the top of my head at the moment
… a blockquote is bit of text that you indented usually
… the blockquote at the top level would take the quotes of the surrounding language
… but inside of it, it's different
florian: in that case, we're fine
… I still think we're on the right behaviour with the spec as it is plus the UA style sheet rule
fantasai: here's a fun wrinkle I think we didn't think about
… if the quote is not generated by the q element, but by ::before, which is a child of the q element
… match-parent should use the language tag of the parent to resolve to a string
florian: @@
… that's still not good enough, it's good enough to make it work, but we also need to disable that on descendant s
florian: I thought we had the solution, but I forgot the ::before in the child
r12a: I find it very difficult to follow all the stuff you're talking about because I don't know the technical details
florian: I think we really understand the use case that you want to achieve, but it's surprisingly tricky to get there
<fantasai> q { quotes: match-parent; } q q { quotes: inherit; }
<r12a> fuqiao, here's a link: r12a/mins2issue
fantasai: this is not as bad as an universal selector because q is not very often used
… even if you have to walk up the parent up to the route every time you hit a queue, you're not gonna hit a q very often
… so it won't regress most pages probably
florian: we now have a definition that probably works and a selector that's less problematic
… still not amazing, but probably works
… maybe we should update the spec
… and talk with the browser vendors
fantasai: that seems reasonable
… back to blockquote
florian: maybe it's just parent, not match-parent
fantasai: auto-parent or something like that
florian: we should write it down
fantasai: and ask the browser vendors
florian: I'm curious how often is this something people run into and complained about
xfq: I've seen some real examples in paper books
r12a: I've seen real web pages too
… I use the q element myself
… it's really useful for things like translation
… you don't have to go through all the hard coded quote marks and change them
… you just change the CSS

data:text/html,<div lang="zh"><q lang="fr">Quote <q>embedded</q></q> <q>Quote</q>

The CSS Working Group just discussed [css-content] Quote character choice must depend on surrounding language, not language of the quotation, and agreed to the following:

RESOLVED: adopt a quotes value that, if the parent's quotes computed value is auto, computes the correct quotes for the parent's language, and if the parent's quotes computed value is not auto, inherits that value
RESOLVED: drop existing match-parent value

The full IRC log of that discussion

<emeyer> florian: The internationalization people have told us what they want
<dbaron> s/five other ways/five other ways, whether computed style from font relative units or layout/
<emeyer> …A quote should inject at the start and end the quotation marks of the parent's language, not the element's language
<emeyer> …But if you nest them, the innermost should use the quote of the outermost quotation style
<emeyer> …In the general default case, you have to lock in the quote style and carry it down the ancestor chain
<emeyer> …We think we've come up with some approaches, but they could be performantly painful
<emeyer> The old-fashioned way was to supply a bunch of pairs of strings
<emeyer> 1. The spec has an auto value which computes to itself and represents the quotation system implied by the language of the parent element
<emeyer> fantasai: So if you have English text with a French quote, you use English quotation marks, even though the q elem,ent and its generated content are in French
<emeyer> …But if the French quote has a quote in French or English or whatever, you still want to use the English style quotes because you're in an English paragraph
<florian> q { quotes: auto; }
<florian> q::before,
<florian> q::after,
<florian> q * { quotes: match-parent; }
<emeyer> florian: So to achieve that, there's a match-parent value that computes to itself and means, "use the same quotation system as my parent"
<kizu> +q
<emeyer> …This does put a `q *` selector in UA stylesheets
<emeyer> …If you think this doesn't solve as stated, say so; if you think it's fine to put it in UA stylesheets, say so
<astearns> ack kizu
<emeyer> kizu: If we had a content pseudo-element, we might use this for quotes?
<emeyer> fantasai: No, that wouldn't work, because inheritance is before box construction
<emeyer> florian: 2. Uses different keywords not specced yet, but let's call one 'parent-language'
<emeyer> …This is like 'auto', but it computes to the set of strings the language needed, and inherits as those strings
<florian> q { quotes: parent-language; }
<florian> q q { quotes: inherit; }
<emeyer> s/but/except/
<emeyer> …If you're a quote element, you lock on your parent, unless you're nested, in which case you inherit the strings
<emeyer> …I don't know which UAs would prefer, I suspect the latter
<emeyer> …If neither works, what do we do??
<emeyer> dbaron: If both are bad, we could solve it by having a value that uses the parent language only if the parent has the initial value, and otherwise inherits from the parent
<emeyer> florian: Say again?
<emeyer> dbaron: 'parent-language-or-auto', uses the logical value 'auto' would use, otherwise inherits
<kbabbitt> q+
<emeyer> florian: It computes to itself and stays as is?
<emeyer> dbaron: All I need auto for is it's the initial value of the property
<emeyer> …So on the outer element it would look at the parent to get the language
<emeyer> (crosstalk)
<emeyer> …Then if you have a nested q element, you look at the parent, it isn't auto, so you just inherit it
<emeyer> florian: I agree that would also work
<emeyer> …One thing to not forget and I don't think you did, the place where the actual quotes are injected, they're the before and after, but that should still work with what you described
<emeyer> …Great, now we have three solutions; which is most implementable?
<astearns> ack kbabbitt
<emeyer> kbabbitt: I vote against putting a universal selector in a UA stylesheet, as it will likely trigger a lot of style invalidation
<emeyer> dbaron: I would defer to Rune or Anne for their thought on option 2
<dbaron> s/or Anne/or Ian/
<emeyer> florian: internationalization is reluctant about option 2, since you have to remember to put a bunch of non-obvious things in stylesheets
<emeyer> …I think David's thing is closer to what they want
<emeyer> dbaron: That's true, the downside is it's more magical and more weird
<emeyer> …We'd need a name
<emeyer> fantasai: match-parent?
<emeyer> dbaron: noooooooooo
<emeyer> florian: It doesn't quite work because it has to do different things
<emeyer> fantasai: Another one is to call one value normal and one auto?
<emeyer> dbaron: We could name for what it isn't for instead of what it does
<TabAtkins> for-q
<emeyer> florian: Bikeshedding aside, between option 2 and 3, which is better?
<TabAtkins> [me yelling at the dude who just sideswiped me] "FOR-Q"
<emeyer> futhark: I'm a little confused about the options, but avoiding the universal is good
<fantasai> 1. q { quotes: auto; }
<fantasai> q * { quotes: match-parent; }
<fantasai> 2. q { quotes: parent-language; }
<fantasai> q q { quotes: inherit; }
<emeyer> dbaron: Option 2 had a `q q` selector
<fantasai> 3. q { quotes: magic; }
<emeyer> …option 3 has only `q` because all the nmagic is in the value
<emeyer> futhark: I think I prefer that
<ChrisL> q {quotes: anon }
<emeyer> florian: All the magic happens at compute time, which is a different concern
<emeyer> futhark: Does it have to walk up the tree?
<emeyer> dbaron: It involves lookiong at the parent and maybe pulling stuff down
<emeyer> futhark: That sounds the best option
<emeyer> florian: So we can go back to bikeshedding optoin 3
<emeyer> jfkthame: Can we just not change the value of auto?
<emeyer> florian: ??
<emeyer> iank_: That would change the existing quotes property?
<emeyer> florian: The value now is only strings, there is no auto
<astearns> s/??/we could use auto, but then we need an initial value - maybe normal?/
<emeyer> fantasai: But everyone's shipping auto
<emeyer> florian: What does it do?
<emeyer> fantasai: [missed]
<emeyer> florian: So auto does something and has to be kept and we need a new name
<emeyer> fantasai: capture?
<emeyer> florian: Maybe
<emeyer> astearns: I prefer going back to the issue while resolving on behavior
<dbaron> quotes: outer-language ?
<fantasai> It wouldn't be outer language if you nested three languages though
<dbaron> Proposed resolution: adopt a quotes value that, if the parent's quotes computed value is auto, computes the correct quotes for the parent's language, and if the parent's quotes computed value is not auto, inherits that value.
<bkardell_> I'm good with that
<emilio> q+
<emeyer> emilio: Doesn't this require you to walk arbitrary ancestors?
<emeyer> florian: You only have to look at the parent
<emeyer> emilio: This would only apply to the quote element?
<emeyer> fantasai: You could put it on any element
<emeyer> dbaron: This will mostly work for style computation and inheritance
<emeyer> …The special inheriatnce rules here will only require looking up one step for each element
<emeyer> emilio: But it would expose ?? data for the language
<emeyer> dbaron: Yes
<fantasai> s/??/CLDR/
<emeyer> emilio: Okay, I think it might be fine
<emeyer> dbaron: I guess that might be a substantive change in that you need to do CLDR seek at computation time rather than layout time
<emeyer> emilio: I don't think that's a hard lookup to do, but I don't know how much we can expose that data
<emeyer> dbaron: I think you can get it with text data
<dbaron> s/text data/text measurement/
<emeyer> fantasai: CLDR doesn't vary by locale, it's ???
<emeyer> florian: It exposes information about the page, not the environment
<dbaron> s/???/something baked into the browser/
<emeyer> emilio: As long as that's the case, it's okay
<emeyer> RESOLVED: adopt a quotes value that, if the parent's quotes computed value is auto, computes the correct quotes for the parent's language, and if the parent's quotes computed value is not auto, inherits that value
<emeyer> florian: I think we should drop match-parent, which doesn't do what we want
<emeyer> astearns: Concerns?
<fantasai> PROPOSED: Drop existing match-parent value
<emeyer> dbaron: How widely implemented is it?
<emeyer> florian: I don't think it is
<emeyer> astearns: Objections?
<emeyer> RESOLVED: drop existing match-parent value
<emeyer> florian: Now, what does auto do? I think there are two different behaviors
<emeyer> …Unless we have an obvious answer, it should be a separate issue

Navigation Menu

Repository navigation

[css-content] Quote character choice must depend on surrounding language, not language of the quotation #5478

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-content] Quote character choice must depend on surrounding language, not language of the quotation #5478

Description

Activity

fantasai commented on Feb 5, 2024

r12a commented on Feb 8, 2024

fantasai commented on Feb 12, 2024

frivoal commented on Feb 20, 2024

r12a commented on Feb 20, 2024

frivoal commented on Feb 21, 2024

frivoal commented on Apr 17, 2024

xfq commented on Apr 17, 2024

svgeesus commented on Jun 12, 2024

css-meeting-bot commented on Jun 12, 2024

frivoal commented on Jun 12, 2024

r12a commented on Jun 13, 2024

jfkthame commented on Jun 13, 2024

fantasai commented on Oct 8, 2026

astearns commented on Oct 19, 2026

tabatkins commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions