Intent to Prototype: Deprecated and remove font-family: -webkit-pictograph

41 views
Skip to first unread message

Frédéric Wang

unread,
Aug 13, 2021, 8:23:59 AMAug 13
to blink-dev

Contact emails

fw...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-fonts/#font-family-prop

Summary

Deprecate and remove special handling of the <family-name> "-webkit-pictograph" which selects a font from the corresponding user preference. In Chromium, the defaults are:

- Apple Color Emoji on macOS (and iOS/WebKit)

- Segoe UI Symbol on Windows

- Times New Roman on Linux

- Noto Color Emoji on ChromeOS

- This feature is not implemented on Android.

Blink component

Blink>Fonts

Motivation

- Remove non-standard property inherited from WebKit's implementation.

- Improve spec conformance and cleanup existing font-family code.

- Prepare for future implementation of font-family e.g. a replacement would be "font-family: emoji"


Initial public proposal



TAG review



TAG review status

Not applicable

Risks



Interoperability and Compatibility

This feature was implemented by Apple in 2011 before the Blink fork and is still implemented in WebKit. It has never been implemented in Firefox.

A HTTPArchive search from March 2020 provided 1903 pages out of ~5millions (i.e. 0.0003806%). I'm adding a user counter to actually measure when a -webkit-pictograph font is actually resolved to the corresponding user font setting which may give more accurate/relevant data.

One motivation is to improve interop with Firefox and spec compliance. But I'm also trying to refactor our internal font-family implementation that is inherited from WebKit time and is a bit messy right now. Original generic names like "serif" or "cursive" have web-exposed bugs ; the recently implemented "system-ui" too but behaves inconsistently ; and we have non-standard values like -webkit-pictograph. Once things are cleaned up, we can consider implementing new values like font-family: emoji, math, fangsong, ui-serif, etc without adding more problems...

... however, one can also argue that it's would be better to implement "font-family: emoji" as a replacement/alias to "font-family: -webkit-pictograph" before deprecating/removing the latter. Again, this is possible but mean we would add more web-exposed bugs / inconsistencies in the meantime.

So I'm not really sure about the best approach. Sending "Intent to Prototype" for now and waiting for feedback.

Gecko: Positive No support for -webkit-pictograph

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-August/031938.html) This has been implemented in WebKit since 2011. In general Apple is against removing features that could potentially break web compat or their platform. I asked them to see if they would be happy to add "font-family: emoji" as an alias for -webkit-pictograph, as they did for "system-ui". In general about the current font-family implementation, Myles C. Maxfield commented in the github PR to add WPT tests that he is aware of the issue and doesn't think it's desirable that these -webkit-* values are web-exposed.

Web developers: No signals "font-family: emoji" was added in the CSS fonts spec, so I guess there is interest to make this more standard. I was not able to find the github discussion, though.


Debuggability

font-family are accessible via standard CSS UI in DevTools.



Is this feature fully tested by web-platform-tests?

Yes

Flag name



Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1065468

Estimated milestones



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5171427683598336

This intent message was generated by Chrome Platform Status.
-- 
Frédéric Wang

Frédéric Wang

unread,
Aug 19, 2021, 1:36:37 AMAug 19
to blin...@chromium.org
Le 13/08/2021 à 14:23, Frédéric Wang a écrit :


Interoperability and Compatibility

This feature was implemented by Apple in 2011 before the Blink fork and is still implemented in WebKit. It has never been implemented in Firefox.

A HTTPArchive search from March 2020 provided 1903 pages out of ~5millions (i.e. 0.0003806%). I'm adding a user counter to actually measure when a -webkit-pictograph font is actually resolved to the corresponding user font setting which may give more accurate/relevant data.

One motivation is to improve interop with Firefox and spec compliance. But I'm also trying to refactor our internal font-family implementation that is inherited from WebKit time and is a bit messy right now. Original generic names like "serif" or "cursive" have web-exposed bugs ; the recently implemented "system-ui" too but behaves inconsistently ; and we have non-standard values like -webkit-pictograph. Once things are cleaned up, we can consider implementing new values like font-family: emoji, math, fangsong, ui-serif, etc without adding more problems...

... however, one can also argue that it's would be better to implement "font-family: emoji" as a replacement/alias to "font-family: -webkit-pictograph" before deprecating/removing the latter. Again, this is possible but mean we would add more web-exposed bugs / inconsistencies in the meantime.

So I'm not really sure about the best approach. Sending "Intent to Prototype" for now and waiting for feedback.

Gecko: Positive No support for -webkit-pictograph

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-August/031938.html) This has been implemented in WebKit since 2011. In general Apple is against removing features that could potentially break web compat or their platform. I asked them to see if they would be happy to add "font-family: emoji" as an alias for -webkit-pictograph, as they did for "system-ui". In general about the current font-family implementation, Myles C. Maxfield commented in the github PR to add WPT tests that he is aware of the issue and doesn't think it's desirable that these -webkit-* values are web-exposed.

Web developers: No signals "font-family: emoji" was added in the CSS fonts spec, so I guess there is interest to make this more standard. I was not able to find the github discussion, though.

So just to follow-up here too,

HTTPArchive result from March 2020 from Yoav were:

* -webkit-pictograph alone represented less than 0.04% of pages.
* -webkit-pictograph + -webkit-body + -webkit-standard represented less than 0.1426%

That sounded big, so I had started to prepare a use counter that would provide finer measurement (i.e. only measure when the font family setting is actually resolved for -webkit-pictograph) : https://chromium-review.googlesource.com/c/chromium/src/+/2124260

New results from August 2021 provided by Yoav and Dominik showed that together -webkit-pictograph + -webkit-body + -webkit-standard represent less than 0.004% of HTTPArchive pages so it's an order of magnitude smaller.

Reference doc: https://docs.google.com/document/d/1nYJzL-MWQrTmf9Z-KscTWuM_5n6-IVdJeEllJ3Appro

-- 
Frédéric Wang

Yoav Weiss

unread,
Aug 19, 2021, 2:44:00 AMAug 19
to Frédéric Wang, blink-dev
I just re-ran the pictograph query and got 3231 results out of ~7.5 million pages, which puts us back in the 0.04% range.

Adding a use-counter sounds like a reasonable way to see what actual usage looks like. 

--
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/e6efc0e1-34a4-8546-a03e-53d69871ded5%40igalia.com.
Reply all
Reply to author
Forward
0 new messages