Csswg-drafts: [css-ui-4] appearance: none on <meter>

[gregwhitworth]

@LeaVerou pointed out that Chrome 52 now removes the meter visualization for when -webkit-appearance: none is set. The spec doesn't seem to state what happens with <meter> but we should probably state what occurs. Reading through the spec this seems to be ok based on this text:

All decorative visual aspects of a form control which are not caused by a CSS style rule must be suppressed when the appearance is changed using appearance, even if the UA’s internal representation for this element was composed of multiple elements or pseudo elements combined together. For example, select is often rendered with an arrow on the right side indicating that the list will be expanded if the element is clicked. If the computed value of appearance is none, this must disappear.

But since <meter> is used to present information visually this seems to contradict with this part of the spec:

However, the UA must preserve aspects of the form control which are necessary to operate the control with its original semantics.

It would be good to get some feedback from other implementers and Google on why they made this change and its potential impact.

Chrome status of the change

[RByers]

@tkent-google made this change after discussing it with @frivoal and posting the plan to www-style. Does the spec need some improvement here?

[gregwhitworth]

Yes, a few things, based on my statement above they seem to contradict each other since meter is a visual representation, that is essentially its "operation". Yes meter can have fallback content, but is this how it is actually used in the wild - even if it's overall usage is low?

Additionally, before making a change that makes them disappear we should probably have a discussion on standardizing the styling of the parts to provide webdevs with a CSS approach to this rather than force them to use JS for a crossbrowser approach. I'm aware of some -moz and -webkit based psuedos that allow you to target the inner guts of the meter.

[tkent-google]

The motivation of Chrome's behavior change was to fix http://crbug.com/51182.
All of major browsers have similar horizontal bar representation of . But web authors want to render completely different representation such as rounded speedometer. We needed a way to stop the horizontal bar representation, and (-webkit-)appearance:none was suitable.

If there are other better idea to provide both of UA-default rendering and full-customization, I'd like to follow it.

[LeaVerou]

FWIW, the bug I pointed out was that the <meter> disappeared entirely (including its styling) when using -webkit-appearance: none, which I believe is undoubtedly a regression.

[gregwhitworth]

For context to what @LeaVerou is saying, here's her dabblet: http://dabblet.com/gist/97d86bc81cf9349aa7159ef2e1cc8210

[frivoal]

I think the spec needs significantly more work in this area, but I have not been able to commit time to do it.

If a visualization conveying the information carried by an element can be created using CSS, then I think that appearance: none is be justified in making the native look go away. However, this does not necessarily means that the element should become invisible. There should probably be something in the UA stylesheet to provide a default CSS-based rendering, which authors then go on overriding, possibly using all: unset to get a blank state after having checked using @supports that the styles they want to use are actually supported.

For <metter>, it is a bit tricky. I believe that using standard-but-not yet implemented CSS, it can be recreated.

meter {
    appearance:none;
    width: 100px;
    height: 1em;
    display: inline-block;
    background: gray;
}
meter::before {
    content: "";
    display: block;
    height: 100%;
    background: lime;
    width: calc(100% * ( attr(value number, 0) - attr(min number, 0) ) / attr(max number, 1));
}

Using non-standard but implemented css, it can also be recreated. Firefox's UA stylesheet for example uses a non standard ::-moz-meter-bar pseudo which thanks to the non-standard -moz-appearance: meterchunk; has the right size.

However, I do not think it can be recreated using standard css as currently implemented.

When appearance is none, should the spec make a decision about which control must preserve some native components to be functional, and which should instead have their look and feel be created via the UA style-sheet (and which, if any, should become invisible)? The problem is not just that it is a lot of work for the spec editor, but that the answer depends on how rich the is the set of css features implemented by each UA.

The spec currently contains these statements:

All decorative visual aspects of a form control which are not caused by a CSS style rule must be suppressed when the appearance is changed using appearance, even if the UA’s internal representation for this element was composed of multiple elements or pseudo elements combined together.
[...]
However, the UA must preserve aspects of the form control which are necessary to operate the control with its original semantics. This does not include aspects of a control which are merely needed to observe the state the control is in, only those that are needed for the user to be able to modify the state of the control.
[...]
UAs should include in their User Agent stylesheet style rules to give form controls a recognizable shape when appearance is none.

I think:

1. This should be changed to say that the UA must also preserve aspects of a control which are needed to observe the state the control is in if it would not be possible to expose that same information using CSS supported by the UA, and that in that case, the UA must include such style rules in their UA stylesheet rules.
2. Author guidance should be added, recommending judicious use of appearance:none, @supports, and all: unset together
3. The determination of which form control should be treated which way should be left up to each UA, since it depends on what CSS it implements.

It sure would be nice if we could have no UA dependent behavior, and fully determine the behavior of everything in the spec, but I am not sure how to go about that given the broad diversity of form controls and the changing nature of CSS support in browsers.

[frivoal]

Agenda+ to discuss the general approach.

[zcorpan]

Was this discussed at https://wiki.csswg.org/planning/tpac-2017 ? I don't see it in the minutes.

I like what Chrome does for meter and think should be adopted for progress as well. It lets authors show fallback content if they so wish, and gives them flexibility to create an entirely custom widget. (I haven't yet done web compat analysis for progress/meter, though.)

I also think that it could be a good idea to implement the meter and progress widgets using CSS, and expose a pseudo-element to authors to control the inner part (when not appearance: none), so that authors can control the colors etc for the "default" widgets. Thoughts?

cc @MatsPalmgren

[jugglinmike]

@frivoal I can't find discussion on this in the minutes, either. Does it still need face-to-face discussion?

[bkardell]

@zcorpan what is the 'etc' beyond colors?

[zcorpan]

@bkardell I don't know. We could check what browsers allow today with their non-standard pseudo-elements, and check what authors are trying to do with them, and how much they are used, to inform what to do.

[zcorpan]

Behavior for appearance: none for progress and meter is specified in https://github.com/whatwg/html/pull/4857 - no wpt tests yet.

[MatsPalmgren]

I like what Chrome does for meter and think should be adopted for progress as well. It lets authors show fallback content if they so wish, and gives them flexibility to create an entirely custom widget

I disagree that this is a desirable behavior. It goes against how HTML normally defines when fallback content should be rendered - namely that it is intended as a fallback for UAs that don't support the element at all. As the current spec says for <meter>:

Authors are encouraged to include a textual representation of the gauge's state in the element's contents, for users of user agents that do not support the meter element.

appearance:none should only disable the native theme and let authors style it using CSS, that's all.
Showing alternate content is an orthogonal issue.

[zcorpan]

Thanks @MatsPalmgren. I've reverted that part of whatwg/html#4857