- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 15:40:24 +0000
- To: public-css-archive@w3.org
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`
<details><summary>The full IRC log of that discussion</summary>
<emeyer> florian: The internationalization people have told us what they want<br>
<dbaron> s/five other ways/five other ways, whether computed style from font relative units or layout/<br>
<emeyer> …A quote should inject at the start and end the quotation marks of the parent's language, not the element's language<br>
<emeyer> …But if you nest them, the innermost should use the quote of the outermost quotation style<br>
<emeyer> …In the general default case, you have to lock in the quote style and carry it down the ancestor chain<br>
<emeyer> …We think we've come up with some approaches, but they could be performantly painful<br>
<emeyer> The old-fashioned way was to supply a bunch of pairs of strings<br>
<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<br>
<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<br>
<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<br>
<florian> q { quotes: auto; }<br>
<florian> q::before,<br>
<florian> q::after,<br>
<florian> q * { quotes: match-parent; }<br>
<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"<br>
<kizu> +q<br>
<emeyer> …This does put a `q *` selector in UA stylesheets<br>
<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<br>
<astearns> ack kizu<br>
<emeyer> kizu: If we had a content pseudo-element, we might use this for quotes?<br>
<emeyer> fantasai: No, that wouldn't work, because inheritance is before box construction<br>
<emeyer> florian: 2. Uses different keywords not specced yet, but let's call one 'parent-language'<br>
<emeyer> …This is like 'auto', but it computes to the set of strings the language needed, and inherits as those strings<br>
<florian> q { quotes: parent-language; }<br>
<florian> q q { quotes: inherit; }<br>
<emeyer> s/but/except/<br>
<emeyer> …If you're a quote element, you lock on your parent, unless you're nested, in which case you inherit the strings<br>
<emeyer> …I don't know which UAs would prefer, I suspect the latter<br>
<emeyer> …If neither works, what do we do??<br>
<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<br>
<emeyer> florian: Say again?<br>
<emeyer> dbaron: 'parent-language-or-auto', uses the logical value 'auto' would use, otherwise inherits<br>
<kbabbitt> q+<br>
<emeyer> florian: It computes to itself and stays as is?<br>
<emeyer> dbaron: All I need auto for is it's the initial value of the property<br>
<emeyer> …So on the outer element it would look at the parent to get the language<br>
<emeyer> (crosstalk)<br>
<emeyer> …Then if you have a nested q element, you look at the parent, it isn't auto, so you just inherit it<br>
<emeyer> florian: I agree that would also work<br>
<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<br>
<emeyer> …Great, now we have three solutions; which is most implementable?<br>
<astearns> ack kbabbitt<br>
<emeyer> kbabbitt: I vote against putting a universal selector in a UA stylesheet, as it will likely trigger a lot of style invalidation<br>
<emeyer> dbaron: I would defer to Rune or Anne for their thought on option 2<br>
<dbaron> s/or Anne/or Ian/<br>
<emeyer> florian: internationalization is reluctant about option 2, since you have to remember to put a bunch of non-obvious things in stylesheets<br>
<emeyer> …I think David's thing is closer to what they want<br>
<emeyer> dbaron: That's true, the downside is it's more magical and more weird<br>
<emeyer> …We'd need a name<br>
<emeyer> fantasai: match-parent?<br>
<emeyer> dbaron: noooooooooo<br>
<emeyer> florian: It doesn't quite work because it has to do different things<br>
<emeyer> fantasai: Another one is to call one value normal and one auto?<br>
<emeyer> dbaron: We could name for what it isn't for instead of what it does<br>
<TabAtkins> for-q<br>
<emeyer> florian: Bikeshedding aside, between option 2 and 3, which is better?<br>
<TabAtkins> [me yelling at the dude who just sideswiped me] "FOR-Q"<br>
<emeyer> futhark: I'm a little confused about the options, but avoiding the universal is good<br>
<fantasai> 1. q { quotes: auto; }<br>
<fantasai> q * { quotes: match-parent; }<br>
<fantasai> 2. q { quotes: parent-language; }<br>
<fantasai> q q { quotes: inherit; }<br>
<emeyer> dbaron: Option 2 had a `q q` selector<br>
<fantasai> 3. q { quotes: magic; }<br>
<emeyer> …option 3 has only `q` because all the nmagic is in the value<br>
<emeyer> futhark: I think I prefer that<br>
<ChrisL> q {quotes: anon }<br>
<emeyer> florian: All the magic happens at compute time, which is a different concern<br>
<emeyer> futhark: Does it have to walk up the tree?<br>
<emeyer> dbaron: It involves lookiong at the parent and maybe pulling stuff down<br>
<emeyer> futhark: That sounds the best option<br>
<emeyer> florian: So we can go back to bikeshedding optoin 3<br>
<emeyer> jfkthame: Can we just not change the value of auto?<br>
<emeyer> florian: ??<br>
<emeyer> iank_: That would change the existing quotes property?<br>
<emeyer> florian: The value now is only strings, there is no auto<br>
<astearns> s/??/we could use auto, but then we need an initial value - maybe normal?/<br>
<emeyer> fantasai: But everyone's shipping auto<br>
<emeyer> florian: What does it do?<br>
<emeyer> fantasai: [missed]<br>
<emeyer> florian: So auto does something and has to be kept and we need a new name<br>
<emeyer> fantasai: capture?<br>
<emeyer> florian: Maybe<br>
<emeyer> astearns: I prefer going back to the issue while resolving on behavior<br>
<dbaron> quotes: outer-language ?<br>
<fantasai> It wouldn't be outer language if you nested three languages though<br>
<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.<br>
<bkardell_> I'm good with that<br>
<emilio> q+<br>
<emeyer> emilio: Doesn't this require you to walk arbitrary ancestors?<br>
<emeyer> florian: You only have to look at the parent<br>
<emeyer> emilio: This would only apply to the quote element?<br>
<emeyer> fantasai: You could put it on any element<br>
<emeyer> dbaron: This will mostly work for style computation and inheritance<br>
<emeyer> …The special inheriatnce rules here will only require looking up one step for each element<br>
<emeyer> emilio: But it would expose ?? data for the language<br>
<emeyer> dbaron: Yes<br>
<fantasai> s/??/CLDR/<br>
<emeyer> emilio: Okay, I think it might be fine<br>
<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<br>
<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<br>
<emeyer> dbaron: I think you can get it with text data<br>
<dbaron> s/text data/text measurement/<br>
<emeyer> fantasai: CLDR doesn't vary by locale, it's ???<br>
<emeyer> florian: It exposes information about the page, not the environment<br>
<dbaron> s/???/something baked into the browser/<br>
<emeyer> emilio: As long as that's the case, it's okay<br>
<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<br>
<emeyer> florian: I think we should drop match-parent, which doesn't do what we want<br>
<emeyer> astearns: Concerns?<br>
<fantasai> PROPOSED: Drop existing match-parent value<br>
<emeyer> dbaron: How widely implemented is it?<br>
<emeyer> florian: I don't think it is<br>
<emeyer> astearns: Objections?<br>
<emeyer> RESOLVED: drop existing match-parent value<br>
<emeyer> florian: Now, what does auto do? I think there are two different behaviors<br>
<emeyer> …Unless we have an obvious answer, it should be a separate issue<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5478#issuecomment-2163354212 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 15:40:25 UTC