[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 #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.

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

[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: #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?

[josepharhar]

I opened this issue with the intention of bikeshedding naming as a next step, as well as a couple other issues for what it will mean for <select>: #10333
We also have the ::picker() issue here: #10440
I'm not opposed to leaving this open, but I'm also not sure exactly what direction to take this issue in for a discussion tomorrow.

[josepharhar]

The "needs edits" label was added so that we can spec this, and we will keep this issue open until the spec is written

[josepharhar]

I created a PR to define appearance:base here: #10691