Intent to Ship: meter element fallback styles

Traian Captan

unread,

Aug 12, 2024, 5:05:34 PMAug 12

to blink-dev

Contact emails

tca...@chromium.org

Explainer

None

Specification

None

Summary

With this change <meter> elements with `appearance: none` will have a reasonable fallback style that matches Safari and Firefox instead of just disappearing from the page. As well developers will be able to custom style the <meter> elements. A temporary Enterprise policy MeterAppearanceNoneFallbackStyle is available until Chrome 133 to control this feature.

Blink component

Blink>HTML>Meter

Search tags

meter

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The Interoperability Risk is Low. This change increases interop with Safari and Firefox which already provide a reasonable fallback style for <meter> elements with `appearance: none`. The Compatibility Risk is Low.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

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

Yes

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

No

Flag name on chrome://flags

MeterAppearanceNoneFallbackStyle

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/40210066

Estimated milestones

Shipping on desktop	129
DevTrial on desktop	129
Shipping on Android	129
DevTrial on Android	129
Shipping on WebView	129

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4993824284475392?gate=6457633259913216

This intent message was generated by Chrome Platform Status.

Domenic Denicola

unread,

Aug 13, 2024, 1:51:41 AMAug 13

to Traian Captan, blink-dev

On Tue, Aug 13, 2024 at 6:05 AM Traian Captan <tca...@chromium.org> wrote:

Contact emails
tca...@chromium.org

Explainer
None

Specification
None

My understanding is that appearance: none has a specification, probably around https://drafts.csswg.org/css-ui/#appearance-switching . Can you ensure this field is filled out, and more importantly, that the implementation you propose is in accordance with the specification?

Summary
With this change <meter> elements with `appearance: none` will have a reasonable fallback style that matches Safari and Firefox instead of just disappearing from the page. As well developers will be able to custom style the <meter> elements. A temporary Enterprise policy MeterAppearanceNoneFallbackStyle is available until Chrome 133 to control this feature.

Blink component
Blink>HTML>Meter

Search tags
meter

TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility
The Interoperability Risk is Low. This change increases interop with Safari and Firefox which already provide a reasonable fallback style for <meter> elements with `appearance: none`. The Compatibility Risk is Low.

Can you say more about the compatibility risk? How often are authors using appearance: none on meter elements today, and how will their pages' appearances and layout change?

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive

Other signals:

WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None

Debuggability
None

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

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

Why not?

Flag name on chrome://flags
MeterAppearanceNoneFallbackStyle

Finch feature name
None

Non-finch justification
None

Please include the justification for why this does not have a Finch killswitch, or add one.

Requires code in //chrome?
False

Tracking bug
https://crbug.com/40210066

Estimated milestones
Shipping on desktop 129
DevTrial on desktop 129
Shipping on Android 129
DevTrial on Android 129
Shipping on WebView 129

Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
None

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4993824284475392?gate=6457633259913216

This intent message was generated by Chrome Platform Status.

--
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/CAFxahvt0RUfGg65EyALkzUsKbZ9R8w90C-HPhRV6dR0mOieRdw%40mail.gmail.com.

Traian Captan

unread,

Aug 15, 2024, 5:07:36 AMAug 15

to Domenic Denicola, blink-dev

On Mon, Aug 12, 2024 at 10:51 PM Domenic Denicola <dom...@chromium.org> wrote:

Specification
None

My understanding is that appearance: none has a specification, probably around https://drafts.csswg.org/css-ui/#appearance-switching . Can you ensure this field is filled out, and more importantly, that the implementation you propose is in accordance with the specification?

Sure, I can add it. I'm thinking that "https://drafts.csswg.org/css-ui/#appearance-decorative" seems most appropriate, which states: "UAs should include in their user agent stylesheet style rules to give widgets a recognizable shape when appearance is none.".

I didn't find anything else in the spec defining how the fall back styles should look like. Please let me know if I missed something.

Risks

Interoperability and Compatibility
The Interoperability Risk is Low. This change increases interop with Safari and Firefox which already provide a reasonable fallback style for <meter> elements with `appearance: none`. The Compatibility Risk is Low.

Can you say more about the compatibility risk? How often are authors using appearance: none on meter elements today, and how will their pages' appearances and layout change?

The usage of 'appearance: none ' for the meter element seems to be around 0.006 () VS around 0.01 for 'appearance: auto' usage.

Regarding the rendering of appearance none, we will display a fall back style instead of being invisible.

Regarding layout change, there is no change since the size is defined on the meter element itself, and we are not changing that.

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

Why not?

Since I did not find fall back style rendering being specified I thought that we shouldn't add them to wpt-external, however I added a set of wpt-internal tests in:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/html/semantics/forms/the-meter-element/

Based on the definition of "UAs should include in their user agent stylesheet style rules to give widgets a recognizable shape when appearance is none." in "https://drafts.csswg.org/css-ui/#appearance-decorative" I created a CL adding WPT external tests asserting that <meter> with 'appearance: none' should not render the same as <meter> with 'appearance: auto':

https://chromium-review.googlesource.com/c/chromium/src/+/5790065

Flag name on chrome://flags
MeterAppearanceNoneFallbackStyle

Finch feature name
None

Non-finch justification
None

Please include the justification for why this does not have a Finch killswitch, or add one.

My mistake. The flag I added is a "Finch feature name". I moved it to the correct field. Sorry for the confusion.

Regards,

Traian

Domenic Denicola

unread,

Aug 16, 2024, 12:38:53 AMAug 16

to Traian Captan, Domenic Denicola, blink-dev

On Thu, Aug 15, 2024 at 6:07 PM Traian Captan <tca...@chromium.org> wrote:

On Mon, Aug 12, 2024 at 10:51 PM Domenic Denicola <dom...@chromium.org> wrote:
Specification
None

My understanding is that appearance: none has a specification, probably around https://drafts.csswg.org/css-ui/#appearance-switching . Can you ensure this field is filled out, and more importantly, that the implementation you propose is in accordance with the specification?
Sure, I can add it. I'm thinking that "https://drafts.csswg.org/css-ui/#appearance-decorative" seems most appropriate, which states: "UAs should include in their user agent stylesheet style rules to give widgets a recognizable shape when appearance is none.".
I didn't find anything else in the spec defining how the fall back styles should look like. Please let me know if I missed something.

Yes, I guess this is under-defined. It seems to bottom out in https://html.spec.whatwg.org/#the-meter-element-2 which has nothing interesting in the UA stylesheet, and states "Need to detail the expected primitive appearance."

This relates to the interoperability issues discussed below. You say "This change increases interop with Safari and Firefox which already provide a reasonable fallback style for <meter> elements with `appearance: none`," but don't give detail on whether our "reasonable fallback style" is the same as or different from theirs.

From what I can tell with some brief testing with Firefox Linux and Safari Tech Preview MacOS, they both produce a 80x16 box with 0 margin and padding in this "primitive appearance" mode. Firefox's inspector does not show any UA styles, but Safari shows UA styles of: { box-sizing: border-box; display: inline-block; block-size: 1em; inline-size: 5em; vertical-align: -0.2em; }. These actually match the spec's expected "native appearance", but I guess the "native appearance" has slightly different visuals, e.g. rounded corners and a shinier progress color.

What UA styles will we follow? Is there a chance we could agree on the same styles as Safari, and thus update the part of the HTML spec I pointed out above?

I don't think we should block this intent on getting this all specified perfectly, since the change you're making is bringing us closer to interop in a historically under-specified area. But I do want to understand to what extent we'll match Firefox and Safari, and it would be an excellent bonus if we took this opportunity to improve the spec for everyone while we were here.

Risks

Interoperability and Compatibility
The Interoperability Risk is Low. This change increases interop with Safari and Firefox which already provide a reasonable fallback style for <meter> elements with `appearance: none`. The Compatibility Risk is Low.

Can you say more about the compatibility risk? How often are authors using appearance: none on meter elements today, and how will their pages' appearances and layout change?
The usage of 'appearance: none ' for the meter element seems to be around 0.006 () VS around 0.01 for 'appearance: auto' usage.
Regarding the rendering of appearance none, we will display a fall back style instead of being invisible.
Regarding layout change, there is no change since the size is defined on the meter element itself, and we are not changing that.

Thanks. This seems relatively safe, as long as we have a Finch kill switch. Since the layout doesn't change it shouldn't affect the rest of the page, it might just cause some meters to appear that were previously invisible in Chrome and visible in Firefox/Safari.

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

Why not?
Since I did not find fall back style rendering being specified I thought that we shouldn't add them to wpt-external, however I added a set of wpt-internal tests in:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/wpt_internal/html/semantics/forms/the-meter-element/

Based on the definition of "UAs should include in their user agent stylesheet style rules to give widgets a recognizable shape when appearance is none." in "https://drafts.csswg.org/css-ui/#appearance-decorative" I created a CL adding WPT external tests asserting that <meter> with 'appearance: none' should not render the same as <meter> with 'appearance: auto':
https://chromium-review.googlesource.com/c/chromium/src/+/5790065

Those tests are a great start. If we can agree on the UA styles per the above, we could expand them using tests similar to these.

Traian Captan

unread,

Aug 19, 2024, 1:30:50 AMAug 19

to Domenic Denicola, blink-dev

This relates to the interoperability issues discussed below. You say "This change increases interop with Safari and Firefox which already provide a reasonable fallback style for <meter> elements with `appearance: none`," but don't give detail on whether our "reasonable fallback style" is the same as or different from theirs.

We match both their fall back styles. Safari was already matching Firefox's fallback style.

From what I can tell with some brief testing with Firefox Linux and Safari Tech Preview MacOS, they both produce a 80x16 box with 0 margin and padding in this "primitive appearance" mode. Firefox's inspector does not show any UA styles, but Safari shows UA styles of: { box-sizing: border-box; display: inline-block; block-size: 1em; inline-size: 5em; vertical-align: -0.2em; }. These actually match the spec's expected "native appearance", but I guess the "native appearance" has slightly different visuals, e.g. rounded corners and a shinier progress color.

What UA styles will we follow? Is there a chance we could agree on the same styles as Safari, and thus update the part of the HTML spec I pointed out above?

Yes. We match Safari's UA style.

I don't think we should block this intent on getting this all specified perfectly, since the change you're making is bringing us closer to interop in a historically under-specified area. But I do want to understand to what extent we'll match Firefox and Safari, and it would be an excellent bonus if we took this opportunity to improve the spec for everyone while we were here.

Agreed. The fallback styles I added match both Firefox and Safari.

There is also an open css-ui github issue regarding how the fall back styles should look like : [css-ui-4] appearance: none on <meter>

Those tests are a great start. If we can agree on the UA styles per the above, we could expand them using tests similar to these.

Thanks! That sounds good to me.

Regards,

Traian

Alex Russell

unread,

Aug 21, 2024, 11:43:45 AMAug 21

to blink-dev, Traian Captan, blink-dev, Domenic Denicola

LGTM1; thanks for the detailed responses to Domenic.

Mike Taylor

unread,

Aug 21, 2024, 11:45:05 AMAug 21

to Alex Russell, blink-dev, Traian Captan, Domenic Denicola

LGTM2 - it would be great to add additional tests as mentioned.

--

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/e7572a42-b918-4efa-876f-f1165a4b33c4n%40chromium.org.

Daniel Bratell

unread,

Aug 21, 2024, 12:02:51 PMAug 21

to Mike Taylor, Alex Russell, blink-dev, Traian Captan, Domenic Denicola

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/30e3195e-d23f-4e3b-afe4-afbbd21eaf37%40chromium.org.

Domenic Denicola

unread,

Aug 21, 2024, 9:22:01 PMAug 21

to blink-dev, Daniel Bratell, Traian Captan, Domenic Denicola, Mike Taylor, Alex Russell

(Unnecessary) LGTM4. Thanks to all your detailed answers, I think the compat and interop risk is low, and am excited to see this ship.

If you or your team has time to follow up on https://github.com/whatwg/html/issues/10569 to finish the spec and tests story, that would be a great help.

On Thursday, August 22, 2024 at 1:02:51 AM UTC+9 Daniel Bratell wrote:

LGTM3

/Daniel

On 2024-08-21 17:44, Mike Taylor wrote:

LGTM2 - it would be great to add additional tests as mentioned.

On 8/21/24 5:43 PM, Alex Russell wrote:

LGTM1; thanks for the detailed responses to Domenic.

On Sunday, August 18, 2024 at 10:30:50 PM UTC-7 Traian Captan wrote:

This relates to the interoperability issues discussed below. You say "This change increases interop with Safari and Firefox which already provide a reasonable fallback style for <meter> elements with `appearance: none`," but don't give detail on whether our "reasonable fallback style" is the same as or different from theirs.

We match both their fall back styles. Safari was already matching Firefox's fallback style.

From what I can tell with some brief testing with Firefox Linux and Safari Tech Preview MacOS, they both produce a 80x16 box with 0 margin and padding in this "primitive appearance" mode. Firefox's inspector does not show any UA styles, but Safari shows UA styles of: { box-sizing: border-box; display: inline-block; block-size: 1em; inline-size: 5em; vertical-align: -0.2em; }. These actually match the spec's expected "native appearance", but I guess the "native appearance" has slightly different visuals, e.g. rounded corners and a shinier progress color.

What UA styles will we follow? Is there a chance we could agree on the same styles as Safari, and thus update the part of the HTML spec I pointed out above?

Yes. We match Safari's UA style.

I don't think we should block this intent on getting this all specified perfectly, since the change you're making is bringing us closer to interop in a historically under-specified area. But I do want to understand to what extent we'll match Firefox and Safari, and it would be an excellent bonus if we took this opportunity to improve the spec for everyone while we were here.

Agreed. The fallback styles I added match both Firefox and Safari.

There is also an open css-ui github issue regarding how the fall back styles should look like : [css-ui-4] appearance: none on <meter>

Those tests are a great start. If we can agree on the UA styles per the above, we could expand them using tests similar to these.

Thanks! That sounds good to me.

Regards,

Traian

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e7572a42-b918-4efa-876f-f1165a4b33c4n%40chromium.org.

--
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+unsubscribe@chromium.org.

Traian Captan

unread,

Aug 23, 2024, 2:19:41 AMAug 23

to Alex Russell, blink-dev, Domenic Denicola

Thanks Alex!

Traian Captan

unread,

Aug 23, 2024, 2:19:41 AMAug 23

to Mike Taylor, Alex Russell, blink-dev, Domenic Denicola

Thanks Mike!
Once the spec gets sorted out I can add the additional WPT tests.

Reply all

Reply to author

Forward