Yes, 100%. Very good point, I was definitely over-simplifying the measurement challenge. Thanks David!
On Tue, May 30, 2023, 5:47 p.m. David Baron <[email protected]> wrote: > I was trying to avoid being too specific about what would be worth > measuring both because I haven't taken the time to think through all the > details, and because other folks on this thread have a lot of domain > expertise that can help figure out what makes sense. I just wanted to > point out that if you are measuring stuff, it's worth considering that it > may be useful to measure something about usage of system versus downloaded > fonts in order to understand variation between machines (which I agree is > at least mostly variation between platforms). > > -David > > On Tue, May 30, 2023 at 11:44 AM Dominik Röttsches <[email protected]> > wrote: > >> Hi David and Rick, >> >> 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. >> >> >> I think expectations as to what should the browser do vs. what is >> reasonably expected of site owners in terms of font selection and visual >> delivery is on a spectrum (font fallback being a similar case). >> In the case of using font-variant-position, I tend to agree with Rick: >> I'd consider using font-variant-position without a suitable font is a site >> bug. Safari seems to be of the same opinion by shipping >> font-variant-position without synthesis. >> >> 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?). >> >> >> It's difficult to measure the visual end result accurately: >> Only at shaping time we know exactly which font binary is used. This in >> HarfBuzzShaper and we can determine whether the `sups` and `subs` >> OpenType features >> <https://learn.microsoft.com/en-us/typography/opentype/spec/features_pt#subs> >> are >> requested (we would need extra code for determining whether these features >> were requested through font-variant-position: or font-feature-settings). >> Then we can determine whether the font has such a feature in its shaping >> tables. The difficulty is: We reach the shaping code lots of times for >> every relayout or web font arriving. So initially, we may shape with a >> fallback font before the web font arrives, which affects the measurement >> result. Measuring in shaping is not synchronized with a stable layout stage >> or something like a "done" state of the page. So we could get to an >> approximation, but in shaping we can't currently determine what's the last >> state that "stayed" and was perceived by the user. >> >> David wrote: >> >>> 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.) >> >> >> I do agree this feature is most meaningful in combination with web fonts. >> Or even more specifically: Selecting font-variant-position needs to be >> carefully synced with the selected font and making sure the exact font has >> high chances of getting loaded. >> Do I understand correctly you suggest measuring font-variant-position >> usage with system fonts vs. web fonts because of the differences between >> machines? Or did you also mean platforms? >> The system font set used from the web is relatively stable between >> machines, meaning: Windows fonts are usually similar across machines (when >> it comes to those selected from the web), so are Mac fonts. >> >> In any event, I did a quick check: >> Mac: Helvetica, Times, and Courier New on Mac, and as far as I can tell, >> neither has a specific superscript or subscript OpenType or AAT font >> feature. >> Windows: Out of Arial, Courier, Times, Verdana only Verdana has subscript >> glyphs (no superscript), the others do not have such a feature. >> >> Bottom line: >> I am with Rick on shipping this and considering a lack of glyph support >> up a site bug. >> Depending on feedback from API owners, if needed, we can measure an >> approximation of selection of the feature vs. support in the font. >> >> As is, this measurement may read too high (see above: initial shaping >> with fallback font), but potentially we can filter that measurement and >> only report selection of the feature vs. support in a successfully loaded >> web-font. Development of such a measurement takes from 2 days to 9 days, >> depending on complexity (very basic, no distinction of >> font-feature-settings and font-variant-position, no distinction of system >> fonts to complex: distinguish font-feature-settings from >> font-variant-position, distinguish system fonts, web fonts). >> >> >> Dominik >> >> >> >> On Wed, May 24, 2023 at 5:41 PM 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/CAFUtAY9fMAG16L3_KweN4FnnSnVsfevxHyH2qfdN1B42ef1Xmg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fMAG16L3_KweN4FnnSnVsfevxHyH2qfdN1B42ef1Xmg%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/CAFUtAY-SQGewKUSrL0MGTXh_L3DU_RSfah2t8SrS8K3FPaeR2g%40mail.gmail.com.
