Remove support for the font-family value "-webkit-standard". This essentially behaves as an alias to the proprietary keyword "-webkit-body" and is only exposed as historical implementation details inherited from WebKit.
This will make Blink more aligned with the spec and with Firefox, but no longer aligned with WebKit. Although not recommended, people can continue to use the proprietary name "-webkit-body" to preserve existing behavior. In March 2020, searching these strings on HTTPArchive gave 2738 matches over ~5 millions (~0.05%). For better accuracy, a use counter was added which is located at the place where this generic name is actually tested and resolved to a more precise name. This counter also excludes other internal uses of that string, as mentioned above. On November 1st, reported measurement was ten times smaller that HTTPArchive (~0.005%): https://chromestatus.com/metrics/feature/timeline/popularity/3987
font-family is exposed via usual CSS DevTools.
No milestones specified
PS: For those interested in that one and other font-family stuff,
there will be a breakout session on day 2 of BlinkOn 15.
-- Frédéric Wang
Contact emails
fw...@igalia.com, ssi...@igalia.comExplainer
None
Specification
https://drafts.csswg.org/css-fonts-4/#font-family-prop
Summary
Remove support for the font-family value "-webkit-standard". This essentially behaves as an alias to the proprietary keyword "-webkit-body" and is only exposed as historical implementation details inherited from WebKit.
Blink component
Blink>Fonts
TAG review
TAG review status
Not applicable
Risks
Interoperability and Compatibility
This will make Blink more aligned with the spec and with Firefox, but no longer aligned with WebKit. Although not recommended, people can continue to use the proprietary name "-webkit-body" to preserve existing behavior. In March 2020, searching these strings on HTTPArchive gave 2738 matches over ~5 millions (~0.05%). For better accuracy, a use counter was added which is located at the place where this generic name is actually tested and resolved to a more precise name. This counter also excludes other internal uses of that string, as mentioned above. On November 1st, reported measurement was ten times smaller that HTTPArchive (~0.005%): https://chromestatus.com/metrics/feature/timeline/popularity/3987
I started to poke through https://github.com/search?p=5&q=%22-webkit-standard%22&type=Code out of curiosity and a few things stand out:
1) Some tools used for archiving / exports appear:
Some "HTTrack Website Copier":
https://github.com/MicIOE/MicIOE.github.io/blob/533ac9fecef9e407b2f82061304fb2ee113c90a0/micioe/main/www.micioe.com/news/news2/2145.html
It's possible the tools were generating the usage, or just
capturing the result of certain pages already using it.
However, the results co-occur a lot with CJK fonts and mso-
properties (MS Office docs saved to web? Outlook emails?). Do we
have a guess at why Chinese documents might pick -webkit-standard
over something else? Is there some kind of layout benefit that we
might break?
i.e.,
Gecko: Shipped/Shipping Firefox does not support this -webkit prefixed value.
WebKit: Neutral (https://github.com/web-platform-tests/wpt/pull/22512#discussion_r399764967) As a general rule, Apple is against removing features if that can break things on the web or their platform. Myles C. Maxfield commented that he is aware of the issue and don't think it's something desirable that these values are web-exposed.
Web developers: No signals It's not clear whether developers are actually aware of this behavior but it was used by a few pages (see compat analysis).
Other signals:
Debuggability
font-family is exposed via usual CSS DevTools.
Is this feature fully tested by web-platform-tests?
Yes
Flag name
Requires code in //chrome?
False
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5639265565278208
This intent message was generated by Chrome Platform Status.
PS: For those interested in that one and other font-family stuff, there will be a breakout session on day 2 of BlinkOn 15.
-- Frédéric Wang
--
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/958f3a2d-c47a-7b37-7a05-46e4d8ace894%40igalia.com.
I started to poke through https://github.com/search?p=5&q=%22-webkit-standard%22&type=Code out of curiosity and a few things stand out:
1) Some tools used for archiving / exports appear:
Some "HTTrack Website Copier": https://github.com/MicIOE/MicIOE.github.io/blob/533ac9fecef9e407b2f82061304fb2ee113c90a0/micioe/main/www.micioe.com/news/news2/2145.html
It's possible the tools were generating the usage, or just capturing the result of certain pages already using it.
However, the results co-occur a lot with CJK fonts and mso- properties (MS Office docs saved to web? Outlook emails?). Do we have a guess at why Chinese documents might pick -webkit-standard over something else? Is there some kind of layout benefit that we might break?
i.e.,
Thanks for taking a look. I'm not sure I have a proper answer to
your question, but some comments below. In any case, maybe we want
to be safer : analyze the pages reporting the counter and rely on
a Finch flag?
Regarding the proprietary -mso properties, they are not affected
by this intent to unship AFAIK.
Links 1, 3, 4 has a font-family with a single -webkit-standard
while link 2 has a quoted '-webkit-standard' value (whether the
name is quoted or not should not make a difference for Blink).
It's indeed possible these pages are affected by this intent if
the inherited font is not the default.
Checking WPT test css/cssom/font-family-serialization-001.html and
also the initial value, it does not seem that WebKit or Blink
serialize "-webkit-standard" name (unless they were already
specified in the document). So I guess authoring tools do that on
purpose, although I can't explain the rationale. Doc 4 has
"Safari" in its name, which suggests it's designed for webkit.
Regarding CJK, we have special behavior on Android for these
characters. And bug 1252383 showed that an internal use of
"-webkit-standard" allowed to work around a Skia bug 12503. Bug
again, I can't explain why someone would need to do it
explicitly...
The @font-face{ font-family:"-webkit-standard"; } in link 3 is
also weird, I'm not sure what's happening when we don't specify an
src...
-- Frédéric Wang
I started to poke through https://github.com/search?p=5&q=%22-webkit-standard%22&type=Code out of curiosity and a few things stand out:
1) Some tools used for archiving / exports appear:
Some "HTTrack Website Copier": https://github.com/MicIOE/MicIOE.github.io/blob/533ac9fecef9e407b2f82061304fb2ee113c90a0/micioe/main/www.micioe.com/news/news2/2145.html
It's possible the tools were generating the usage, or just capturing the result of certain pages already using it.
However, the results co-occur a lot with CJK fonts and mso- properties (MS Office docs saved to web? Outlook emails?). Do we have a guess at why Chinese documents might pick -webkit-standard over something else? Is there some kind of layout benefit that we might break?
i.e.,
Thanks for taking a look. I'm not sure I have a proper answer to your question, but some comments below. In any case, maybe we want to be safer : analyze the pages reporting the counter and rely on a Finch flag?
I think looking at a few dozen random samples of affected pages
by someone who can read these pages and discern (subtle?) breakage
would be useful. If you found anything concerning there, perhaps a
Finch flag would be wise before moving forward.
Regarding the proprietary -mso properties, they are not affected by this intent to unship AFAIK.
Right, just pointing out a co-occurrence that might hint at use
cases or sources.
--
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/8ab058c3-e8b4-48a9-9bec-5457c6e3c85bn%40chromium.org.
-- Frédéric Wang
Hi,
As I explained in yesterday's session, the use counter is placed in FontSelector::FamilyNameFromSettings where the "-webkit-standard" is actually resolved to a more concrete family name. This is the only place in our code where that name is handled specially, so that should be relatively accurate measurement.
On the other hand, an occurence in HTTPArchive (or any other pages) does not mean the name will ever be taken into account. For example with
"font-family: SomePopularFont, -webkit-standard, SomeOtherFont"
it's very likely that SomePopularFont will be used before trying "-webkit-standard", if SomePopularFont is available on the system.
For something like
"font-family: SomeRareOrPendingToLoadWebFont, -webkit-standard"
our code would still try the standard font family as a fallback anyway, so no need to specify it explicitly.
Also, since the standard font is used as the initial value, occurences found in the github pages mentioned by Mike
"font-family: -webkit-standard"
can only have a visible effect if the font-family was changed on an ancestor already (I haven't seen this on these HTML pages, although maybe that was done in an external stylesheet).
Finally, even when "-webkit-standard" is seen by FontSelector::FamilyNameFromSettings (and use counted), this does not mean there is a visible effect. This is what is done:
- On non-Android platforms, a concrete font name is selected from a user preference depending on the ISO script code.
- On Android, it can only have an effect for CJK scripts, where it will rely on Skia to pick a font (testing one CJK character).
Incidentally, this replies a bit to Mike's previous interrogation: this -webkit-standard stuff depends on ISO scripts, and on Android is only relevant for CJK.
Possible breakage is that a different font is selected, with the risk of a completely wrong/different rendering. The use case I can imagine is
<div style="font-family: MyFont">
<div style="font-family: -webkit-standard">SomeCJKContent</div>
</div>
for which the -webkit-standard currently forces selection of a special font for CJK script (user preferrence or calculated via Skia).
Would it be possible to get results of top pages hitting the use counter, so one can analyze them more carefully ? Do we need to do any additional change in Chromium to make that possible ?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f52dc959-aab4-f97b-b47c-42d4416911be%40igalia.com.
Would it be possible to get results of top pages hitting the use counter, so one can analyze them more carefully ? Do we need to do any additional change in Chromium to make that possible ?
chromestatus.com already has this feature, by combining UseCounter with HTTPArchive. It can take a while for this data to be populated though, because of latency in the indexing.
Hi Chris,
Last week Chromestatus was showing wrong results, basically for any feature it was returning matches for all HTTPArchive pages. Now it returns no data at all for -webkit-standard. Not sure if we need to wait more before indexing happens...
Otherwise, I was thinking of something we did for scroll position
values in non-default writing modes in the past [1] i.e. use UKM
to better collect and analyze affected origins and maybe
introducing a finch flag to ship this more safely (the code change
to disable that is one line [2] so that should be easy). But IIRC
we will need help from a Googler for that purpose.
[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/7X2CKPGeEa0/m/7Rau54VwDQAJ
[2]
https://chromium-review.googlesource.com/c/chromium/src/+/3282157
-- Frédéric Wang
--
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/f4dd6049-8221-e881-8979-c9029dc5ae01%40igalia.com.
I wonder if we have metrics about unrenderable characters? I.e. how often we fail to render some text because the glyph isn't present in the selected font? If we did, then I think it would be pretty easy to do a finch trial for changes like this and decide go/no-go based on that data.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fqrpWok%3DB_s2qBacf%2BHZzcJYHiWY3e6OHODQ%2BWiVDXw%40mail.gmail.com.
Hi Rick & Frédéric,On Mon, Nov 22, 2021 at 11:27 PM Rick Byers <rby...@chromium.org> wrote:I wonder if we have metrics about unrenderable characters? I.e. how often we fail to render some text because the glyph isn't present in the selected font? If we did, then I think it would be pretty easy to do a finch trial for changes like this and decide go/no-go based on that data.We used to have a metric to tell us for which Unicode code block no fallback character was found after the primary fonts, user preference font and system fallback, but I think we removed that after it had given us the useful information that these were mostly math symbols and some emoji. For privacy reasons we can't have a metric to track missing glyph coverage for single characters, but the bucketed Unicode block approach worked. To my knowledge we do not (and did not) have metrics on coverage/missing glyphs per selected font.
--
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/958f3a2d-c47a-7b37-7a05-46e4d8ace894%40igalia.com.
-- Frédéric Wang
On Wed, Nov 24, 2021 at 5:21 AM Dominik Röttsches <dr...@google.com> wrote:Hi Rick & Frédéric,On Mon, Nov 22, 2021 at 11:27 PM Rick Byers <rby...@chromium.org> wrote:I wonder if we have metrics about unrenderable characters? I.e. how often we fail to render some text because the glyph isn't present in the selected font? If we did, then I think it would be pretty easy to do a finch trial for changes like this and decide go/no-go based on that data.We used to have a metric to tell us for which Unicode code block no fallback character was found after the primary fonts, user preference font and system fallback, but I think we removed that after it had given us the useful information that these were mostly math symbols and some emoji. For privacy reasons we can't have a metric to track missing glyph coverage for single characters, but the bucketed Unicode block approach worked. To my knowledge we do not (and did not) have metrics on coverage/missing glyphs per selected font.Ok, thanks! Any thoughts on the compat risk of this change? If we spot check 10 HA results and can explain why the change doesn't noticeably break anything on those 10, then I'm guessing that makes this change low enough risk to proceed. But I'm not sure I trust my judgment on that. WDYT?
Thank you Yoav, Rick and Dominik,
Some random remarks/thoughts:
1. First I believe the risk is probably not to have missing characters : At the end, we actually always do try "-webkit-standard" internally as a fallback. Instead, the risk is more to have inconsistent fonts selected (with different style, metrics) for the same text. Say, MyGenericFont would contain basic CJK or emoji or math characters but then would lack some more exotic ones which would then be taken by another MySpecializedFont.
2. That said, I can't explain why how " -webkit-standard" would
really guarantee anything against the inconsistent font
selected. Maybe instead this -webkit-standard value is used to
to explicitly select a preferred font per Unicode scripts (on
non-Android platforms) or to resolve CJK scripts specially (on
Android).
3. My guess is more that these usages are really generated by
tools (as
Mike mentioned) not introduced on purpose by authors. Indeed,
the result of using -webkit-standard explicitly is really hard
to predict.
4. In any case, unshipping support for explicit
-webkit-standard may affect the selected font, but does not
change the selection via explicit -webkit-body or for
initial/fallback font (I sent an email to clarify that, as that
was lost in the initial email)
5. On Android, the feature only has effect for CJK scripts and
it was previously mentioned usage might be on purpose. But it
seems very low on that platform per Rick's stats so that no
longer seems a concern to me.
6. I suspect all these -webkit-* stuff were introduced by Apple and used in their product, so it does not seem surprising to have higher usage on mac.
7. Also, Mike mentioned co-occurence with mso- properties (used by enterprise's products?) so that may explain the weekday analysis by Rick.
In any case, I shared with Sonia (cc'ed) the results provided
by Yoav. She will try and analyze them in more details and we
will come back to this thread when we are able to explain things
more concretely.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN6muBtoJAiCcMT-DBOkR3VyD_uW_%3D%3DCMGo-CJrO8PjqwXObqA%40mail.gmail.com.
-- Frédéric Wang
--
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/CAFUtAY9CsRJbP%3DC%3D34MbMGKL3EWTh5ODORnRHN81W7ADSzJy-A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/45a76684-da7f-7677-9e17-8f1e1441d67d%40chromium.org.
--
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/CAJUhtG_0RxmvOjTifLBWjEVfSBWtmn%2Bnp2uGfdj-VVEwtGEhVQ%40mail.gmail.com.
-- Frédéric Wang