[css-ui-4] Provide hooks for HTML to define rendering for widgets

[frivoal]

@fantasai and I gave a stab at the refactoring of #6537 we had been talking about in #3526. Goal: avoid having to talk about specific HTML elements in the CSS spec, and in particular, avoid having to have long lists of types of widgets.

Doing that was undesirable because:

• CSS, at least in theory, is not limited to HTML.
• The descriptions of each types of widgets were stubs “a button is a widget which must have the native appearance of a button”, while the HTML spec held the actual descriptions of the rendering of various elements in its Rendering chapter.
• This created a bunch of unnecessary indirections between the two specs, making both of them longer and harder to read than necessary.

The resulting spec is much more straightforward and much shorter, so we think this is a better approach.
This PR is the CSS part of this refactor. For the HTML part of the refactor, look here: https://github.com/frivoal/html/pull/new/appearance-compute-widget-3-updated-take-2 (Note: this is not yet submitted as a PR, pending CSSWG review). The HTML part is complete in the sense that it works with the CSS part, but like the original PR from @zcorpan, lacks details about the rendering of each type of widgets. I'd expect the HTML folks to keep iterating from there.

[zcorpan]

Thank you! This indeed seems like a nicer solution. I see that <input type=search> with appearance: textfield and <select>'s devolved state being menulist-button are handled in https://github.com/frivoal/html/pull/new/appearance-compute-widget-3-updated-take-2 , so that's good.

From a first read, it looks equivalent except:

• transition origin is excluded (as per [css-ui-4] appearance-disabling property origins #7215)
• revert-level is handled the same as revert. Is this intended to be revert-layer?

[css-meeting-bot]

The CSS Working Group just discussed HTML widget rendering PRs, and agreed to the following:

• RESOLVED: Acccept Florian's pr (7224) and submit the corresponding one to HTML.

The full IRC log of that discussion

<TabAtkins> Topic: HTML widget rendering PRs
<TabAtkins> github: https://github.com//pull/7224
<TabAtkins> florian: A while back, zcorpan made a PR against CSS UI and HTML to link the specs together better, and give HTML a way to define how appearance:none works for the different widgets
<TabAtkins> florian: The two specs shared an algo for exactly how the appearance disabled, etc
<TabAtkins> florian: Normatively it was fine, but editorially I thought the css/html split wasn't ideal. The CSS spec ended up defining a button, slider, dropdown, etc, but in a very lightweight way.
<TabAtkins> florian: Then there was back-and-forth bouncing for the dfns.
<TabAtkins> florian: This new PR reorganzies the concept, putting the hTML-specific stuff into HTML and defining some concepts in CSS that HTML can rely on
<TabAtkins> florian: Luckily zcorpan likes the rebalancing.
<astearns> q+
<TabAtkins> florian: And for clarity I did this with fantasai so that makes three of us that like it
<TabAtkins> Rossen_: Just reitering, looks like zcorpan likes the approach, and it's equivlaent except transform-origin
<astearns> q-
<TabAtkins> florian: Right, forgot that normative difference. We have a separate issue for that question.
<TabAtkins> Rossen_: Second question is about revert-level vs revert, he was wondering if this was meant to be revert-layer
<TabAtkins> florian: defer to fantasai
<TabAtkins> fantasai: Yes, of course
<Rossen_> q?
<TabAtkins> florian: So proposed resolution is, after correcting the revert-level mistake, accept the PR and submit the corresponding HTML half as well
<TabAtkins> Rossen_: Comments or objections?
<TabAtkins> RESOLVED: Acccept Florian's pr (7224) and submit the corresponding one to HTML.

[frivoal]

From a first read, it looks equivalent except:

• transition origin is excluded (as per [css-ui-4] appearance-disabling property origins #7215)

Correct. Let's get to the bottom of that difference in that issue.

• revert-level is handled the same as revert. Is this intended to be revert-layer?

Oops. Nice catch, thank you. Fixed.

[Loirooriol]

What about

@layer {
  .widget { border-left-style: solid }
}
@layer {
  .widget { border-left-style: revert-layer }
}

The cascaded value is revert-layer, but the native appearance should be disabled anyways since the specified value will be border-left-style: solid.

[frivoal]

filed as #7252