Intent to Ship: Remove font-family -webkit-<generic-name>

51 views
Skip to first unread message

Frédéric Wang

unread,
Aug 13, 2021, 3:57:21 AMAug 13
to blink-dev

Contact emails

fw...@chromium.org

Explainer

None

Specification

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

Summary

Remove support for the font-family values -webkit-cursive, -webkit-fantasy, -webkit-monospace, -webkit-sans-serif and -webkit-serif. They essentially behave as an alias to the standard keywords cursive, fantasy, monospace, sans-serif and serif and are only exposed as historical implementation details inherited from WebKit.

Motivation

Blink stores font-family's <generic-name> strings with a -webkit prefix for internal manipulation and removes that prefix when the font-family string is serialized.

It is possible for users to directly use these -webkit prefixed forms as font-family's <family-name> values and hence observe special behavior for both rendering and serialization.

Removing special behavior for these non-standard -webkit-<generic-name> values will improve alignment with the CSS specifications and Firefox.

It will also make Blink's behavior more consistent e.g. that behavior does not happen for the generic font family "system-ui".

It will also allow to greatly simplify our internal implementation of font-family, preparing for more cleanup and implementation of new generic names.

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. Fixing potential pages broken by this change or not currently working in Firefox is straightforward : just remove the -webkit prefix. This will continue to work in WebKit too.

In March 2020, searching these strings on HTTPArchive gave 11 matches over ~5 millions (0.0000022 %). Typically this is used by elements with class="Apple-style-span", suggesting it was generated by some Apple WYIWYG authoring tool that probably does not properly serialize internal -webkit-<generic-name> values.

Internally, these values were used by one legacy web test (see https://chromium-review.googlesource.com/c/chromium/src/+/3091145) and by the "internal popup menu" (https://chromium-review.googlesource.com/c/chromium/src/+/3087350).



Gecko: Shipped/Shipping Firefox does not support these -webkit prefixed values.

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


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

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

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

Frédéric Wang

unread,
Aug 13, 2021, 4:04:57 AMAug 13
to blin...@chromium.org
Le 13/08/2021 à 09:57, Frédéric Wang a écrit :
> In March 2020, searching these strings on HTTPArchive gave 11 matches
> over ~5 millions (0.0000022 %).

Details here : https://bugs.chromium.org/p/chromium/issues/detail?id=1065354

> Typically this is used by elements with class="Apple-style-span",
> suggesting it was generated by some Apple WYIWYG authoring tool that
> probably does not properly serialize internal -webkit-<generic-name>
> values.

More info about Apple-style-span:
https://webkit.org/blog/1737/apple-style-span-is-gone/

--
Frédéric Wang

Daniel Bratell

unread,
Aug 13, 2021, 8:37:08 AMAug 13
to Frédéric Wang, blink-dev

11 matches out of ~5 millions, which may (or may not) select an alternatively undesired font is not much. Normally I'd want a use counter to ensure possible breakage is very small, but with such a tiny known usage of such an unknown feature, I'm leaning towards thinking this should be safe enough. Thoughts?

/Daniel

--
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/040a4a54-d8ce-a9f7-8e3c-6cba3a57c67e%40igalia.com.

Frédéric Wang

unread,
Aug 13, 2021, 8:55:12 AMAug 13
to Daniel Bratell, blink-dev
Le 13/08/2021 à 14:36, Daniel Bratell a écrit :
>
> 11 matches out of ~5 millions, which may (or may not) select an
> alternatively undesired font is not much. Normally I'd want a use
> counter to ensure possible breakage is very small, but with such a
> tiny known usage of such an unknown feature, I'm leaning towards
> thinking this should be safe enough. Thoughts?
>
> /Daniel
>
Yes, so I forgot to say that I did try to add a use counter last year
[1] to actually measure when font settings would be accessed for
rendering purpose. But because of our messy internal font-family
implementation, this is a bit tricky right now : One cannot generally
distinguish these to the situation where the settings is read because of
an equivalent standard <generic-name> value (i.e. with -webkit removed).

I'm currently trying a big refactoring of the font-family implementation
that would make such a use counter theoretically possible... but the
goal of this intent is really to make such refactoring easier. Also
these -webkit-<generic-name> prefix really just seem and unintentionally
exposed implementation detail.

An alternative would be to have the use counter during the CSS parsing
step but that would make the metrics less accurate (i.e. it would count
"font-family: MySystemFont, -webkit-serif;" even though "-webkit-serif"
is generally just ignored). Also, I'm a bit affraid it could have some
perf impact.

[1] https://chromium-review.googlesource.com/c/chromium/src/+/2124260/4

--
Frédéric Wang


Mike Taylor

unread,
Aug 13, 2021, 10:56:45 AMAug 13
to Daniel Bratell, Frédéric Wang, blink-dev
Hi Daniel,

On 8/13/21 8:36 AM, Daniel Bratell wrote:
>
> 11 matches out of ~5 millions, which may (or may not) select an
> alternatively undesired font is not much. Normally I'd want a use
> counter to ensure possible breakage is very small, but with such a
> tiny known usage of such an unknown feature, I'm leaning towards
> thinking this should be safe enough. Thoughts?
>
> /Daniel
>
Obviously I can't speak for Mozilla, but in my time working on the
Firefox webcompat team this never showed up on our radar (also, I had no
idea this existed...). A quick search of
https://github.com/webcompat/web-bugs and Bugzilla seems to confirm that.

later,
Mike

Rick Byers

unread,
Aug 13, 2021, 12:08:15 PMAug 13
to Mike Taylor, Daniel Bratell, Frédéric Wang, blink-dev
This does feel close to a bugfix to me - something that was accidentally exposed and likely never really used. I'm comfortable using HTTP Archive data instead of UseCounters here, but March 2020 was a pretty long time ago. Can we do a new one?

LGTM1 assuming a current HTTP Archive search doesn't show this has grown non-trivially.

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

Daniel Bratell

unread,
Aug 13, 2021, 2:09:39 PMAug 13
to Rick Byers, Mike Taylor, Frédéric Wang, blink-dev

LGTM2 (but note Rick's note)

/Daniel

TAMURA, Kent

unread,
Aug 16, 2021, 7:41:21 PMAug 16
to Frédéric Wang, blink-dev
LGTM3




--
TAMURA Kent
Software Engineer, Google


Frédéric Wang

unread,
Aug 17, 2021, 8:58:15 AMAug 17
to blin...@chromium.org
Thank you everybody for the LGTM.

Unfortunately I don't have permission to run the request again myself. Last year Yoav was the one who did it for me.

So I guess we'll have to wait a bit before I can provide the data.

This -webkit-<generic-name> is only the tip of the iceberg. For people who are interested about the status of font-family and how we can improve our implemenation, I've written a design doc here:

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

Yoav Weiss

unread,
Aug 18, 2021, 3:19:04 AMAug 18
to Frédéric Wang, Dominik Röttsches, Rick Viscomi, blink-dev
Looks like +Dominik Röttsches beat me to it, and got ~0.003% in HA. That's an order of magnitude more than we've seen a year and a half ago, but that still doesn't qualify as "large".
The sample size now is also significantly larger, so I wonder if the increase comes from higher usage, or from some HA change that now includes more response bodies.

+Rick Viscomi - any changes done on the front of response bodies in the last 18 months?

Frédéric Wang

unread,
Aug 18, 2021, 3:32:13 AMAug 18
to blin...@chromium.org
Dominik's request is for

-webkit-monospace, webkit-serif, -webkit-sans-serif, -webkit-cursive, -webkit-fantasy, -webkit-pictograph, -webkit-body, -webkit-standard

But this intent to ship is only for

-webkit-<generic-name> (i.e. -webkit-monospace, webkit-serif, -webkit-sans-serif, -webkit-cursive, -webkit-fantasy)

Your results from March 2020 were:

-webkit-<generic-name>: 11 out of ~5millions
-webkit-pictograph: 1903 out of ~5millions
-webkit-body: 2489 out of ~5millions
-webkit-standard: 2738 out of ~5millions

So most of the matches were actually coming from -webkit-pictograph, -webkit-body and -webkit-standard (it's true that that percent is 10 times smaller for these too).

I was waiting to get results for only the -webkit-<generic-name>.

Yoav Weiss

unread,
Aug 18, 2021, 3:46:13 AMAug 18
to Frédéric Wang, blink-dev
Indeed! Re-running the query only for the values covered by this intent returned 20 results out of ~7.5 million pages, which is 0.000267% - the same order of magnitude that we saw 18 months ago.

LGTM4 from my perspective! :)

Frédéric Wang

unread,
Aug 18, 2021, 6:21:14 AMAug 18
to Yoav Weiss, blink-dev
Thanks Yoav.

Just to be sure:

- Your result for -webkit-<generic>: 20 over 7.5 million is 0.00000267%
- Dominik's result including -webkit-pictograph/body/standard: 10538 over 324427478 is 0.00003248%
-- 
Frédéric Wang

Rick Viscomi

unread,
Aug 19, 2021, 11:04:26 AMAug 19
to Yoav Weiss, Frédéric Wang, Dominik Röttsches, blink-dev
Yes there were several changes to the `response_bodies` table in the last year.

1. We migrated the pipeline from Java to Python
2. We exceeded the 15 TB transfer limit in September 2020, causing a multi-month outage
3. We fixed (2) in July and accidentally introduced a new bug that included rows with null bodies (now fixed)
Reply all
Reply to author
Forward
0 new messages