- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Aug 2023 16:27:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `font-synthesis: super`, and agreed to the following:
* `RESOLVED: Add font-synthesis-position as defined in https://github.com/w3c/csswg-drafts/issues/7441#issuecomment-1444461111 except 'auto' means synthesis is required (not merely allowed)`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: font-synthesis: super<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7441<br>
<fantasai> astearns: jfkthame, can you take this one?<br>
<fantasai> jfkthame: I agree there's a problem here, but unsure whta exactly is being proposed as a way forward<br>
<fantasai> jfkthame: crux seems to be that it's not possible to tell whether superscript/subscript glyphs will be synthesized or not if unavailable<br>
<fantasai> jfkthame: adding 'font-synthesis-position' doesn't solve the real problem here<br>
<fantasai> fantasai: can you outline the problem?<br>
<fantasai> jfkthame: font-variant-position is supposed to apply superscript/subscript font features if available<br>
<fantasai> jfkthame: spec suggests that a browser may synthesize reduced+shifted glyphs if the OT feature doesn't actually support the characters that are present<br>
<fantasai> jfkthame: a lot of fonts only have support for a small minority of characters<br>
<fantasai> jfkthame: but whether the browser will or won't do synthesis is left up to the implementation<br>
<fantasai> jfkthame: which means authors can't use font-variant-position because you won't know if it has an effect or not<br>
<astearns> ack dbaron<br>
<fantasai> dbaron: I think maybe the idea I was thinking at the time was, if we had font-synthesis-position<br>
<fantasai> dbaron: then an engine that supported synthesis would support that value of font-synthesis<br>
<fantasai> dbaron: and therefore you could use @supports to detect whether synthesis was supported<br>
<fantasai> dbaron: whereas engine that didn't support synthesis of super/subscripts wouldn't support that value of font-synthesis because nothing to control<br>
<fantasai> dbaron: since synthesis wasn't supported in the first place<br>
<fantasai> dbaron: that way you can use @supports queries to detect synthesis support for font-variant<br>
<fantasai> dbaron: through the addition of a font-synthesis value that controlled it<br>
<florian> q+<br>
<fantasai> This makes sense to me, fwiw.<br>
<fantasai> astearns: So if you're using super/subscript for semantic purposes<br>
<fantasai> astearns: you could check whether font-synthesis-position is supported<br>
<fantasai> astearns: and know that it's OK to use it, because there will be fallback synthesis that will preserve semantics<br>
<fantasai> astearns: but if not there, you know that you need to fiddle with the glyphs yourself to make sure the semantic meaning is preserved<br>
<astearns> ack florian<br>
<fantasai> florian: Minor related point, for this proposal of dbaron's to be reliable<br>
<fantasai> florian: we need a tweak to the text<br>
<fantasai> florian: currently we say that the browser "should" synthesize, we need to take it to "must"<br>
<fantasai> florian: can't allow a UA to do it *sometimes*<br>
<fantasai> florian: but I support dbaron's proposal<br>
<fantasai> dbaron: it doesn't help for engines that already support synthesis but don't support the new value<br>
<fantasai> dbaron: e.g. Gecko already does the synthesis, can't detect it right now<br>
<fantasai> dbaron: but Gecko could implement this, which would make synthesis detectable<br>
<fantasai> astearns: jfkthame, thoughts?<br>
<fantasai> jfkthame: I think that seems reasonable<br>
<fantasai> jfkthame: I think it would be nice to see a proposed spec wording<br>
<fantasai> jfkthame: to make it explicit as to what happens<br>
<fantasai> jfkthame: but I don't have any problem in principle with this way forward<br>
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/7441#issuecomment-1444461111<br>
<TabAtkins> fantasai: I don't htink the specific wording is that complex<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: Chris outlined the exact text we'd add<br>
<TabAtkins> fantasai: The only thing we need ot make clear is if we support this property, you *will* perform synthesis for font-variant-position when it's needed. You don't have the option to not do it.<br>
<TabAtkins> fantasai: Taht's all we need to add to make this work.<br>
<emilio> fantasai: we'd add another prop and another value to the shorthand, and UAs must support it<br>
<emilio> ... if they implement that prop<br>
<fantasai> florian: Given backlog of edits, I think we can resolve on it, and if anyone is unhappy they can say so before the edit lands<br>
<fantasai> astearns: Does that work?<br>
<fantasai> jfkthame: sounds fine<br>
<fantasai> jfkthame: main change in Chris's comment, 'auto' value means synthesis is *allowed* and instead we'd say is *required* if glyphs are missing<br>
<fantasai> astearns: so playing out the future where we have an engine that does super/subscript synthesis now<br>
<fantasai> astearns: decides they don't want to do synthesis anymore, they drop the property?<br>
<fantasai> florian: yes<br>
<fantasai> chrishtr: so spec would require synthesis<br>
<fantasai> chrishtr: so chrome would no longer be spec compliant?<br>
<fantasai> fantasai: No, you're mixing up font-variant-position and font-synthesis-position<br>
<fantasai> chrishtr: so new thing to solve this issue<br>
<fantasai> dbaron: we define the property so that it's not mandatory to implement, but if you implement has to correspond to this other feature<br>
<fantasai> florian: nothing's ever mandatory in CSS, but if you implement `font-synthesis-position`, you must implement font synthesis<br>
<fantasai> chrishtr: did drott's comments get answered in the issue?<br>
<fantasai> astearns: ...<br>
<fantasai> chrishtr: only applies to font-variant-position?<br>
<fantasai> florian: UA stylesheet uses different things to simulate superscripts and subscripts, so conceptually related but technically not<br>
<fantasai> florian: you can override that in CSS, but unless you do that, not relevant<br>
<fantasai> chrishtr: Second question was about feature detection<br>
<fantasai> fantasai: we're enabling feature detection by adding this property<br>
<fantasai> @supports (font-synthesis: position) { ... do stuff with font-variant-position here ... }<br>
<fantasai> chrishtr: so if we resolve to add this, then Gecko because they do synthesis, they ship this property<br>
<fantasai> chrishtr: then developers would be able to reliably condition use of font-variant-position on support for font-synthesis-position<br>
<fantasai> chrishtr: so can do it reliably or not<br>
<fantasai> fantasai: yes, exactly<br>
<fantasai> chrishtr: OK! seems fine to me, thanks for walking me through it<br>
<fantasai> astearns: proposed resolution is to accept Chris's formulation of font-synthesis-position, but make it so that 'auto' forces synthesis intead of making it allowed<br>
<fantasai> chrishtr: that would resolve Florian's comment at the end of the issue?<br>
<fantasai> florian: correct<br>
<fantasai> astearns: you're looking to preserve meaning, so you know that the syntax will be reliable<br>
<fantasai> s/syntax/feature/<br>
<fantasai> astearns: OK, any objection to proposed resolution?<br>
<fantasai> RESOLVED: Add font-synthesis-position as defined in https://github.com/w3c/csswg-drafts/issues/7441#issuecomment-1444461111 except 'auto' means synthesis is required (not merely allowed)<br>
<fantasai> astearns: Anything else on this one?<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7441#issuecomment-1680918811 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 August 2023 16:27:19 UTC