I think it's worth noting that lack of interop here could take two different forms: (1) different behavior in different browser engines and (2) different behavior on different machines in the same browser engine, because of different system font availability. Some of the more advanced font capabilities in CSS mostly make sense only with downloadable fonts and not with system fonts -- and the choices we make regarding synthesis may affect whether this falls into that bucket of capabilities.
So if it makes sense to add use counters to understand the compatibility implications here, I think it may be worth adding what we would need to understand the breakdown of how many sites are using this in a way that (a) is interoperable across browsers/machines versus (b) is broken in some browsers and working on others versus (c) is broken on some machines and working on other machines, even using the same browser. I suspect this would mean something like measuring how often we see font-variant-position used with a system font versus a downloadable font. (This might also need to be recorded along with the data on whether the font has or lacks the superscript/subscript glyphs, because the intersection of the two might be interesting.) -David On Wed, May 24, 2023 at 10:41 AM Rick Byers <[email protected]> wrote: > 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/CAG0MU3iOuB8nq2M6nF9kiFsVfJRCfsVkDQy%3D01c5kenfHZUiAg%40mail.gmail.com.
