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 ?
Le 18/11/2021 à 09:15, Yoav Weiss a écrit :
The fact that we see an order of magnitude more impact from this in
the HTTPArchive than use-counters seems to suggest this is more of a
long-tail problem (which use-counters mask by being page-view based).
Do you have a sense of what breakage may look like?
On Wednesday, November 17, 2021 at 8:57:53 PM UTC+1 Mike Taylor wrote:
On 11/17/21 6:02 AM, Frédéric Wang wrote:
I started to poke through
https://github.com/search?p=5&q=%22-webkit-standard%22&type=Code
<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:
Evernote:
https://github.com/karshih/Notes/blob/edf2d8658db898a4d993a22db62722e2d8e23ee8/accounts/www.evernote.com/100389449/content/ACFB7C02-6642-435C-B739-DBE738BDC66D/content.enml
<https://github.com/karshih/Notes/blob/edf2d8658db898a4d993a22db62722e2d8e23ee8/accounts/www.evernote.com/100389449/content/ACFB7C02-6642-435C-B739-DBE738BDC66D/content.enml>
Some "HTTrack Website Copier":
https://github.com/MicIOE/MicIOE.github.io/blob/533ac9fecef9e407b2f82061304fb2ee113c90a0/micioe/main/www.micioe.com/news/news2/2145.html
<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.,
https://github.com/huanyun-c/egg_linkingLeft/blob/36a00019d54219c07150bdf5fe07445d1d1a221a/app/view/rule/fwxy.ejs#L31-L37
<https://github.com/huanyun-c/egg_linkingLeft/blob/36a00019d54219c07150bdf5fe07445d1d1a221a/app/view/rule/fwxy.ejs#L31-L37>
https://github.com/english5-net/e5-ckeditor5-build/blob/a60acf23729ba6a48671cb3d0136294a26893360/packages/ckeditor5-paste-from-office/tests/_data/list/resume-template/normalized.safari.word2016.html#L3-L9
<https://github.com/english5-net/e5-ckeditor5-build/blob/a60acf23729ba6a48671cb3d0136294a26893360/packages/ckeditor5-paste-from-office/tests/_data/list/resume-template/normalized.safari.word2016.html#L3-L9>
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.
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...
--
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 [email protected]
<mailto:[email protected]>.
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8ab058c3-e8b4-48a9-9bec-5457c6e3c85bn%40chromium.org?utm_medium=email&utm_source=footer>.
--
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 [email protected].
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.
