[css-ui-4] Define how to compute the kind of widget to use for an element

[howard-e]

[css-ui-4] Define how to compute the kind of widget to use for an element. Relevant to #3526 (comment).

Tests:

• HTML: Compute kind of widget web-platform-tests/wpt#30267

[zcorpan]

Nice @howard-e! Some comments mostly on cross-references and dfns

[frivoal]

Edit: moved this text to be a comment in the issue rather than on the PR, since my question is about the approach rather than the details. #3526 (comment)

[zcorpan]

@frivoal that happens so rarely that I think it's a non-problem. The property behaves differently for different kinds of widgets, how would you define it without listing them?

[zcorpan]

The content now looks good to me! 👍

Reading the generated spec and the surrounding context, I'm not sure the placement is ideal. I think it makes more sense to introduce a new section, before "Effects of appearance on Decorative Aspects of Elements", called something like "Computing the kind of widget".

[zcorpan]

LGTM

[zcorpan]

It turns we have missed to specify steps for "radio" and "checkbox". I think they should be similar to progress-bar/meter, i.e. authorProps doesn't result in 'none' appearance.

Also "listbox" (<select multiple>), which I think should be like button

[zcorpan]

whatwg/html#7004 hooks into this from HTML

[zcorpan]

menulist had regressed in the rewrite, compare with https://github.com/whatwg/html/pull/4857/files#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dR112533-R112536

Fixed in 179b8cb

[zcorpan]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1730147#c5 @emilio wrote

For meter, Chromium has the same rendering between the two, while WebKit and Gecko have different rendering. But for progress all browsers seem to agree to have different appearances (the second being like appearance: none).

I think ~all browsers agree on disabling native styling when backgrounds/borders are specified on ~all html-exposed widgets except checkboxes and radios. So I'm not sure why meter would be different, so I think Gecko/WebKit behavior is slightly better.

When I worked on this originally, browsers were less consistent, and the appearance: none rendering for progress and meter in some browsers was no style and render the children (like a span). There were objections to that behavior, and it has now changed in browsers. But it seems the new normal is to do the fallback thing for progress and meter. See #356

[css-meeting-bot]

The CSS Working Group just discussed Kind of widget for an element.

The full IRC log of that discussion

<emilio> topic: Kind of widget for an element
<emilio> github: https://github.com//pull/6537
<emilio> florian: haven't looked into this recently
<emilio> astearns: I think we should accept the edits and file issues if there are remaining problems
<emilio> fantasai: I'd like that to be conditional on florian's approval
<emilio> florian: Can we defer this to next week? Need to check changes were made
<emilio> Rossen_: yeah, that's fine, don't want to get that landed and then review it

[frivoal]

Please see the comment I left in the issue that is PR addresses: #3526 (comment) and #3526 (comment)

[css-meeting-bot]

The CSS Working Group just discussed [css-ui-4] Define how to compute the kind of widget to use for an element.

The full IRC log of that discussion

<emeyer> Topic: [css-ui-4] Define how to compute the kind of widget to use for an element
<emeyer> github: https://github.com//pull/6537
<emeyer> florian: I reviewed this a while back. No issue with the specifics; issue with the overall approach.
<emeyer> …Overall, I think it’s odd to have a CSS spec define every type of HTML widget.
<emeyer> …The definition of a text field is “a one-line input that looks like a text field”. That’s almost tautological.
<emeyer> …Definitions of inputs should be over in the HTML spec. I think we should define widgets that define like foo, those that act like blah.
<emeyer> …If we think this is the right approach, the text content is fine. But I don’t think this is the right approach.
<emeyer> zcorpan: I co-authored this. I hear two things. One: the algorithm should refactor so it doesn’t repeat. Two: the definitions are vague.
<emeyer> …If the WG thinks descriptions of rendering should be in HTML, that’s fine with me.
<emeyer> florian: The way they look is tied to how they behave and what they do. All these are sort of kind of replaced elements, but they seem outside of the scope of what CSS controls, in terms of both appearance anad behavior.
<emeyer> …If we want to specify their appearance in detail and think the specifics of that should be in CSS, I see why you want it here.
<emeyer> …Do we expect that this would define how things would look in not-HTML languages? That seems odd.
<emeyer> zcorpan: For the applicability of other languages, I see that as hypothetical.
<emeyer> florian: You can style plain XML with CSS.
<emeyer> zcorpan: I don’t see why someone would want to invent a new language that recycles stuff from HTML.
<emeyer> florian: I stand by my original position, but I feel less strongly about it.
<emeyer> …This seems like it touches on OpenUI and what they plan to do.
<emeyer> astearns: Any other opinions?
<emeyer> …Florian and Simon, do you think we can resolve on this today, or should we pull in others?
<emeyer> florian: I think refactoring is good, we can at least do that. We should also talk with Greg [Whitworth].
<bkardell_> there is open agenda space in the openui call - suggest you add it?
<emeyer> zcorpan: I don’t think it’s super urgent at this point.
<emeyer> florian: This has helped me progress. We’ll get back to this later?
<bkardell_> there is a call tomorrow
<emeyer> astearns: We’ll take this back to the PR and the issue and see what we can do there.

[zcorpan]

Open UI discussed this today: https://www.w3.org/2022/02/03-openui-minutes.html

RESOLUTION: For elements without a concept of native appearance, we should use appearance: none.

[zcorpan]

@frivoal can you clarify how you envisioned the algorithm would be refactored? Since there's no connection between the term "can be a button" and "kind of widget/button", we'd need to specify that mapping somehow.

[zcorpan]

This change, which was implemented and shipped in Chromium and Gecko in 2020, not landing in the spec yet is now blocking implementation in WebKit and thus blocking interoperability improvements. See web-platform-tests/wpt#33401

@frivoal 's request to refactor is an editorial change, and so I'd like to push back on that at this point. We can track it in an issue.

Can we merge?

[zcorpan]

The corresponding PR for HTML whatwg/html#7004 has been reviewed and is ready to merge when this PR is merged.

[css-meeting-bot]

The CSS Working Group just discussed Compute the widget for an element.

The full IRC log of that discussion

<TabAtkins> Topic: Compute the widget for an element
<TabAtkins> github: https://github.com//pull/6537#issuecomment-1083049538
<TabAtkins> florian: We discussed this last time, and I think we agreed that doing an editorial refactor was desriable
<TabAtkins> florian: But the convo, largely by my fault, fell by the wayside and hasn't made progress
<TabAtkins> florian: So request is to merge now because I have no substantive disagreements, and track the editorial refactor separatey.
<TabAtkins> florian: Seems reasonable, only hesitant is the changes to address the editorial bit have to land in both HTML and CSS, and it seems easier to get them done before.
<TabAtkins> florian: So if considered reasonable I'd like to have one week to try and finish the changes, but if tha'ts too much I yield
<TabAtkins> astearns: otoh, we could just merge this, have you do the check, and if there's something you want addressed before HTML picks up the change you have a week to pick that up
<TabAtkins> florian: HTML is waiting for us, so once we merge they'll probably merge
<TabAtkins> astearns: Fair. Anyone prefer merging now rather than waiting one more week?
<TabAtkins> [silence]
<TabAtkins> astearns: Okay, you have a deadline.

[frivoal]

Alternative refactored version posted here: #7224

[frivoal]

Closing as retracted, since @zcorpan (and the WG) accepted #7224 as a preferable alternative.