I also think that synthesizing is a core feature of this CSS property: Without synthesizing, the same functionality can also be achieved using plain `font-feature-settings`. Using `font-variant-position` is nicer, sure.
But what happens if the requested webfont cannot be loaded for whatever reason, and the page is rendered using a fallback system font, is very much something that the current Chrome implementation of `font-variant-position` doesn't solve in any way: It will just render the text using normal glyphs, which is very confusing if they're supposed to be superset glyphs. For example, go to the MDN font-variant-position page <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position#result> and look at the "Result" section in Chrome 117+: Even though the browser supports `font-variant-position` now, the text there is completely rendered using "normal" glyphs (assuming your system font doesn't have sup/sub glyphs) and there is not the slightest indication that the text is supposed to be in super/subscript. A compromise that would work well in my eyes is to at least synthesize if we detect that the rendered font doesn't have *any superscript/subscript glyphs at all*. That might be easier to detect in OpenType fonts than checking for the existence of every single rendered glyph? On Thursday, 17 August 2023 at 14:00:57 UTC+2 Jonathan Kew wrote: > Note that the CSS Fonts 4 spec *requires* the browser to synthesize > appropriate scaled/shifted glyphs if the font does not provide them: > > > In the case of OpenType fonts that lack subscript or superscript glyphs > for a given character, user agents *must* synthesize appropriate > subscript and superscript glyphs. > > (see https://drafts.csswg.org/css-fonts-4/#font-variant-position-prop) > > On Tuesday, 4 July 2023 at 18:23:14 UTC+1 Munira Tursunova wrote: > >> 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/26c73025-f4c3-415b-869a-b45e2ea377adn%40chromium.org.
