[css-ui] 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 https://github.com/w3c/csswg-drafts/issues/5914#issuecomment-778089292

[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/w3c/csswg-drafts/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.

[bradkemper]

I get the reasoning of not using CSS for DOM building, but I think the end result of doing an attribute is that instead of doing this:

* { appearance: base; /* etc. */ }

Authors will just do this instead:

*[base]:base { /* etc. */ }

And if they have control over the HTML, they will add the base attribute to every form element whether it is currently supported or not.

And those without control over the HTML won't be able to take advantage of this feature.

I'd still rather have just a pseudo be the switch for whether or not to use the alternate DOM, when it is supported on that element.

Sorry I missed the meeting. It sounds like it was a very interesting conversation.

[annevk]

DOM modifications that depend on CSS computed values are messy/difficult to implement

I wonder if we need this aspect. If we provide sufficient pseudo-elements web developers should have their styling needs addressed as well.

[mfreed7]

So the resolution above was initially this:

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

and I think the second part got accidentally (based on the detailed notes) left off the resolution. Does that sound right?

If so, we need to add a new attribute to HTML that enables interoperable styling on controls that wear it. And we need to add a pseudo class to CSS that matches when an element supports interoperable styling. That leaves a few questions:

1. What should the name of the attribute be? By itself, base seems wrong. It made sense when it was appearance:base, but just base as an attribute feels hard to understand. How about something like interoperable? That feels too long, but at least it explains what it's trying to do.
2. What should the name of the pseudo class be? Perhaps just the same as the name of the attribute? E.g. input[interoperable]:interoperable?
3. How does this attribute interact with appearance? There would seem to be two possibilities. One is that input[interoperable] {appearance:auto} and input[interoperable] {appearance:none} both render the same way, with an interoperable spec-defined set of styles and DOM structure. The other is that only appearance:none does that, and appearance:auto is still up to the UA to define. I think I prefer the former, but I'm not sure.

[zcorpan]

1. I don't like either base (could refer to base URLs or other) or interoperable (things should generally be interoperable). Maybe something like basestyle or stylable?
2. Why is a pseudo-class needed if it only checks the presence of an attribute?
3. It seems to me the former has to be chosen, or it was moot to use an attribute.

[kbrilla]

1. interoperable sound great! Basestyle as a second favorite
2. I would ecpect pseudo is needed to know that basestyle is actually supported for that element and was applied.

[mfreed7]

• I don't like either base (could refer to base URLs or other) or interoperable (things should generally be interoperable). Maybe something like basestyle or stylable?

I kind of like basestyle - it says that it's related to styles, and it has "base" which I like for some reason. I don't like stylable for two reasons - there are two spellings (also styleable) and all controls are stylable in some ways even if they don't have interoperable styling which is what this attribute implies.

• Why is a pseudo-class needed if it only checks the presence of an attribute?

The pseudo class allows for feature detection - it should only match when the attribute is actually supported on a given element. I.e. const supported = document.createElement('select').matches(':basestyle');. If there's a better way to do feature detection element-by-element, I think that'd be fine too.

• It seems to me the former has to be chosen, or it was moot to use an attribute.

I don't understand this comment, sorry.

[SebastianZ]

@mfreed7 wrote:

I kind of like basestyle - it says that it's related to styles, and it has "base" which I like for some reason.

I do so as well. Though note, in CSS, names are generally dash-separated, so it should be base-style.

Sebastian

[SelenIT]

Maybe unstyled could work as the name of this attribute, implying that authors would have to style these controls themselves?

[mfreed7]

I like unstyled also, maybe better actually.

I do so as well. Though note, in CSS, names are generally dash-separated, so it should be base-style.

But this is the name of an HTML attribute, which typically don’t have dashes. Perhaps you’re talking about the pseudo class for feature detection?

[SebastianZ]

I do so as well. Though note, in CSS, names are generally dash-separated, so it should be base-style.

But this is the name of an HTML attribute, which typically don’t have dashes. Perhaps you’re talking about the pseudo class for feature detection?

I did talk about the pseudo-class, yes. I didn't realize before the resolution was to add an HTML attribute and make it detectable in CSS. But given that, the HTML attribute may still be called basestyle. Generally, I believe the attribute name and the name in CSS should be aligned with each other.

Maybe unstyled could work as the name of this attribute, implying that authors would have to style these controls themselves?

Form elements with that attribute will still have some basic styling, right? So "unstyled" may not be fully true. Though as we are searching for something that fits for both HTML and CSS, it might make sense to use a single word to avoid the issue of the names being different due to the different word separation rules in both languages. So "unstyled" sounds ok.

Sebastian

[annevk]

I don't think we should add a new HTML attribute for this. Although it is a bit janky and CSS should probably support it better, it's possible to implement this without a new HTML attribute and adding an HTML attribute for this would be mixing styling and semantics, something which we've managed to avoid doing for a very long time now.

[mfreed7]

I don't think we should add a new HTML attribute for this. Although it is a bit janky and CSS should probably support it better, it's possible to implement this without a new HTML attribute and adding an HTML attribute for this would be mixing styling and semantics, something which we've managed to avoid doing for a very long time now.

Would you mind suggesting an alternative, rather than just saying "no"? This was discussed at length in CSSWG and the conclusion was that an attribute was the best solution.

[annevk]

I'm not sure that was an "at length" discussion, but it's been discussed a number of times since then as well, including in this thread. And the alternative is using a new appearance value and branching code on that. WebKit at least hasn't fully ruled out that option and I wouldn't really want to consider HTML-based alternatives until we're sure we cannot solve this through styling.

[mfreed7]

Ok, sounds like we're back to needing a CSS solution. That's appearance:base and an :appearance-base-supported pseudo-class (name TBD) to detect support on each element. Right?

@hober and @emilio were concerned about changing DOM structure based on CSS property values, I'm not sure if that's still an issue?

I'm still concerned about forward compat issues. While they were possible with a base attribute, it seems a lot less likely for someone to add base to every element on the page than it does for someone to add * {appearance:base} to a stylesheet.

[annevk]

I think the details of the CSS-based solution are still up for debate. Perhaps as a start we introduce one-off values for each control and once we've covered all controls we can add a catch-all and new controls would have to support it out-of-the-box once you support the catch-all. That might allow us to get somewhere incrementally. E.g., we could start by adding appearance:base-radio that would only work on <input type=radio>.

[gregwhitworth]

I appreciate the continued discourse. Since we resolved on using <select> over introducing a new element (eg: selectlist) I would still prefer a CSS based solution even if we have to do the control by control approach that @annevk outlined. Only concern with the CSS approach is the potential performance implications going back to adjust the tree after style calc.

I think for new elements we should follow the resolution of them being interoperable by default and opt in to native UA styling/tree/external control. This is what we resolved on in Open UI when first discussing this which can be found here.

[annevk]

I had not heard of that before. The WebKit team strongly believes that the defaults should be consistent across controls and thus disagrees with that Open UI resolution.

[gregwhitworth]

@annevk yeah, I added this topic to our agenda to discuss tomorrow because since Open UI resolved to use select rather than selectlist based on your feedback; it has the domino effect and it will ultimately result in aligning with WebKit's position.

[mfreed7]

I had not heard of that before. The WebKit team strongly believes that the defaults should be consistent across controls and thus disagrees with that Open UI resolution.

Just to be sure I understand this comment - you're saying you don't think appearance:base (or whatever the API shape ends up being) should be the default. Is that right? I.e. you're still supportive of a way to get to interoperable styles, just not by default? (We're discussing this tomorrow at OpenUI - it'd be great if you could attend to offer your opinions regardless.)

[annevk]

That's correct. Unfortunately Open UI meets at a time that would be disruptive for my sleep. Aditya will be there though.

[pxlcoder]

I'll be there, but will miss the first 20 minutes.

[gregwhitworth]

We can't post our minutes directly here but we just discussed this (we'll carry it forward to next week) in the Open UI telecon. Here are the minutes: https://www.w3.org/2024/01/11-openui-minutes.html

[mfreed7]

Heads-up, there was a discussion about this issue at OpenUI just now, but the notes got mixed in with this issue. We did not conclude our discussion, so it'll be on the agenda for next week as well.

[josepharhar]

Hello! I've been implementing appearance:base-select for the <select> element in chromium instead of a new HTML element or HTML attribute in response to feedback on the WHATWG thread here: https://github.com/whatwg/html/issues/9799

I was able to implement it by including all of the DOM content needed for appearance:auto and appearance:base-select in the <select>'s UA shadowroot, and then excluding certain parts from the layout tree based on the computed value of the appearance property. It is also possible to adjust certain UA styles based on the computed value of appearance based on findings here: https://github.com/w3c/csswg-drafts/issues/10028#issuecomment-2047865990

[josepharhar]

In response to fantasai's comment here: https://github.com/w3c/csswg-drafts/issues/5998#issuecomment-816310082

DOM modifications that depend on CSS computed values are messy/difficult to implement

I was able to implement the CSS property without making any DOM modifications by adjusting the layout tree in response to the computed style.

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.

I was able to change other styles based on appearance here: https://github.com/w3c/csswg-drafts/issues/10028#issuecomment-2047865990

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.

If this is an issue, then we should implement it as appearance:base-select instead of appearance:base.

[fantasai]

Replying to @josepharhar's comment... For the record, I think appearance: base would be a better solution if it can be done. I was just listing the rationale behind the previous discussions.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] appearance: base to enable interoperable styling of controls/components.

The full IRC log of that discussion

<hdv> jensimmons: can you explain the thinking behind using appearance:base-select rather than a generic appearance base?
<hdv> jarhar: yes, it was one of the points of feedback in the first agenda item
<hdv> jarhar: one of the points was that it would have forward compat issues, so when we ship the new thing we would break websites
<hdv> jarhar: would be happy to make a bikeshedding issue for this so that we can choose a name
<florian> q+
<TabAtkins> Yeah, this was proposed by the csswg in a previous discussion
<hdv> jensimmons: feels like there is a larger conversation that needs to happen around the strategy, to make big high level decisions, to avoid spaghetti 5 years from now
<emilio> q+
<TabAtkins> The forward compat concern is very real
<hdv> dbaron: in this case we ended up with base-select because of thinking about the future, to try and keep an obstacle out of the way
<astearns> ack florian
<lea> q+
<hdv> florian: I see the forward compat issue with just using `base`… but there is also a different problem with using `base-select`, what about telling other elements that they are a `base-select`?
<hdv> florian: last time we discussed something like that in CSSWG
<TabAtkins> q+ to answer the base-select on wrong elements question
<hdv> florian: I think we talked about it would be useful, but as its own value so that it would not be overly generic or specific
<hdv> florian: so why should this be a CSS property rather than an attribute?
<jensimmons> Are the slides Joey presented available online?
<chrishtr> jensimmons: Joey posted a link to it earlier in this irc chat
<TabAtkins> jensimmons: yes, linked at the beginning of the call
<hdv> jarhar: I've started implementing this. Thing is we can't modify DOM based on computed style, so I was able to do everything in layout
<hdv> jarhar: someone on my style theme existed we could have something like the light and dark function, but then appearance auto vs base, and that seems to work
<lea> q-
<florian> q+
<hdv> jarhar: third point, if we make it appearance base there is forward compat issue, and with base-selectw we avoid that
<astearns> ack emilio
<jensimmons> q+
<TabAtkins> ack TabAtkins
<Zakim> TabAtkins, you wanted to answer the base-select on wrong elements question
<hdv> emilio: to play devil's advocate re base-select being too specific… there are various already existing bits where this happens. If we get to the future where all form controls have their own appearance:base-something we could in theory introduce appearance base
<hdv> emilio: so we could see base-select as an in between step
<chrishtr> q+
<hdv> emilio: I don't feel too bad about the appearance-something approach
<TabAtkins> Yup, I was gonna say exactly what Emilio is saying here, if used in the wrong elements it'll just act like auto
<una> Agree - we can always limit base-select to select elements
<astearns> ack florian
<hdv> emilio: don't think implementing is somewhat tricky to add something for each form control but it should be fine
<jarhar> the -internal-appearance-auto-base() as ive implemented it is only for two properties
<hdv> florian: I think you made a reasonable on why it is doable to do it in CSS, but why is it preferable?
<hdv> florian: re that it is already the case for some properties… yes, but it goes against the design principles, the concluded we needed none and auto and nothing else
<hdv> florian: so native mode or non native mode would be what this flips between
<jarhar> q?
<hdv> florian: final point of consideration: CSS is primarily used with HTML, but not only with HTML, so other languages that are not HTML would need to define what these form controls are, seems less great if this would only work on HTML
<hdv> jarhar: I brought the HTML optin to WHATWG, there is pretty strong pushback by the editors
<akeerthi> q+
<hdv> jarhar: it does seem to have nice developer ergonomics and get the ability to style it with CSS.
<hdv> chrishtr: another argument was made, since it's really just about the styling it would be good to put it in CSS, it's not about behaviours, it is about styling
<keithamus> q+
<TabAtkins> Re: coupling, while we don't do it *a lot*, we do have a number of SVG-specific properties already.
<astearns> ack jensimmons
<chrishtr> q-
<hdv> jensimmons: how much does the state switching affect the functionality of the form control vs how much does it affect styling?
<florian> qq+
<hdv> jarhar: interoperable keyboard behaviour may be part of this, not sure if that is considered functionality
<florian> q-
<hdv> jensimmons: sounds like you're thinking that with the change, other markup can be put in select, whereas without the change that markup doesn't have the same behaviour inside of select?
<hdv> jarhar: the native picker could use markup to try and add stuff
<hdv> jarhar: one idea was that you could put images inside of options, that still works in the appearance auto mode
<gregwhitworth> q+
<florian> +1 to jensimmons
<hdv> jensimmons: seems like the sense is, we want to do a lot of things with select, so we add the ability to add any HTML… so we need some kind of toggle to specify the New Thing is being used. But it's unclear then if that New Thing introduces new behaviour
<hdv> jensimmons: eg what if the CSS doesn't load?
<hdv> jensimmons: am thinking… maybe we don't need a big toggle switch to enable the behaviour?
<hdv> chrishtr: jarhar did think about these things…the prototype he mentioned earlier did implement these things
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<hdv> masonf: Anne's point seems to be… most of these things are behaviours and it would not be safe (from privacy/security pov) to allow arbitrary content to pop over
<hdv> emilio: not in Firefox
<hdv> masonf: sorry, meant to say in Chromium
<emilio> s/not in Firefox/Firefox restricts the select area to the top level viewport to avoid this kind of spoofing attack
<hdv> masonf: so the point is that moving between old and new mode with a switch in HTML is that it would need to be done piece by piece, CSS switch would make that easier
<hdv> jensimmons: are you assuming we should have `base-*` for each individual form control?
<hdv> jarhar: yes
<hdv> chrishtr: and then in the future we could introduce `base` as a shortcut so that authors don't need to worry about it
<florian> q+
<lea> q?
<hdv> chrishtr: we want to avoid people using `base` to get the hot new stuff, but then opting in to all the things, including things they don't want
<astearns> ack akeerthi
<lea> q+
<astearns> ack keithamus
<gregwhitworth> ack gregwhitworth
<hdv> aditya: if we're using an attribute authors would need to specify that attribute everywhere in their HTML, would be easier to apply it to all your controls with one property
<hdv> keithamus: that was one of Anne's points as well
<hdv> keithamus: to try and represent Anne's opinions… markup represents the data structures, but not necessarily the UI… so if you put a button inside of an option would that button's text content represent the options content?
<astearns> ack fantasai
<hdv> keithamus: to answer jensimmons's question… a lot of the markup stuff would be ported as good as we can to 'old' `<select>`… `appearance: base-*` would be to turn off all the styling but not as agressively as `none`
<florian> q+
<hdv> fantasai: to the extent this is about largely styling… to have one appearance base I think I agree with florian would be best to not do that
<flackr> q+
<hdv> fantasai: it would be nice if we could look into how appearance base could work for all form controls, so that we could try and ship it as one thing rather than creating all the individual ones, which would be more complicated to learn for folks
<hdv> fantasai: that might require a bit more work, but if we can manage to get it to work it would be better to try and do that
<TabAtkins> Note that this is the same thing we did with reading order, for similar reasons
<TabAtkins> I don't think it's possible, fundamentally, to have "base" work while we haven't designed the behavior on everything else.
<TabAtkins> *especially* the moment we start doing the input types.
<hdv> astearns: I realise we didn't start with 'what we want to get out of this', jarhar what would you like out of this for next time?
<hdv> jarhar: @@@
<masonf> I think redesigning all of the form controls is a bit more than "a bit more work".
<jensimmons> I really appreciate the history meeting mode – especially since much of this work has been done previously inside one or two companies. I am glad to be able to catch up and hear where the discussion is at now.
<gregwhitworth> +1 masonf
<hdv> astearns: let's have a summary comment in the issue next time so that folsk can review
<dbaron> I think one of the underlying issues here is that we have CSS discussions that say "X does not belong in CSS" and WHATWG discussions that say "Y does not belong in HTML" and we need to use some of this meeting sorting out that there isn't overlap between X and Y. :-)
<hdv> s/folsk/folks
<masonf> Much of the work has been done in the open in OpenUI, not within a few companies.
<hdv> jensimmons: do feel it was useful to have a history mode meeting this time, and can be more practical next
<hdv> chrishtr: +1
<jarhar> the @@@ was "i would like to get agreement that we should use css, whatever property or value, to opt in to the new mode instead of html"
<hdv> s/@@@/i would like to get agreement that we should use css, whatever property or value, to opt in to the new mode instead of html
<una> +1
<hdv> astearns: we're out of time, but will start scheduling these regularly

[LeaVerou]

In response to @fantasai’s comment in https://github.com/w3c/csswg-drafts/issues/5998#issuecomment-816310082 :

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

That is a separate pain point that should be addressed for authors as well.

• 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.

In what way?

• 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.

Assuming that form controls are actually still functional with appearance: base, this doesn’t actually seem like the end of the world? Compat impact (not just the quantity, but also the type of impact) is a factor to consider when making changes, weighed against the benefit of the change. It doesn’t mean that if there is any compat impact, the change should not be made. In this case, form control rendering without appearance: base is "anything goes" anyway, so I don't see how a base appearance is any different than a different default style for these use cases.

[mfreed7]

Assuming that form controls are actually still functional with appearance: base, this doesn’t actually seem like the end of the world? Compact impact (not just the quantity, but also the type of impact) is a factor to consider when making changes, weighed against the benefit of the change. It doesn’t mean that if there is any compat impact, the change should not be made. In this case, form control rendering without appearance: base is "anything goes" anyway, so I don't see how a base appearance is any different than a different default style for these use cases.

This doesn't bear out in practice. For example, in 2020, Chromium launched a "form controls refresh", which was just a moderate re-styling of the built-in form controls. In a few cases, those new styles changed the size of elements by a few pixels, e.g. by changing padding from 2px to 1px. We had enormous pressure to change back, and quite a bit of web compat breakage that threatened to require us to roll back the project. And that was just from relatively small changes. I would be very concerned if we just said "it'll be fine to break sites that do *{appearance:base} in the future". We would really like to make all form controls stylable as future projects, and this would put that effort at risk.

I think @frivoal said it best when talking about the non-auto/none values of appearance, such as appearance:button. Those are there for historical and backwards-compat reasons, and the eventual end-state is just auto or none. I think this issue adds one more to that list: auto, none, or base. And there's an unfortunate but necessary requirement for some intermediate values (e.g. base-select) for forwards-compat reasons, but the eventual goal is to get back to just the three values once the work is done to add support for base to all form controls. That work will take some time though, so it's not practical to try to retrofit all form controls in one enormous project. (The work to do this just for <select> has been going for 5+ years now. Let's not wait another 20 years to get form control stylability, please. 😃 )

[astearns]

(chair hat off)

It makes sense to me to have an end goal of base that could be enabled (and tested for support) when and if a browser felt the compat issues were low enough.

Since we aren’t there now I think it makes sense to work on form-specific values on the way towards that end goal.

[LeaVerou]

Thanks for the context @mfreed7, that’s very useful.

Is the idea that we’d start with form-specific values like base-select and move towards appearance: base once it works for all elements? Would the specific values be deprecated then?

[mfreed7]

Is the idea that we’d start with form-specific values like base-select and move towards appearance: base once it works for all elements? Would the specific values be deprecated then?

That sounds like a great plan to me! As @astearns said, shipping base could be done when browsers feel comfortable about the compat situation. I think the intermediate values (e.g. base-select) could be deprecated at that point. Is that the current state of e.g. appearance: button? Deprecated? I would think we should do the same thing for base-select.

[hober]

I don't think we would want to deprecate appearance: base-*, because going forward they can be used for granular feature detection, since these things are expected to vary in support from platform to platform

[mfreed7]

I don't think we would want to deprecate appearance: base-*, because going forward they can be used for granular feature detection, since these things are expected to vary in support from platform to platform

Ohh, that's a very good point.

[annevk]

I think we should also consider appearance: base-*-excluding-picker at the same time. This would allow platforms to respect the in-page styling, but still control the picker. And conversely would allow web developers to only worry about the in-page styling, and let platforms worry about the picker.

[josepharhar]

Thanks for the feedback everyone! I feel like this discussion is moving towards what exactly the new appearance value should be, but I still want to know if using CSS to opt into this new mode is something that the standards groups can agree on. I filed a new issue to discuss particular value(s) for appearance here: https://github.com/w3c/csswg-drafts/issues/10333

After going back and forth between the HTML and CSS groups for some time, we currently have each of them implemented as <selectlist> and appearance:base-select respectively in chromium and I'd like some more direction from these groups on which direction I should go in.

For this issue, here is the proposed resolution that I'd like us to discuss next time: "A CSS property will be used to opt in to an interoperable and stylable mode of the select element."

[tabatkins]

Yes, the WHATNOT joint meeting seemed to, iirc, find the idea of using appearance to trigger the switch to be workable, since the only changes needed were on the box tree side, not the element tree. Given that, we should resolve to accept that behavior.

[css-meeting-bot]

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

• RESOLVED: use css to opt into styleable mode

The full IRC log of that discussion

<chrishtr> masonf: joey is doing most of the work on these issues, but is out today so I'm covering
<chrishtr> masonf: there are a number of questions for the styleable form controls area, but 5998 will help to make concrete progress on a key question about opt-in
<chrishtr> masonf: this is about opting in via a CSS property
<chrishtr> masonf: there are various other ways to opt in that were proposed on the issue, and I'd like to get a resolution that the css property is the way forward
<chrishtr> masonf: we could as subsequent resolutions agree on the names of the property and values, but using a css property is the key next step
<chrishtr> astearns: should we go to the presentation now for anne?
<chrishtr> annevk: need about 10 minutes for the presentation
<chrishtr> chrishtr: annevk does this make sense as a goal?
<chrishtr> annevk: oh yes; the presentation talks about the long-term vision, and styling is a part
<chrishtr> annevk: styling opt-in via css makes sense
<dbaron> Joey's slides 2 weeks ago were https://lists.w3.org/Archives/Public/www-archive/2024May/att-0000/appearance_base_select.pdf
<chrishtr> fantasai: deck is about general concepts, best to get started
<astearns> https://annevankesteren.nl/temp/stylable-form-controls.pdf
<chrishtr> annevk: we've been discussing styleable form controls within the webkit team
<chrishtr> annevk: want to lay out a long-term vision for all controls, not just select
<chrishtr> annevk: gives direction for what we want for web developers in this area
<chrishtr> annevk: motivation: markup for form controls is haphazard, want to be uniform and consistent
<chrishtr> annevk: also want to hear from others what they think
<chrishtr> annevk: terminology: in page controls are part of the layout tree, and then there is the picker which is overlaid on the page for some controls.
<chrishtr> smaug: pickers in an OS window or different process, or in-page?
<chrishtr> annevk: depends on the situation
<chrishtr> annevk: there is a "base" style sheet
<chrishtr> annevk: style sheet will be wireframe-like, meets a11y and i18n criteria, supports dark mode
<chrishtr> annevk: it's a starting point from which developers can add enhancements
<chrishtr> annevk: needs various pseudo elements and opt-in
<chrishtr> annevk: opt-in would be appearance: base, which also opts into the base style sheet
<chrishtr> annevk: for styling pickers we were thinking that these need pseudo elements for overlay boxes
<masonf> q?
<masonf> q+
<chrishtr> annevk: maybe these styles are available for appearance:none mode as well as appearance:base
<chrishtr> annevk: might introduce inline control theming first and then add styling for pickers later
<florian> q+
<chrishtr> annevk: think we might be able to do all of the in-page controls in a timeframe of 1-2 years
<chrishtr> annevk: including base style sheets
<chrishtr> annevk: after that would be pickers, but might not be able to do them all at once or quickly
<chrishtr> annevk: would be great to hear more long term visions from others; alignment and agreement will ensure good web developer and user experience
<flackr> q+ to ask whether select is in page, a picker or either or
<chrishtr> annevk: don't mean to impede or slow down the progress made on select
<chrishtr> annevk: we can do both the short term work already done for select as well as define a pattern for other controls
<emilio> q+
<brecht_dr> q+
<chrishtr> astearns: point of order, would like these presentations to be in the issues before the meeting rather than presented live w/o opportunity for prior feedback and dicsussion
<astearns> ack masonf
<chrishtr> masonf: +1 to that point
<chrishtr> masonf: thanks for the presentation, the deck looks mostly aligned with what my team was thinking
<chrishtr> masonf: one possible departure is pickers
<chrishtr> masonf: one important design consideration we think is important is being able to put arbitrary content in pickers if they are not part of the page
<chrishtr> masonf: the in-page part of the select is styleable (but only allows text content, which is a restriction)
<chrishtr> masonf: the picker is the main area that is not styleable
<Luke> q+
<astearns> ack fantasai
<chrishtr> masonf: not sure the priority is in the right order therefore, since the deck proposes doing in-page first and then pickers
<chrishtr> fantasai: want to provide some more context about what webkit is proposing
<chrishtr> fantasai: incremental rollout is important, that is a consideration.
<chrishtr> fantasai: talked with tim and jen about all this and there were some concerns about DX of per-control values
<chrishtr> fantasai: want the end state to be easy to use
<astearns> q+
<chrishtr> fantasai: want things to be consistent, so that might meaning shipping stuff in a batch
<masonf> q+
<chrishtr> fantasai: for pickers it might be hard but think we can do all of the form controls at once for in-page parts. this is part of why the proposal for 2-phase
<chrishtr> fantasai: agree that the picker being styleable earlier for select since that's a strong need for developers
<chrishtr> fantasai: ::picker pseudo element suggestion is not enough to style all pickers and there'd need to be pseudo elements for the important parts of them also
<astearns> ack florian
<fantasai> s/for developers/for developers; and also it's a lot easier to do because the parts all have representation in the DOM/
<chrishtr> florian: I like the direction this is going in, was previously nervous about base-*
<chrishtr> florian: seemed like a design smell to enumerate all form controls as values
<fantasai> s/parts of them also/parts of them also, ::picker is just meant to represent the overlay box itself/
<chrishtr> florian: we ended up having some special values in the existing appearance property due to compat
<chrishtr> florian: perhaps we do need a few special cases to get there, and we could do that if needed for specific controls that are hard to evolve without compat problems
<chrishtr> florian: there is a desire for more flexible content to put into controls
<chrishtr> florian: want to talk more about the ability to opt into more flexible content rendering as triggered by a css property
<chrishtr> florian: could work, but want to learn more about it
<fantasai> Slides: https://lists.w3.org/Archives/Public/www-archive/2024May/att-0004/stylable-form-controls.pdf
<chrishtr> florian: if pickers need to be done not all at once can we do it with one value?
<emilio> Why not different pseudo-elements like ::select-picker and so on?
<TabAtkins> Ah, I didn't get that ::picker(ident) was a specialization there, okay.
<zcorpan> Would @supports(::picker(select)) work?
<chrishtr> annevk: replying to feature detection for pickers, idea was to have multiple values, but they would be part of the pseudo-element name, not the value of a css property
<fantasai> emilio, 2 reasons - 1 have a common prefix to represent the set, and 2 - want to have the ability to style them all (eventually)
<astearns> q?
<fantasai> zcorpan, @supports(selector(:::picker(select))) should work, yes
<Luke> Does * or ::picker(*) match any of the pickers? I would assume no?
<chrishtr> annevk: if your platform or browser doesn't support it yet then the pseudo element would not be present
<astearns> ack dbaron
<Zakim> dbaron, you wanted to comment on different priority of pickers for different controls
<chrishtr> annevk: for example, ::picker(file) might not exist
<fantasai> Luke, not currently, no but we may get there if we can make them enough of them styleable that adding that later wouldn't cause compat problems
<ntim> ntim: (Pasting what I wrote in Google meet: `::picker(select)` would be exist along with all the HTML parser changes / <selectedoption> Chrome has worked on, but in our vision, what opts in rendering the picker customization would be `::picker(select) { appearance: base/none }` (not `select { appearance: base-select }`)
<emilio> fantasai, doesn't that introduce the same compatibility issue you're trying to avoid? (where we add a new picker in the future that now get weird styling the author didn't expect?)
<chrishtr> dbaron: when you were talking about the in-page then pickers plan, one point I'd like to raise is that the demand for customizing pickers depends on the form control
<fantasai> emilio, ::picker(*)? Yes, which is why we wouldn't introduce it now and take it under consideration for later.
<chrishtr> dbaron: for example, developers don't seem to really want to customize a color picker right now, but they do really want to customize date picekrs
<chrishtr> dbaron: they also want to customize content for date pickers, e.g. by supplying pricing associated with dates
<zcorpan> q+
<chrishtr> annevk: this might involve new html elements, is that what you're saying?
<chrishtr> dbaron: not sure, but maybe
<chrishtr> dbaron: if we work on pickers and then need to change in-page aspects, then would we need a second phase of opt-in and lose the opportunity to upgrade?
<chrishtr> annevk: don't think so because the changes would be semantic/HTML, and so should be allowed to extend existing built-in modes and not just the styleable mode
<ntim> dbaron: Our vision allows for tackling pickers first (through `::picker(datetime) { appearance: none/base }`)
<chrishtr> annevk: there will need to be a base style sheet and then for each additional feature there might be additions to style sheets accordingly
<astearns> ack flackr
<Zakim> flackr, you wanted to ask whether select is in page, a picker or either or
<chrishtr> flackr: interesting that you brought up non-in-page pickers
<chrishtr> flackr: would that mean allowing custom content in non-in-page pickers?
<chrishtr> flackr: for select we're pursuing in-page pickers to make them customizable with content, but appearance: auto and date pickers are in another window
<chrishtr> annevk: in styleable mode the picker would be part of the layout tree
<astearns> ack emilio
<chrishtr> chrishtr: in other words, in styleable mode everything would be part of the document layout tree; the distinction in the deck anne presented is just about project ordering and features, not about rendering model
<chrishtr> emilio: do you envision appearance: base for buttons being different than appearance: none? how much change to style sheet?
<chrishtr> fantasai: for simple controls the diff from existing style sheets would be minimal. for radio buttons it'd likely be more substantial
<chrishtr> emilio: difference between appearance:none and base not particularly important, we can just agree on styles that are shared in most cases?
<chrishtr> fantasai: appearance:base should be wireframe, doesn't need a reset style sheet, meets basic requirements, but not at all opinnionated
<chrishtr> fantasai: appearance:none has compat problems, hence appearance: base changing styles
<dbaron> ("doesn't need a reset style sheet" could mean different things to different people!)
<chrishtr> emilio: aware of Google's implementation approach which seems sensible, would the changes envisioned by webkit work with thta?
<chrishtr> emilio: that?
<fantasai> s/more substantial/more substantial beacuse currently they disappear in 'appearance: none'/
<chrishtr> annevk: Joey's approach should work for anything?
<chrishtr> masonf: yes but devil may be in the details
<chrishtr> emilio: could result in overly complicated browser engines if there are a lot of or complicated styles in appearance:base mode
<astearns> ack brecht_dr
<chrishtr> brecht_dr: idea of the picker that raised confusion for me was that in open ui we played around with elements targeted with css
<chrishtr> brecht_dr: will we be able to do this in general, and allow no-datalist markup?
<chrishtr> brecht_dr: the proposal seems compatible with this, is that right?
<chrishtr> annevk: seems so, but new pseudo elements also needed sometimes? or maybe optgroup etc can be targeted directly
<chrishtr> annevk: base style sheet also works with existing controls, so should be able to target anatomy of the existing controls
<chrishtr> fantasai: we'd probably want a pseudo element for the drop-down arrow
<chrishtr> fantasai: should be consistent with the datalist model, shouldn't need to care whether developer provided that element or not
<chrishtr> brecht_dr: if there if flexibility in the system then perhaps picker and in-page should be released at the same time for a control to make things simpler for developers?
<chrishtr> fantasai: appearance: base for all things can be done, but also bringing up the picker for select and shipping together because it's important and further along
<chrishtr> q?
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<fantasai> s/and shipping together//
<fantasai> s/along/along, and also because the components of the picker are already in the DOM -- we don't have to figure out the internal structure of the picker with pseudos or something, it's right there in the page/
<chrishtr> Luke: some things said resonate. won't solve every problem with CSS, need HTML changes also
<chrishtr> Luke: makes sense to do in-page first generally, and in particular because there are lots of controls without significant pickers
<fantasai> i/Luke: some/fantasai: If we use ::picker(select) { appearance: none; } to opt into styling select, then we don't need to introduce 'appearance: base' to enable styling the picker/
<chrishtr> Luke: lots of customizing for date pickers is new behavior, not just CSS
<chrishtr> Luke: base styles is a good start rather than the finish
<chrishtr> Luke: like the idea of the ::picker pseudo selector/element, solves some future compat problems
<chrishtr> Luke: considering buttons, there are differences today among browsers and platforms, matching in appearance:base mode would be great
<chrishtr> Luke: wondering again how much can be in CSS
<astearns> ack Luke
<astearns> ack astearns
<astearns> ack masonf
<chrishtr> masonf: question: my understanding from the presentation is that with ::picker there'd be a standardized shadow dom
<chrishtr> masonf: also heard there would be arbitrary content, could you clarify?
<chrishtr> astearns: let's discuss picker questions in a new issue
<chrishtr> masonf: sounds good
<fantasai> mfreed, we don't have a specific plan for the various pickers, we just want to use ::picker() as a way to opt into styling them one at a tyle
<chrishtr> masonf: proposal is to avoid having separate values for appearance because that's not ideal, and then boil the ocean and would be hard to do all at once
<florian> q?
<chrishtr> astearns: what I heard is let's boil as much as the ocean as we can but being reasonable. e.g. maybe we can special case a few situations like select
<chrishtr> fantasai: ?
<fantasai> s/?/not trying to boil the ocean, just trying to boil the minimum amount of ocean necessary to give developers a good experience/
<chrishtr> annevk: not saying we should extend all form controls in as fancy a way as select needs, just that we'd achieve the basic styleability of existing controls
<florian> q+
<chrishtr> masonf: think this might end up more complex than anticipated, because we might need a new element for even simple cases when we realize it should be possible
<chrishtr> fantasai: still need to style existing elements
<zcorpan> What I wanted to say: (1) if priorities suggest doing in-page pickers for only some of the controls, we can have `base` and `base-foo` (for all controls when implemented) so authors can feature-check with @supports but also can use `base` for any control. (2) Does appearance: base turn off button layout magic or no?
<astearns> ack Zakim
<astearns> ack zcorpan
<fantasai> If we're concerned about select specifically, the issue is styling the picker, so we would use `::picker(select) { appearance: none; }`
<masonf> The concern is that people do *{appearance:base} and then it breaks later when a browser starts supporting it.
<chrishtr> zcorpan: should we use appearance: base as a trigger to turn off button layout
<chrishtr> emilio: didn't ian have a plan to do that w/o new CSS?
<chrishtr> chrishtr: yes
<zcorpan> light-dark()-like seems OK
<chrishtr> florian: should we do it in CSS? yes. need more discussion about details
<masonf> +1
<chrishtr> RESOLVED: use css to opt into styleable mode
<ntim> I think `::picker(select) { appearance: none }` would allow Chrome to ship select first, without introducing a new `appearance: base-select` value or trying to tackle the whole of `appearance: base` first
<tantek> I tried different 'appearance' values for different clusters of controls as well as specific controls, literally in the earliest versions of the appearance property. This does not work for various reasons. Unfortunately most of that experience (though documented in www-style / w3c-css-wg / various CSS UI drafts) is 20+ years old
<tantek> here you go, wow literally 20 years ago merely days ago: https://www.w3.org/TR/2004/CR-css3-ui-20040511/#system
<dbaron> astearns: I would like to have a separate issue for ::picker()
<tantek> RRSAgent, make minutes

See Generated Minutes

[mfreed7]

So just a quick followup: the plan is for @annevk or someone to open a fresh issue describing the ::picker() proposal in more detail. Is that right?

[benface]

From the minutes:

<chrishtr> zcorpan: should we use appearance: base as a trigger to turn off button layout
<chrishtr> emilio: didn't ian have a plan to do that w/o new CSS?
<chrishtr> chrishtr: yes

I'm not sure what this means, but sounds like appearance: base could be the fix to #3226? 👀

[josepharhar]

Can we close this issue now that we got a resolution?

[annevk]

Would we have a separate issue then to specify it?