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.
