Intent to Ship: Remove font-family -webkit-standard

[Frédéric Wang]

Contact emails

fw...@igalia.com, ssi...@igalia.com

Explainer

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

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

[Mike Taylor]

On 11/16/21 9:46 AM, Frédéric Wang wrote:

Contact emails

fw...@igalia.com, ssi...@igalia.com

Explainer

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:

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

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.

[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:

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?

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

[Mike Taylor]

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.

[Yoav Weiss]

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?

[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 ?

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

[Chris Harrelson]

On Thu, Nov 18, 2021 at 1:16 AM Frédéric Wang <fw...@igalia.com> 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.

 

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.

[Frédéric Wang]

Le 18/11/2021 à 21:29, Chris Harrelson a écrit :

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

[Yoav Weiss]

Based on +Rick Byers's HA for webcompat document, I just ran the following query:
```

SELECT url FROM `httparchive.latest.pages_mobile`

WHERE JSON_EXTRACT(payload, "$._blinkFeatureFirstUsed.Features['3987']") IS NOT NULL

```

Results are here.

In short, there are 191 pages that touch this usecounter, out of 7655542 pages in that table. (or ~0.0025% of pages)

This resolves my previous concerns about HA showing an order of magnitude more usage than our chromestatus use counter data.

While digging into UKM data could be interesting, it'd take some time to gather, so it might be sufficient to take a random sample from the HA list and see what the impact on those sites would be.

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

[Rick Byers]

+1 for taking a random sample (eg. 10) of pages from the HTTPArchive UseCounter list and trying to understand how it's being used and what breakage would result (especially on a Mac, see below).

I also looked at per-platform breakdowns (Google internal data, sorry) and found:

• Android WebView usage is very low (~0.0003%). -webkit-isms sometimes feature in Android native apps so I wanted to verify we didn't see high usage. This is so low as to likely be irrelevant I think.
• Mac is much higher than Windows - eg. 0.01-0.02% for Mac vs. 0.002%-0.004% for Windows
• There's a pronounced weekday pattern with Mac/Windows usage about doubling M-F relative to Sat/Sun
• Android usage is low (~0.001%) with no weekday pattern

This suggests to me perhaps some enterprise or line-of-business application may be using it. But if we have evidence that the change in behavior is almost always subtle (eg. font metrics) not significant (eg. missing text) then I think this is probably low enough risk to just try.

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.

Rick

[Dominik Röttsches]

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.

Dominik

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.

[Rick Byers]

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?

[Frédéric Wang]

Hi,

I noticed the "motivation" was removed from the email draft generated by chromestatus. So let's put it here:

"The "-webkit-standard" name is used internally to describe a default font family that can be configured via a user preference. It's implicitly used internally (e.g. for initial or fallback font) or explicitly by authors via the proprietary name "-webkit-body". However because of how this is implemented, authors can also just specify "-webkit-standard" and obtain similar web-exposed behavior. Removing special behavior for these proprietary value will improve alignment with the CSS specifications and Firefox."

Just to make sure we are all on the same page, this intent is to remove this special behavior for explicit "-webkit-standard" families. The internal use for default/fallback fonts as well as support for "-webkit-body" are out of the scope of this intent.

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

[Dominik Röttsches]

On Wed, Nov 24, 2021 at 4:30 PM Rick Byers <rby...@chromium.org> wrote:

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?

Yes, I think that's fair, even thorough I would say, as I trust the low numbers of occurence. I am not sure what guarantees authors who used -webkit-standard were expecting. Generic family names, including system-ui etc. are safer to use. Looking at a few examples from HA might shed some light on what the idea of the usage was. 

Dominik

[Frédéric Wang]

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

[Frédéric Wang]

Le 25/11/2021 à 11:12, Frédéric Wang a écrit :
>
> 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.
>

One more thought: in Mike's example, we typically have the value alone 
(without other family names) like "font-family: -webkit-standard". This
may suggest it is just used for resetting to default font, but I believe
"font-family: initial" would have the same result.

--
Frédéric Wang

[Rick Byers]

Interesting, thanks. If missing glyphs isn't really an issue, then the compat risk is much lower. A cosmetic impact that makes a page in Chrome look like how it looks in Firefox is IMHO a good thing (helps raise awareness of the poor cosmetics without actually preventing usage). So, while doing some quick analysis of a few cases sounds like a good idea to me just to validate some assumptions here, I wouldn't suggest investing too much time into that. 

Rick

[Mike Taylor]

(sorry to disappear on PTO for much of this discussion)

+1 to what Rick is suggesting here, the risk is likely low but worth spending an hour or two to verify we're not breaking some (non-obviously) important usage.

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

[Mike West]

Friendly-pinging Mike's ping of Rick's suggestion. Is that analysis something you can spend some time on before we ship this?

-mike

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.

[Frédéric Wang]

Sorry for the delay to come back to you. I had started to check a few pages provided by Yoav manually and it seems similar pattern shows up: the counter is hit when the page specifies "font-family: -webkit-standard;" or (more rarely) "font-family: -webkit-standard, serif;" on some elements (*). This is similar to what Mike found on github and the same remarks apply, in particular:

- that may theorically change the rendering, but more investigation is needed to be sure.
- -webkit-standard would internally be used as a fallback anyway so there is no risk of missing glyphs if we ignore user-specified one.

I discussed with Sonia Singla (coding experience student at Igalia) and she was interested in double-checking a few pages visually on macOS (since that's where the main concern is) to see if anything is broken, as well as finishing the work of landing this patch. We will comment further when this is done.

(*) For completeness, see the attached output of the following bash command:

for url in `cat $TEXT_FILE_WITH_THE_LIST_OF_URLS`; do
    echo $url
    $CONTENT_SHELL --run-web-tests $url 2>&1 | grep FamilyNameFromSettings | sed 's/.*FontSelector::FamilyNameFromSettings /  /'
    echo
done

with the following patch logging the font-family when the counter is hit:

--- a/third_party/blink/renderer/platform/fonts/font_selector.cc
+++ b/third_party/blink/renderer/platform/fonts/font_selector.cc
@@ -49,6 +49,7 @@ AtomicString FontSelector::FamilyNameFromSettings(
     UseCounter::Count(
         use_counter,
         WebFeature::kFontSelectorCSSFontFamilyWebKitPrefixStandard);
+    LOG(INFO) << "FontSelector::FamilyNameFromSettings " << font_description.Family().ToString().Utf8().data();
   }

[Sonia Singla]

Hi Everyone,

So I tested some pages on mac and did not find any visual changes or anything is breaking for the links I tested. I updated the sheet[0]. Once we get the approvals to remove the property, I will be working on patches

Sonia

CE Intern

Igalia

[Sonia Singla]

Link to spreadsheet[0]

[0] https://docs.google.com/spreadsheets/d/1lChXA87u2r7yuBdfJu283UDsGhRGqT9ol2rVwVOQw0o/edit?resourcekey=0-yCKFjRfFk0RYeNm-d6DvFw#gid=1758573992

[Mike Taylor]

Hi Sonia,

Could you please make this spreadsheet public?

thanks,
Mike

[Yoav Weiss]

The public equivalent is https://docs.google.com/spreadsheets/d/1WZTRBujaaFrtUaRnBOoVYzJkZuColXFN-GgToF6nR5Q/edit#gid=73457229

[Yoav Weiss]

LGTM1

Thanks for doing the work of verifying this is not a breaking change!

[Mike Taylor]

Awesome - appreciate the extra due diligence here.

LGTM2

[Mike West]

LGTM3.

-mike

[Rick Byers]

Thank you! 

+1 to it sounding like this will be fine. LGTM4

Of course we'll need to keep an eye out for regressions being filed during dev/beta but we should be able to rely on any such bug getting routed quickly to you Sonia as a result of bisecting. Don't hesitate to reach out to any of us if you get a report of a regression and are unsure what to do about it!

Rick

[Joe Medley]

Is this in 98?

[Frédéric Wang]

Patch is under review but has not landed yet.

Le 21/12/2021 à 21:02, 'Joe Medley' via blink-dev a écrit :
> Is this in 98?

[Joe Medley]

Please update the status entry as soon as you know. (That will inform me so that I know which beta post to mention it in.)

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Frédéric Wang]

Done. Will be in 99 https://chromiumdash.appspot.com/commit/43387cbc83601f713bcdbb05b9f07da955ae455e

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