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
<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/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>.
