Thanks David, Dominik. As API owners I think our job is largely about evaluating interop risk vs. platform benefit. It's hard for me to evaluate the benefit of this feature without synthesis (how big of a problem is webfont fallback in practice?). But it seems clear to me that adding this feature to Chrome matching Safari (but not Firefox) is a net reduction in interop risk compared to the status quo of all three browsers behaving differently due to Chrome's lack of support. So, while we could have all sorts of debate and discussion about what more to do, as-is this passes our I2S bar for me.
LGTM1. Sorry for the long delay. Rick 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 <yoavwe...@chromium.org> >>> wrote: >>> >>>> On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas < >>>> r...@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+unsubscr...@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+unsubscr...@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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY92VqdD8DYmqYqqNVPOMGhAQa1tYZFUfzOQw1qfR0O3oA%40mail.gmail.com.
