[css-ui][html] Layering concerns for 'appearance'

[zcorpan]

https://drafts.csswg.org/css-ui-4/#appearance-switching

The button value, if applicable to all elements, probably needs to be specified in css-ui what it does. Other values might be specified in HTML's rendering section.

There are also properties that turn off the appearance (e.g. an author-specified border on a button). In Firefox this applies to appearance values regardless of element, in Chromium this depends on the element. (Specify in HTML?)

@annevk raised in a conversation today that the layering here should be discussed. Can you elaborate here?

cc @bzbarsky @frivoal @fantasai @MatsPalmgren @tkent-google

[annevk]

What I'm worried about is that on the HTML side we'll have this thing where we branch on element (and its attributes) and decide on a render algorithm. This render algorithm might then further branch on appearance. On the CSS side we might use appearance to decide on a render algorithm for the remaining elements. That feels a little circular and depending on how you resolve it you either end up with the Chromium or Firefox behavior.

I guess what you want is some kind of algorithm that takes in the element and its set of properties, and then returns what kind of thing to render. However, that means CSS ends up depending on some HTML-specific thing or we'd define the whole thing in HTML.

[fantasai]

We don't have to define the whole thing in HTML, we just need to define as much as we can that's consistent in CSS with some explanation of the various classes of exceptions, and then HTML can specify which elements trigger which exceptions. This isn't too different from how we define pseudo-classes.

For convenience in developing the spec, I've suggested we keep the per-element details in a separate chapter of css-ui-4, then once it's stabilized we can move it over to HTML. But appearance and its values should all be thoroughly defined in CSS UI.

[frivoal]

@zcorpan, @annevk Between the state of the css-ui-4 spec, and the direction the HTML spec is taking with whatwg/html#4857, I think the layering concern question is answered. Not all the pieces have fallen into place yet, but we seem to know where we're going.

Are you ok with closing this issue, or am I missing something that still needs to be discussed here?

[annevk]

If someone could summarize the agreed upon layering that'd help. (Or point to where that was discussed.)

[zcorpan]

I don't think this is addressed, yet.

[zcorpan]

Thinking about this again, I think most of the logic around 'appearance' could be in css-ui. HTML would only provide algorithms to determine whether an element, given a computed 'appearance' value, can be a specific kind of widget.

Something like this, using the current state of whatwg/html#4857

css-ui

The possible kinds of widgets are none, button, searchfield, textfield, slider-horizontal, checkbox, radio, listbox, menulist, menulist-button, textarea, progress-bar, and meter.

UA must run this at used value time: compute the kind of widget to use for an element element:

1. If computedAppearance is 'none', then return none.

2. Let computedAppearance be the computed value of element's 'appearance' property.

3. Let authorProps be a map of all properties that have a cascaded value for element, where the Author Origin, Animation Origin and Transition Origin cascade origins are included and the User Origin and User Agent Origin cascade origins are ignored, where the key is the property name and the value is that cascaded value.

4. If element can be a button, given computedAppearance, then return the appropriate widget with authorProps set to authorProps, expected set to button, and fallback set to none.

5. If element can be a textfield, given computedAppearance, then return the appropriate widget with authorProps set to authorProps, expected set to textfield, and fallback set to none.

6. If element can be a searchfield, given computedAppearance, then return the appropriate widget with authorProps set to authorProps, expected set to searchfield, and fallback set to none.

7. If element can be a slider-horizontal, given computedAppearance, then return slider-horizontal.

8. If element can be a menulist-button, given computedAppearance, then return menulist-button.

9. If element can be a menulist, given computedAppearance, then return menulist.

10. If element can be a textarea, given computedAppearance, then return the appropriate widget with authorProps set to authorProps, expected set to textarea, and fallback set to none.

11. If element can be a progress-bar, given computedAppearance, then return progress-bar.

12. If element can be a meter, given computedAppearance, then return meter.

13. Return none.

The appropriate widget, given a map of properties authorProps, and an expected kind of widget expected, and a fallback kind of widget fallback, is as follows:

1. For each prop of the properties that disable native appearance for widgets:
   1. If authorProps[prop] exists, and it is not "revert", then return fallback.
2. Return expected.

The properties that disable native appearance for widgets are:

• 'background-color'
• 'border-top-color'
• 'border-top-style'
• 'border-top-width'
• 'border-right-color'
• 'border-right-style'
• 'border-right-width'
• 'border-bottom-color'
• 'border-bottom-style'
• 'border-bottom-width'
• 'border-left-color'
• 'border-left-style'
• 'border-left-width'
• 'border-block-start-color'
• 'border-block-end-color'
• 'border-inline-start-color'
• 'border-inline-end-color'
• 'border-block-start-style'
• 'border-block-end-style'
• 'border-inline-start-style'
• 'border-inline-end-style'
• 'border-block-start-width'
• 'border-block-end-width'
• 'border-inline-start-width'
• 'border-inline-end-width'
• 'background-image'
• 'background-attachment'
• 'background-position'
• 'background-clip'
• 'background-origin'
• 'background-size'
• 'border-image-source'
• 'border-image-slice'
• 'border-image-width'
• 'border-image-outset'
• 'border-image-repeat'
• 'border-top-left-radius'
• 'border-top-right-radius'
• 'border-bottom-right-radius'
• 'border-bottom-left-radius'
• 'border-start-start-radius'
• 'border-start-end-radius'
• 'border-end-start-radius'
• 'border-end-end-radius'

HTML

To determine if an HTML element can be a button, given computedAppearance: localName is "button", or localName is "input" and inputState is one of Button, Submit, Reset, or Color.

(etc, see "compute the kind of widget" in whatwg/html#4857)

[annevk]

Thank you for writing that up @zcorpan! That's a very clear proposal and matches the high-level architecture outlined by @fantasai in #3526 (comment). I hope that model works for implementations.

Nit: "can be a button" needs a default of some sort as otherwise it seems undefined for a number of elements.

[frivoal]

WRT #3526 (comment), this should be specified, but I am not convinced it be in the CSS spec. Not only should the host language own which elements can be an X, but it seems to me it should also own the list of widget types elements can be. Otherwise, HTML cannot introduce new types of widgets without first depending on an update in CSS, and that seems backwards.

[frivoal]

My comment above used to be in the pull request, but I moved it here since it's more a question about the general approach than about the details of the PR. Over there, @zcorpan said:

@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?

As far as I can tell, there's a generic logic which applies to most widget types, and a few are special cased. We can continue to define in the css spec what you do in those special cases, but frame the rest generically, and let HTML own the full list. Wouldn't that work? Potentially, we could even simplify further, as we don't seem to have many different types of special cases, but just two buckets: those where we care about authorProps and those where we don't. We could just define these two buckets here, and let HTML define the full list and say which widget goes in what bucket.

[zcorpan]

OK, that seems fair enough.

[annevk]

I don't think it's backwards that HTML would need CSS to be updated for widget types that require novel layout. In fact, that seems perfectly normal to me. Why would it be backwards?

[fantasai]

I filed #7215 against the proposal detailing which cascade origins are inspected.

[frivoal]

Alternative refactored PR posted here: #7224

[frivoal]

The CSS side of this has been landed, but I suppose we should keep this open until whatwg/html#7839 lands as well.

[zcorpan]

whatwg/html#7839 was merged, closing.