It's a shame to me to be holding back interop on the case of fonts having the superscript or subscript glyphs out of fear for the case where they don't. Perhaps we can treat the case of font-variant-position being used with fonts that lack the glyphs as a site bug that we can work to address independently? Personally, as long as Safari and Chrome behave the same here, I'm skeptical that the lack of synthesis would turn into a non-trivial problem in practice.
If we were to ship without synthesis, would it be practical to have a UseCounter which measures how often we see font-variant-position used with a font that lacks the glyphs? This would tell us how important the bug is. If it remains really rare, then IMHO we've probably already wasted more energy worrying about it than it's worth. If it becomes more common over time then I think we have a variety of options, chiefly implementing synthesis, but also raising awareness with devtools features, UKM-based site-specific outreach, and possibly even interventions of some form (like using a fallback font?). Rick On Fri, Feb 24, 2023 at 9:22 AM David Baron <[email protected]> wrote: > On Fri, Feb 24, 2023 at 5:49 AM Yoav Weiss <[email protected]> wrote: > >> On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas <[email protected]> >> wrote: >> >>> There's a CSSWG issue about this topic in particular: >>> https://github.com/w3c/csswg-drafts/issues/7441 >> >> >> Is this something that can be put on the agenda for the CSSWG to discuss? >> > > I added this to the group's (long) agenda backlog. > > (Also, a few other relevant CSSWG issues I found were > w3c/csswg-drafts#1888 <https://github.com/w3c/csswg-drafts/issues/1888>, > w3c/csswg-drafts#2796 <https://github.com/w3c/csswg-drafts/issues/2796>, > w3c/csswg-drafts#5225 <https://github.com/w3c/csswg-drafts/issues/5225>, > w3c/csswg-drafts#5518 <https://github.com/w3c/csswg-drafts/issues/5518>, > and also some minutes from July 2020 > <https://lists.w3.org/Archives/Public/www-style/2020Aug/0006.html#:~:text=vertical%2Dalign%3A%20super%20and%20font%20metrics> > and from September 2020 > <https://lists.w3.org/Archives/Public/www-style/2020Sep/0023.html#:~:text=should%20we%20add%20the%20super%20and%20subscript> > .) > > One other point that I missed yesterday is that one of the key reasons > that these new properties can't be used for the default rendering of <sup> > /<sub> elements is that they don't support *nested* > subscript/superscript. One of the goals of the 2011 discussion I cited > above was to solve that issue in a reasonable way. All of the current ways > of doing typographically correct super/subscripts only support a single > level of super/subscript, and not nesting. This works for the majority of > use cases, but not all. > > -David > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3ht%3DrZwCtQoUWJXR4avCaY2TvAa9NMiYAfMsdan94wzVw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3ht%3DrZwCtQoUWJXR4avCaY2TvAa9NMiYAfMsdan94wzVw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fMAG16L3_KweN4FnnSnVsfevxHyH2qfdN1B42ef1Xmg%40mail.gmail.com.
