We decided to ship font-variant-position without adding a metric measuring whether the feature is applied against a correct font because of difficulties determining a stable document state at the shaping level, for details, see https://docs.google.com/document/d/1dYiljb9pJmWtEIulsse_jzxJwLh3F14Y_X6WbHfETXg/edit?usp=sharing&resourcekey=0-6TIx4OqLWmKBuzv3yR-qRA .
On Wednesday, May 31, 2023 at 5:39:03 PM UTC+2 Daniel Bratell wrote: > LGTM3 > > /Daniel > On 2023-05-31 17:38, Mike Taylor wrote: > > LGTM2 > On 5/31/23 10:30 AM, Rick Byers wrote: > > 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 <dba...@chromium.org> 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 <dr...@google.com> >> 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 <rby...@chromium.org> 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 <dba...@chromium.org> >>>> wrote: >>>> >>>>> On Fri, Feb 24, 2023 at 5:49 AM Yoav Weiss <yoav...@chromium.org> >>>>> wrote: >>>>> >>>>>> On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas < >>>>>> re...@igalia.com> 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 blink-dev+...@chromium.org. >>>>> 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 blink-dev+...@chromium.org. >>>> 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 blink-dev+...@chromium.org. > 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 > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-SQGewKUSrL0MGTXh_L3DU_RSfah2t8SrS8K3FPaeR2g%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fdd2801f-e6b6-420e-bac7-cb902cee342an%40chromium.org.
