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

[Frédéric Wang]

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]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/93c98e36-a6c9-400d-7a9a-68a4d621cc59%40chromium.org.

[Daniel Bratell]

LGTM2 (but note Rick's note)

/Daniel

[TAMURA, Kent]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/40ba0382-8cda-fd78-9345-bd1a03a50398%40gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Frédéric Wang]

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/

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHHie%2ByxEy8XPjrZMPi7WMdTnV3S1BXaBWvdqPMicPh9g%40mail.gmail.com.

-- 
Frédéric Wang

[Yoav Weiss]

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?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fdceaa38-f6c5-a56c-8b35-53ee60812d24%40igalia.com.

[Frédéric Wang]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXc-iZFs8KxeYM-AOCr9HVE%2BTo%3DGez0Vg%3DDEju0XZ%3DzDQ%40mail.gmail.com.

-- 
Frédéric Wang

[Yoav Weiss]

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! :)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/046e6780-dd90-d8e1-ce1e-da9cfa50432e%40igalia.com.

[Frédéric Wang]

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]

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)