[css-forms-1] appearance: base to enable interoperable styling of controls/components

[gregwhitworth]

The below comment is in reference to an explainer level proposal regarding a new pseudo element and a way for an author to opt-in to a standardized DOM and styles, currently being proposed is appearance: base.

@gregwhitworth why not make the proposed behavior for appearance: base be the behavior for appearance: none for radio buttons and checkboxes? Would it not be web compatible? There are likely some sites that use appearance: none plus a background image to show the checkmark, so this would show a double checkmark, though I don't know how common it is. Maybe it's even an acceptable change? The content would still work, just not rendered as originally intended. When styling form controls, that shouldn't come as a huge surprise I would think.

CSS UI says that widgets should be usable even with appearance: none, but checkboxes and radio buttons as implemented today aren't. https://drafts.csswg.org/css-ui/#appearance-semantics

(Feel free to split this into a new issue if you want to separate the discussion around appearance from ::indicator.)

cc @frivoal

Originally posted by @zcorpan in #5914 (comment)

[gregwhitworth]

@zcorpan I had not considered that given that appearance: base takes the step of requiring a defined DOM and styles. You're correct at the definition that the behavior should remain but without that required DOM & styles we don't take a step towards the goal of this which is to enable styling of the built-in control/component without having to replace it.

I don't have a strong opinion regarding the switch that enables that DOM & styles, @frivoal recommended over on the explainer repo a base attribute on the control/component that would likewise enable this and would also not conflate appearance which some people think will lead to author confusion.

You both have more history investigating the appearance property so I'll happily take guidance to ensure that the following goals are met:

1. Requires defined DOM & styles to enable an author to style the control/component
2. Doesn't introduce author confusion
3. Allows user agents & the CSSWG to incrementally enhance more controls & components without compat concerns

@fantasai brought up item 3 with the current proposal of appearance: base as authors may apply it to many controls and thus hindering our future additions. @tabatkins recommended a appearance: base-checkbox style approach to the problem and as noted @frivoal recommended a similar approach but with a HTML attribute.

cc: @tantek as he had opinions on this aspect as well

Also: Thank you all so much for the thoughtful engagement and help on this

[gregwhitworth]

To sum up the possible options for a switch to a defined anatomy and UA styles we have:

• appearance keyword of base-<control> (eg: base-checkbox)
• A base attribute on the control (eg: <input type="checkbox" base>)

With regards to next steps - @tabatkins @frivoal @tantek @jensimmons am I missing any other possible solutions?

[zcorpan]

Don't we want to have a defined DOM and styles for appearance: none?

[bradkemper]

Does using SVG allow more CSS animation than html? Why not use clip path and a background instead?

While I applaud the idea of having standardized stylable component parts in the presence of appearance: base (especially for things like file upload controls), I’m not a fan of that being a single design for all eternity. I would rather allow for platforms to vary it somewhat and update in the future, but perhaps sticking to a limited set of properties, so that authors know which ones they will need to overwrite. Or just let the authors use all: initial.

I am also not against using glyphs, even if different platforms have different fonts. They don’t all have to look identical for this proposal of standardized component parts to be valuable. As long as the author can apply a different font, or use content: "" and a clipping path and background for that part, then it is just as customizable.

[bradkemper]

appearance: base-checkbox on something other than a checkbox would not be good. I thought we were trying to get away from that. appearance: base seems better.

Also, I would prefer to keep this all in CSS. I often can only edit the CSS for a project, not the HTML or JavaScript. Perhaps we could have an at-rule for styles that only apply to elements that have appearance: base. appearance Property values inside the at-rule would be ignored.

[gregwhitworth]

Don't we want to have a defined DOM and styles for appearance: none?

When initially discussing this with @fantasai and @frivoal in the fall 2020 they didn't want overload appearance: none for compat reasons; although that was the initial direction I was heading which is why I actually extend appearance: none with the base solution. The defined DOM structure I think is actually the least of the concerns for compat in this scenario though because properties that wouldn't have worked prior may begin working due to the standardization of base styles. I'm not entirely sure of a concrete scenario however given how appearance: none is most commonly used however. @fantasai @frivoal do you all have one?

Does using SVG allow more CSS animation than html? Why not use clip path and a background instead?

It provides greater flexibility on the parts (eg: paths) with strokes, joint, etc. Also, the minute you have to reach for background assets you've removed one of the key demos for this base solution which isn't to have to reach for any graphics software. It's also important to note that while SVG is currently being proposed for the checkmark that probably won't be the case for all control/component parts much in the same way that when authors create their own today they don't use SVG for the entire control.

I am also not against using glyphs, even if different platforms have different fonts. They don’t all have to look identical for this proposal of standardized component parts to be valuable. As long as the author can apply a different font, or use content: "" and a clipping path and background for that part, then it is just as customizable.

I am due to the limitations of styling to text as outlined in the explainer in comparison to SVG.

I’m not a fan of that being a single design for all eternity

I agree to an extent, this is commonly brought up but if one looks at many of the controls in the platform the models and base UX has remained the same since the webs inception. Upon looking into <select>, checkbox, radio, there are some that have existed prior in the same manner prior to browsers in native OSes and some (eg: checkbox/radio) prior to graphical UI. Some even exist well before mass access to computers existed, here's an example from 1963 with checkboxes, text inputs, date, date-time, etc. The important part to note is that this "design" will be a base but with the standardized DOM & styles they can adjust the look and feel utilizing the powerful layout capabilities we have today provided to us on the web. It will be purposefully plain and simple to give authors a starting point with the expectation that they will/can adjust it interoperably. So while I agree with your position I feel that cow paths are very well trodden in Graphical UI to be able to take a host of controls/components and define their parts and base styles.

appearance: base-checkbox on something other than a checkbox would not be good.

This is a good point and one we'll need to ensure is accurately informed to authors as well in spec text as it will only apply to an HTMLInputElement with a state of checkbox; or other elements as we make progress with others. As appearance: none works today it removes the native styling but doesn't enforce a DOM nor base styles for that DOM. Does that clarify it?

[css-meeting-bot]

The CSS Working Group just discussed appearance: base to enable interoperable styling of controls/components, and agreed to the following:

• RESOLVED: This feature should be solved with an attribute rather than a CSS value

The full IRC log of that discussion

<Rossen_> Topic: appearance: base to enable interoperable styling of controls/components
<Rossen_> github: https://github.com//issues/5998
<myles> gregwhitworth: The context is that we're trying to start down the path of standardizing form controls and components. We'll need an agreed-upon DOM and styles.
<myles> gregwhitworth: Last time I presented on this, I presented about the base appearance keyword and the pseudo element for checkbox. I want to de-tangle them. I've had requests for input type=range
<myles> gregwhitworth: I want to move forward with the base keyword.
<myles> gregwhitworth: For more context, the base keyword would be a toggle that informs the browser that you want to have a standardized dom and styles for a given element. That would allow you to style interoperably.
<myles> gregwhitworth: UAs want to provide their own defaults. Authors need to opt-in.
<emilio> q+
<myles> gregwhitworth: I'm looking for feedback. questions, thoughts.
<Rossen_> ack emilio
<florian> q+
<myles> emilio: If we want this to change the shadow dom that UAs create, this is better as an attribute, despite that option sucking.
<myles> emilio: for gecko, it's kind of okay to create a lot of dom during layout. it's not amazing. I'd like to get rid of that mechanism. Blink generates the shadow dom at the DOM level, not depending on layout.
<myles> emilio: Making CSS changes affect DOM for them, i suspect it would be more of an issue.
<myles> emilio: Conceptually, it feels wrong
<myles> gregwhitworth: Sure. I'm primarily .... not that that's bikeshedding .... I want to get at the more meta-issue. If implementors say they prefer the attribute, I can bring this to WHATWG. I'm asking if this group accepts standardized styles and standarized DOM
<myles> emilio: I'm definitely okay in getting more interop in form controls.
<myles> emilio: This detail probably matters.
<myles> emilio: Can chrishtr weigh in?
<hober> q+
<myles> emilio: Is CSS the right place for this toggle?
<tantek> +1 emilio
<myles> hober: My understanding is that we're also pretty reluctant to add more mechanisms in CSS that cause DOM to get created.
<myles> hober: So, I think, this does seem like a problem we should be trying to solve. An attribute would be less weird.
<myles> hober: ... on the implementation side of things.
<Rossen_> ack florian
<myles> florian: In addition to the implementation complexity, I have 2 other reasons for why attributes are probably better.
<Rossen_> ack hober
<myles> florian: 1. If we got with a CSS property with a single bas keyword, we need to introduce it simultaneously on all the elements that accept it, or have a bunch of values so people can detect their way into doing the right thing. That problem isn't true if we do it as an attribute.
<myles> florian: 2. Depending on whether an element is base or not base, you want to style it differently. If you cause it to be base or not base through CSS, then you can't select on it.
<tantek> +1 florian about what you want to style differently
<myles> florian: The UA stylesheet needs to be different for a regular checkbox vs a base checkbox, if the switch is in CSS, all that solves itself if the switch is done via an attributre.
<Rossen_> ack fantasai
<myles> florian: We have multiple things pointing in this direction. All of these work better if we got with an attribute vs a CSS property.
<myles> fantasai: Just to throw a wrench into that, florian, you want to style them differently based on the attribute, but also on whether or not the browser supports that attribute
<myles> florian: We should have an attribute an attribute AND a pseudoclass.
<myles> fantasai: We can also add an @supports query.
<myles> fantasai: We need a way to answer the question "is this implemented"
<myles> florian: The base pseudoclass would mean "is it present AND implemented"
<fremy> +1 to the pseudo-class suggested by florian
<myles> florian: pseudoclasses are simpler
<tantek> +1 to considering pseudoclass
<myles> fantasai: For style vs content vs behavior, this belongs more in CSS than HTML. But emilio and florian gave good arguments for why it might have to end up in HTML regardless.
<myles> fantasai: If we add appearance: value, I would go for appearance: basic
<tantek> in general I'm opposed to any extension to the 'appearance' property, but that's a lower level concern
<heycam> `input[type=checkbox]:custom`
<myles> Rossen_: Most of the conversation leans toward attribute. gregwhitworth, does that work?
<myles> gregwhitworth: I want a resolution, as ammunition for going to WHATWG
<myles> gregwhitworth: Also for adding styles to checkbox. I'm looking for a resolution.
<myles> florian: 2 resolutions: 1. to use an attribute, and 2. to add a pseudoclass
<myles> fantasai: proposed resolution: This functionality be pursued as an attribute, and CSS adds a mechanism to detect an element in this mode in a browser that has support for it
<myles> gregwhitworth: I'm fine working on that BTW
<fantasai> "CSS Working Group recommends that"
<myles> bkardell_: Wouldn't existing "define" work?
<myles> bkardell_: the "define" pseudoclass
<myles> bkardell_: should work
<myles> bkardell_: I guess not, because it's already defined. never mind
<myles> emilio: It almost works, because you can't extend form controls. But maybe you can. If you can, then it doesn't work
<myles> gregwhitworth: I don't want to go down that rabbit hole
<myles> emilio: It seems cleaner to use a different thing
<myles> Proposed resolution: This functionality be pursued as an attribute instead of a CSS property, and CSS adds a mechanism to detect an element in this mode in a browser that has support for it
<bkardell_> it woudl already be true, is the real problem I think
<myles> florian: I support the resolution as it stands. But I would also support a more specific resolution: the mechanism is a pseduclass. @supports would be awkward. Psedudoclass would make it easy. If we do a pseudoclass, we have to figure out which element you're testing against. Would look like a selector
<bkardell_> 0 specificity pseudo please?
<myles> fantasai: Yeah, this is element-by-element
<myles> florian: It's also applied element-by-element
<myles> fantasai: yeah.
<myles> fantasai: I guess that what it's going to have to be. I can't think of a name that makes sense
<myles> florian: We should match the name that HTML sues
<myles> bkardell_: Can it be 0 specficity?
<myles> gregwhitworth: Can we figure this out after I open the issue?
<myles> bkardell_: yes.
<myles> fantasai: I support greg investigating whether or not it should be 0 specificity
<myles> s/greg/gregwhitworth/
<myles> Rossen: We were leaning toward using an attribute. Second resolution: Adding a mechanism to detect the state of the feature. Is this right?
<myles> RESOLVED: This feature should be solved with an attribute rather than a CSS value
<fantasai> [I would like to note that it's not great that, in order to change the styling of the form element, it's necessary to change the markup. But it seems we're constrained by practical considerations.]
<myles> ACTION gregwhitworth: Create an issue about adding a mechanism in CSS to determine if this feature is enabled

[fantasai]

The reasons given for handling this as an attribute rather than in CSS (even though it is about presentation and otherwise would belong in CSS):

• DOM modifications that depend on CSS computed values are messy/difficult to implement
• We need to be able to style differently depending on whether the element is basic or not, and an attribute allows for selecting against that.
• An attribute is less likely to create the forwards-compatibility problem that rules like * { appearance: base } would create if only some form elements supported basic rendering and others didn't.