Intent to Implement and Ship: CSS font-size: xxx-large

[Oliver Dunk]

Contact emails

oli...@oliverdunk.com

Explainer

There’s no explainer to share as this is a small change. Documentation can be easily found on the current values, from xx-small to xx-large - https://cssreference.io/property/font-size/ for example.

Also see the CSS Working Group’s resolution here: https://github.com/w3c/csswg-drafts/issues/3907

Design doc/Spec

This appears in the CSS Fonts Module Level 4 draft: https://drafts.csswg.org/css-fonts-4/#valdef-font-size-absolute-size

Skipping TAG review as this is a trivial change to a feature which has already been implemented.

Summary

We currently support -webkit-xxx-large as a font size. Dropping the prefix and standardising the property means developers can use the size unprefixed, and also means that other browsers can implement it.

Issue requesting implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=966249

Motivation

Allows for a greater range of font sizes when using the user agent defaults. This also standardises a mapping for size 7 which used to be offered on <font>.

Risks

Interoperability and Compatibility

This is low risk. The other values are already supported across browsers, and the prefixed version of this property has existed for many years. A specification exists defining this feature, and there are already shared tests in the web-platform-tests repository.

Edge: No signals

Firefox: No official signals, but public support from a developer here: https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-491244119

Safari: No signals

Web / Framework developers: All I could find was some discussion here: https://readable-email.org/list/www-style/topic/css3-fonts-addition-of-font-size-xxx-large. Opposition was mostly that the change was unnecessary, and those in favour argued it is a small tweak that would make the platform more consistent.

Ergonomics

This feature will generally be used as a direct CSS property. It should be a fairly contained change.

Activation

The prefixed value means this can be used both before and after this change. In other browsers another fallback would be needed.

Debuggability

This is a simple property change that should require no changes to Dev Tools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

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

This will require tweaks to existing tests, such as third_party/blink/web_tests/external/wpt/html/rendering/non-replaced-elements/phrasing-content-0/font-element-text-decoration-color/font-size.html. I’m happy to make those as part of the work.

Link to entry on the feature dashboard

This is a very small change, so I do not believe an entry is necessary.

Requesting approval to ship?

Yes

[Eric Willigers]

non-owner lgtm

[PhistucK]

ChromeStatus entries feed the beta blog post, so I think an entry should be added for this.

While it is a small change, this unprefixes something that was WebKit only, apparently.

I see Gecko implements it but explicitly skips it -

https://dxr.mozilla.org/mozilla-central/source/servo/components/style/values/generics/font.rs#259

So it will probably be a very small change to implement it there.

But I think there should be positive public signals first, otherwise Chrome might end up simply having two non-interoperable values (-webkit-xxx-large as well as xxx-large). Maybe file issues with Firefox and WebKit and gauge some signals?

☆PhistucK

On Thu, Jun 13, 2019 at 12:08 AM Eric Willigers <ericwi...@chromium.org> wrote:

non-owner lgtm

--
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/d5bb359d-cbeb-4559-9c63-8542b9213e2b%40chromium.org.

[Eric Willigers]

https://www.chromestatus.com/feature/5675317559558144

While it is a small change, this unprefixes something that was WebKit only, apparently.

<font size="7"> never had a portable CSS equivalent.

If you look at https://drafts.csswg.org/css-fonts-4/#absolute-size-mapping, the last column was already present but previously had no CSS keyword. 

 

I see Gecko implements it but explicitly skips it -

https://dxr.mozilla.org/mozilla-central/source/servo/components/style/values/generics/font.rs#259

So it will probably be a very small change to implement it there.

Gecko had the feature internally, but it wasn't web exposed (as no keyword was in the standard until now). 

But I think there should be positive public signals first, otherwise Chrome might end up simply having two non-interoperable values (-webkit-xxx-large as well as xxx-large). Maybe file issues with Firefox and WebKit and gauge some signals?

The CSS WG discussion was started by an Apple engineer, received support from a Mozilla engineer, was facilitated by invited experts and was chaired by a Microsoft engineer.

 

[fantasai]

On 6/12/19 10:45 PM, 'Oliver Dunk' via blink-dev wrote:
>
> *Interoperability and Compatibility*

>
> This is low risk. The other values are already supported across browsers, and
> the prefixed version of this property has existed for many years. A
> specification exists defining this feature, and there are already shared tests
> in the web-platform-tests repository.
>
>
> Edge: No signals
>
> Firefox: No official signals, but public support from a developer here:
> https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-491244119
>
> Safari: No signals

Google's I2S template owners seem to only value feedback from the TAG and not
Working Groups for reasons that remain beyond my comprehension, but CSSWG
resolutions generally implicate public support of the resolution from all the
browser vendors, and are therefore worth noting.

As Eric Willigers points out later in the thread, Safari and Microsoft also
signaled their support in the discussion, and if you look into the minutes you
can see the evidence of that:
https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-494877557

~fantasai

[PhistucK]

I understand. I was simply following the information mentioned in the intent ("no (official) public signals"). Since there are positive signals, I see no problem with this, too.

Thank you for clarifying.

☆PhistucK

--
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/7647805b-e6a4-37d9-ec4a-2e5bc1ad06a7%40inkedblade.net.

[Chris Harrelson]

On Wed, Jun 12, 2019 at 1:45 PM 'Oliver Dunk' via blink-dev <blin...@chromium.org> wrote:

Contact emails

oli...@oliverdunk.com

Explainer

There’s no explainer to share as this is a small change. Documentation can be easily found on the current values, from xx-small to xx-large - https://cssreference.io/property/font-size/ for example.

Also see the CSS Working Group’s resolution here: https://github.com/w3c/csswg-drafts/issues/3907

Design doc/Spec

This appears in the CSS Fonts Module Level 4 draft: https://drafts.csswg.org/css-fonts-4/#valdef-font-size-absolute-size

Skipping TAG review as this is a trivial change to a feature which has already been implemented.

Summary

We currently support -webkit-xxx-large as a font size. Dropping the prefix and standardising the property means developers can use the size unprefixed, and also means that other browsers can implement it.

Is -webkit-xxx-large going to have exactly the same semantics as -xxx-large?

Also, we should get UseCounter data to see if -webkit-xxx-large can be removed now. 

Issue requesting implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=966249

Motivation

Allows for a greater range of font sizes when using the user agent defaults. This also standardises a mapping for size 7 which used to be offered on <font>.

Risks

Interoperability and Compatibility

This is low risk. The other values are already supported across browsers, and the prefixed version of this property has existed for many years. A specification exists defining this feature, and there are already shared tests in the web-platform-tests repository.

Edge: No signals

Firefox: No official signals, but public support from a developer here: https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-491244119

Safari: No signals

Do the other browsers also support the feature with a prefix? I assume Safari does. 

Web / Framework developers: All I could find was some discussion here: https://readable-email.org/list/www-style/topic/css3-fonts-addition-of-font-size-xxx-large. Opposition was mostly that the change was unnecessary, and those in favour argued it is a small tweak that would make the platform more consistent.

Ergonomics

This feature will generally be used as a direct CSS property. It should be a fairly contained change.

Activation

The prefixed value means this can be used both before and after this change. In other browsers another fallback would be needed.

Debuggability

This is a simple property change that should require no changes to Dev Tools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

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

This will require tweaks to existing tests, such as third_party/blink/web_tests/external/wpt/html/rendering/non-replaced-elements/phrasing-content-0/font-element-text-decoration-color/font-size.html. I’m happy to make those as part of the work.

Link to entry on the feature dashboard

This is a very small change, so I do not believe an entry is necessary.

Requesting approval to ship?

Yes

--

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/6cb1470f-54ae-40fd-93b0-ae4f6c3da70b%40chromium.org.

[Chris Harrelson]

Hi,

On Thu, Jun 13, 2019 at 11:37 AM fantasai <fantasa...@inkedblade.net> wrote:

On 6/12/19 10:45 PM, 'Oliver Dunk' via blink-dev wrote:
>
> *Interoperability and Compatibility*
>
> This is low risk. The other values are already supported across browsers, and
> the prefixed version of this property has existed for many years. A
> specification exists defining this feature, and there are already shared tests
> in the web-platform-tests repository.
>
>
> Edge: No signals
>
> Firefox: No official signals, but public support from a developer here:
> https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-491244119
>
> Safari: No signals

Google's I2S template owners seem to only value feedback from the TAG and not
Working Groups for reasons that remain beyond my comprehension, but CSSWG
resolutions generally implicate public support of the resolution from all the
browser vendors, and are therefore worth noting.

The Blink intent-to-ship process values all feedback and signals. Links to WG resolutions are always helpful, and in fact a number of previous intents have listed those.

It is good idea to add notes encouraging such links by giving examples. I went ahead and edited the template just now, since it seems uncontroversial.

Before my edit, the template just said "Please include links where possible". If you would like to discuss more about details or have additional feedback, please email blink-api-owners-discuss@.

As Eric Willigers points out later in the thread, Safari and Microsoft also
signaled their support in the discussion, and if you look into the minutes you
can see the evidence of that:
https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-494877557

~fantasai

--
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/7647805b-e6a4-37d9-ec4a-2e5bc1ad06a7%40inkedblade.net.

[Eric Willigers]

 

Is -webkit-xxx-large going to have exactly the same semantics as -xxx-large?

Also, we should get UseCounter data to see if -webkit-xxx-large can be removed now. 

Adding a UseCounter for -webkit-xxx-large is part of this effort. -webkit-xxx-large would become an alias that we can discuss deprecating and removing once we have usage data.

https://bugs.chromium.org/p/chromium/issues/detail?id=966249#c2

Do we have a way to obtain UseCounter data from the top N sites without waiting ~12 weeks for a UseCounter to reach stable users? That would be useful in general.

Do the other browsers also support the feature with a prefix? I assume Safari does. 

Only Blink and WebKit (Safari) support -webkit-xxx-large. There is no -ms-... or -moz-... equivalent. Gecko has xxx-large internally but not yet web exposed.  

[Chris Harrelson]

LGTM1

Thanks for doing the UseCounter work. But regardless of that, I don't see shipping this feature as causing more usage of the prefixed feature, so approving.

On Thu, Jun 13, 2019 at 4:20 PM Eric Willigers <ericwi...@chromium.org> wrote:

 

Is -webkit-xxx-large going to have exactly the same semantics as -xxx-large?

Also, we should get UseCounter data to see if -webkit-xxx-large can be removed now. 

Adding a UseCounter for -webkit-xxx-large is part of this effort. -webkit-xxx-large would become an alias that we can discuss deprecating and removing once we have usage data.

https://bugs.chromium.org/p/chromium/issues/detail?id=966249#c2

Do we have a way to obtain UseCounter data from the top N sites without waiting ~12 weeks for a UseCounter to reach stable users? That would be useful in general.

One option is to do an httparchive search and see if it shows up in CSS files often.

 

Do the other browsers also support the feature with a prefix? I assume Safari does. 

Only Blink and WebKit (Safari) support -webkit-xxx-large. There is no -ms-... or -moz-... equivalent. Gecko has xxx-large internally but not yet web exposed.  

--
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/76b9c6ad-83ba-4e8b-ab77-3aaaf8775082%40chromium.org.

[PhistucK]

Note - the source of truth of the template got moved into ChromeStatus.com -

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACZRgz7s98ZT4-cu1tWevxHsB1nyuQKA-ZBC1LhSHMEGWy1hOw%40mail.gmail.com?utm_medium=email&utm_source=footer

So you better change it there.

Thank you!

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8WmbAFirR0XCwm2FTU-2LtxrD%3D0RFz%2BE2q9684991g7A%40mail.gmail.com.

[Daniel Bratell]

LGTM2

/Daniel

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

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Philip Jägenstedt]

LGTM3, hope this provides a path towards -webkit-xxx-large.

FWIW, I only got 137 matches for "-webkit-xxx-large" in the latest httparchive data, which is very few compared to many things we're successfully removed, so this may be quite tractable. Worst case just add it as a required alias in the spec.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z3c6q4i4rbppqq%40cicero2.linkoping.osa.

[Oliver Dunk]

As Eric Willigers points out later in the thread, Safari and Microsoft also signaled their support in the discussion, and if you look into the minutes you can see the evidence of that:
https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-494877557

Thanks! I have to be honest, I’m not familiar with this process and public support seems like a vague term. I didn’t want to wrongly assume the viewpoint of an organisation based on an individual, but I guess in a working group that’s a fair thing to do. Would be good to clarify this in the template.

I went ahead and edited the template just now, since it seems uncontroversial.

Am I missing this? I can’t seem to find the change on the template. While it may be available in Chrome Status, I’m not yet a Chromium committer, so can’t access that. Changes to the public template would be helpful for people like me.

On 13 Jun 2019, at 19:37, fantasai <fantasa...@inkedblade.net> wrote:

On 6/12/19 10:45 PM, 'Oliver Dunk' via blink-dev wrote:

*Interoperability and Compatibility*
This is low risk. The other values are already supported across browsers, and the prefixed version of this property has existed for many years. A specification exists defining this feature, and there are already shared tests in the web-platform-tests repository.
Edge: No signals
Firefox: No official signals, but public support from a developer here: https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-491244119
Safari: No signals

Google's I2S template owners seem to only value feedback from the TAG and not Working Groups for reasons that remain beyond my comprehension, but CSSWG resolutions generally implicate public support of the resolution from all the browser vendors, and are therefore worth noting.

~fantasai

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/ucEUTqoi4Nc/unsubscribe.
To unsubscribe from this group and all its topics, 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/7647805b-e6a4-37d9-ec4a-2e5bc1ad06a7%40inkedblade.net.

[Chris Harrelson]

On Fri, Jun 14, 2019 at 8:46 AM 'Oliver Dunk' via blink-dev <blin...@chromium.org> wrote:

As Eric Willigers points out later in the thread, Safari and Microsoft also signaled their support in the discussion, and if you look into the minutes you can see the evidence of that:
https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-494877557

Thanks! I have to be honest, I’m not familiar with this process and public support seems like a vague term. I didn’t want to wrongly assume the viewpoint of an organisation based on an individual, but I guess in a working group that’s a fair thing to do. Would be good to clarify this in the template. 

I went ahead and edited the template just now, since it seems uncontroversial.

Am I missing this? I can’t seem to find the change on the template. While it may be available in Chrome Status, I’m not yet a Chromium committer, so can’t access that. Changes to the public template would be helpful for people like me.

I updated the intent-to-ship part of it. Just went back and looked again, and found the intent to implement part was not updated. Fixed that too, thanks for noticing. The new text reads:

"Please include links where possible. Examples include resolutions from relevant standards bodies (e.g. W3C Working Group), tracking bugs, or links to online conversations."

 

On 13 Jun 2019, at 19:37, fantasai <fantasa...@inkedblade.net> wrote:

On 6/12/19 10:45 PM, 'Oliver Dunk' via blink-dev wrote:

*Interoperability and Compatibility*
This is low risk. The other values are already supported across browsers, and the prefixed version of this property has existed for many years. A specification exists defining this feature, and there are already shared tests in the web-platform-tests repository.
Edge: No signals
Firefox: No official signals, but public support from a developer here: https://github.com/w3c/csswg-drafts/issues/3907#issuecomment-491244119
Safari: No signals

Google's I2S template owners seem to only value feedback from the TAG and not Working Groups for reasons that remain beyond my comprehension, but CSSWG resolutions generally implicate public support of the resolution from all the browser vendors, and are therefore worth noting.



~fantasai

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/ucEUTqoi4Nc/unsubscribe.
To unsubscribe from this group and all its topics, 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/7647805b-e6a4-37d9-ec4a-2e5bc1ad06a7%40inkedblade.net.

--

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/8011F0F8-BF61-46AA-ADFA-0C40CCA6A3AD%40oliverdunk.com.

[Boris Zbarsky]

On 6/14/19 11:46 AM, 'Oliver Dunk' via blink-dev wrote:
> I didn’t want to wrongly assume
> the viewpoint of an organisation based on an individual, but I guess in
> a working group that’s a fair thing to do.

Fwiw, it strongly depends on the working group and possibly on the
individual...

Sorry, there's just no way to win here. I actually really appreciated
the conservative approach you took, but it made fantasai unhappy. :(

-Boris