On Thu, Nov 18, 2021 at 1:16 AM Frédéric Wang <[email protected]> wrote:
> 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 ? > 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. > > > 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 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 >> >> 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., >> >> >> 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 >> >> 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]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f52dc959-aab4-f97b-b47c-42d4416911be%40igalia.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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-2AeWMtMK0fGNBMWOMTAZ1QpzUO833G4Wn-2%3D5OvOE3g%40mail.gmail.com.
