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