[select] How to enable interoperable DOM, behaviors and user-agent styles for <select>

[gregwhitworth]

Definition of interoperable UI that ships in the web platform

Prior to outlining the potential solutions it’s important to outline the problem that we’re trying to solve. Open UI aims to introduce new solutions for fully styleable and extensible UI widgets that ship with HTML. In order to achieve this it requires standardized DOM, user-agent styles and behaviors.

Potential solutions

1. CSS appearance: base

Styling is one of the top reasons for taking on this initiative and the solution for this was to originally leverage a new appearance value of base. In recent discussions, for backwards compatibility we’ll need to introduce base- (eg: appearance: base-select).

Pros

• Easy Developer Experience
  • Allows * { appearance: base-select, base-radio }
• Has Apple Support

Cons

• This implies to the developer that the only thing changing are its styles but it’s also changing DOM and behaviors
• Update to the DOM and behaviors requires style computation which results in the engine having to go back to DOM creation which may lead to performance issues if many elements are leveraging this capability; or at a minimum this might make the implementation more complicated.

2. HTML attribute

Leverage a HTML attribute such as <select base> which results in the DOM, behaviors and subsequent styles in the user-agent style sheet

Pros

• Avoids needing to go do style calculation and then go back to DOM to result in an interoperable widget
• Allows interoperable DOM, behaviors and expanded capabilities without requiring interoperable styles

Cons

• Requires the developer to place the attribute on every element they want an interoperable DOM and styles
• This does not have multi-implementer support.

3. HTML element

Introduce a new element when interoperable DOM, behaviors and extended capabilities are desired. An example of this would be the originally proposed element <selectlist>.

Pros

• Avoids needing to go do style calculation and then go back to DOM to result in an interoperable widget
• Allows interoperable DOM, behaviors and expanded capabilities without requiring interoperable styles

Cons

• May result in developer confusion with more than one way to produce a similar widget
• Does not offer progressive enhancement
• This is unlikely to get multi-implementer interest

4. HTML Element or Attribute with interoperable styles by default

This is assuming that an attribute or element is used to produce interoperable DOM and behaviors. Introduce a new appearance value (eg: appearance: ua-<widget>) to allow developers to opt in to user-agent specific styling that is non-interoperable.

Pros

• Avoids having to do anything in CSS to result in interoperable styles by default
• As new elements are introduced the need for setting interoperable styles is not required

Cons

• Introduces inconsistencies in default behavior for HTML widgets

5. HTML markup divergence for adjusted elements that already exist

This one only applies to scenarios where there is already a widget in HTML that will be re-used. To use <select> as an example, when a <datalist> is parsed as a child of a <select> it will result in the interoperable DOM and behaviors.

Pros

• Avoids needing to go do style calculation and then go back to DOM to result in an interoperable widget
• Allows interoperable DOM, behaviors and expanded capabilities without requiring interoperable styles
• Provides progress enhancement

Cons

• May result in developer confusion since they’ll need to know the specific elements to add in order to trigger the interoperable experience
• The prior bullet is compounded by the potential of Javascript manipulation of the element which the component author may not have prepared for

Proposed Resolutions

Interoperable DOM, Behaviors and Styles

1. Proposed Resolution: Introduction of a CSS property that changes the DOM, behaviors and styles to be made interoperable
2. Proposed Resolution: Introduction of new elements that have interoperable DOM, behaviors and styles by default. A new solution to be introduced to allow developers to opt-in to user-agent specific styles.
3. Proposed Resolution: Introduction of a new attribute that changes DOM, behaviors and styles with user-agent stylesheet referencing attribute (eg: select[base] { /* interoperable styles */})

Interoperable DOM & Behaviors

Note: Either of these resolutions also requires an interoperable style solution

1. Proposed Resolution: Introduction of a HTML attribute that results in interoperable DOM and behaviors
2. Proposed Resolution: Introduction of new elements or parser modifications of current semantic elements that result in interoperable DOM and behaviors

Interoperable styles

1. Proposed Resolution: Introduce appearance: base- to result in interoperable styles

Related Discussions

1. [appearance: user-agent] Opt-in to the current OSes control variant #689
2. [css-ui] appearance: base to enable interoperable styling of controls/components #5998
3. Stylable element #9799 stylable select: What should we do about the multiple and size attributes? #977

[mfreed7]

Is the plan to take a live vote this Thursday?

[gregwhitworth]

@mfreed7 yes, the reason for this is that they're not ALL mutually exclusive (at least I don't view them that way) and so we may resolve on Thursday for select and our initial stance but I am curious about some of the arguments made that oppose certain solutions outside of the context of select or similar scenario.

[brechtDR]

I would like to comment on this with an initial thought when hearing about the changes last time. I'm not a native speaker and it sometimes gets hard when doing a call at 8pm to find the right words. I thought I'd document it here first.

One thing I loved about the previous proposal was the idea to style the "listbox", "marker" and "button" using a pseudo element in CSS.

Reason: As a developer we sometimes need to work with third parties - for example - payment providers. It is common that when working with such external tools, we only get to add some CSS and cannot touch the HTML. Just saying that pure CSS styling with pseudos is a feature that will be missed and could've been loved by many.

About the progressive enhancement. I am wondering if there is no chance to polyfill the old selectlist idea at all for older browsers (that's a question).

I do believe an "opt-out" option for selectlist is more interesting than an "opt-in" option for a select.

However, if going for an opt-in solution, I would like people to consider using an attribute rather than changing behavior based on children of the select element. An attribute would still give the ability to style certain elements such as button / marker / listbox with purely CSS. This would also be consistent with how the current switch implementation on Safari is. That consistency would be a nice bonus.

Going for a stylable select instead of a new element is of course probably an easier way to go about accessibility as all screen readers and browsers know it. I just wonder if the "easy solution" would still be the good solution ten years from now. There is always an overlap of support, but that changes over time.

So for me:
Still in love with the new element idea, if not, would love an attribute.
And in general, I believe datalist could use some stylable improvements. Just not sure if this is the place for it or the thing that should trigger that

I do want to note that I am looking at this with a "web front-end developer who specializes in layout" layout goggles and am only thinking about that kind of developer experience.

[mfreed7]

Reason: As a developer we sometimes need to work with third parties - for example - payment providers. It is common that when working with such external tools, we only get to add some CSS and cannot touch the HTML. Just saying that pure CSS styling with pseudos is a feature that will be missed and could've been loved by many.

select>datalist {
  /* put your datalist (popover) styles here */
}
select>button {
  /* put your select button styles here */
}

I'm unclear why we need pseudo elements to achieve "CSS only" styling of all the parts...?

If you mean that you need to touch the HTML to change <select> to <select><datalist>, then you'd also have to touch the HTML to change <select> to <select newthing>. Both are ~10 characters that need to be added to HTML, to opt your "old-style" select into the new "stylable" select shadow DOM structure. So perhaps you're arguing for option #1 above, where a CSS property opts you in to both styling and DOM structure?

[brechtDR]

So perhaps you're arguing for option #1 above, where a CSS property opts you in to both styling and DOM structure?

Perhaps I am. It just felt so powerful and futuristic to do with pseudo elements. It also felt like a good way for authors that wanted to play it safe when it comes to accessibility. As authors could just use css, not worry about doing wrong things with the DOM, have the select(list) do all the right things and your only a11y worry would be things such as contrast. And for those that wanted to take it a step further, there were the new elements to take customisation to a deeper level. But as I stated before, I look at this with certain goggles. I also feel that some of the proposals are hard to explain (tutor) to people: "Adding a datalist to the select to make new things happen" is hard ... That in itsef is not a viable argument, I am aware of that. Just sharing this thought / opinion. I know the idea of me liking what we had is not the popular route anymore. 🙂

[mfreed7]

Perhaps I am. It just felt so powerful and futuristic to do with pseudo elements. But as I stated before, I look at this with certain goggles. I also feel that some of the proposals are hard to explain (tutor) to people: "Adding a datalist to the select to make new things happen" is hard ... That in itsef is not a viable argument, I am aware of that. Just sharing this thought / opinion.

Totally fair! Just to be clear, I wasn't trying to minimize your point, just understand it.

[gregwhitworth]

That in itsef is not a viable argument, I am aware of that. Just sharing this thought / opinion. I know the idea of me liking what we had is not the popular route anymore. 🙂

@brechtDR This is a viable argument; just because there are many things about the web are confusing to teach to devs doesn't mean we should continue to introduce new ones.

That said, I will purposefully keep my position scoped to <select> and select the following, only if what @josepharhar mentioned is possible in that the shadow DOM could be interoperable without having to do style calculation:

Proposed Resolution: Introduction of a CSS property that changes the DOM, behaviors and styles to be made interoperable

If it does require require going back to DOM construction then I prefer the attribute approach with user-agent styles referencing this attribute to set interoperable styles (eg: no introduction of a base-<widget> solution). So option 3:

Proposed Resolution: Introduction of a new attribute that changes DOM, behaviors and styles with user-agent stylesheet referencing attribute (eg: select[base] { /* interoperable styles */})

I am personally only a fan of any solution that changes DOM, Styles and behaviors at once (eg: I don't want a mix & match potential although I know some may want that).

[brechtDR]

@gregwhitworth I do have one question that is not completely answered in the document I think. Will we be able to add other elements inside of a styleable select (more especially in the datalist)? It can be handy to have an extra wrapper <div> for layout reasons to create a truly styleable select... I refer to a previous example I created: https://codepen.io/utilitybend/pen/PoXOzzw

[josepharhar]

Will we be able to add other elements inside of a styleable select (more especially in the datalist)?

Yes

As a developer we sometimes need to work with third parties - for example - payment providers. It is common that when working with such external tools, we only get to add some CSS and cannot touch the HTML

I'm unclear why we need pseudo elements to achieve "CSS only" styling of all the parts...?

Selectlist had pseudo elements and the new stylable select proposal doesn't have pseudo elements, but as mason showed in his example you can just target the button and datalist elements directly without the need for pseudo elements.

With selectlist, the opt in to the new behavior was to change the tag name from select to selectlist. With stylable select, the opt in is to add button and datalist elements. If the HTML of the website opts in, either with the old selectlist proposal with pseudo elements, or the new stylable select proposal, then you are guaranteed to be able to style the button and listbox with either proposal.

[flackr]

It's also possible to combine solutions 2 and 3, in a very analogous way to <input type=button value="click me"> and <button>click me</button>.

The attribute allows you to create a <select type=list> that supports progressive enhancment (note, I'm using type, to further draw the analogy to input, but of course the attribute doesn't have to be type), or if you have an alternative fallback or in the future where every browser supports it, you can use <selectlist> or some other new element which is only ever the new thing.

This can of course be done anytime after adding the attribute.

[lukewarlow]

To clarify if we add an attribute to select would that also require changes to the children. One of the niceties with using select is to get the fallback in older browsers. E.g older browsers use root options whereas the new stuff is taken from inside a datalist. I would want this behaviour to continue even if an attribute was also needed?

I do think an attribute is generally the "correct" solution if we choose a html change because void elements can't have children.

I agree with Greg (provided I've understood correctly) that the new Dom structure and new styles should be one in the same.

Though one example that contradicts that is the new switch input Apple has implemented, where it can follow accessibility requirements for showing symbols. I think it's important that these kind of affordances are accounted for.

[brechtDR]

I think most of my "worries" are gone now. I do like the idea by @flackr as well. It still feels strange to me putting a datalist in there instead of a more declarative name in a new element such as "listbox". But that's rather a feeling than something that is objective.

[css-meeting-bot]

The Open UI Community Group just discussed [select] How to enable interoperable DOM, behaviors and user-agent styles for <select>, and agreed to the following:

• RESOLVED: trigger for dom structure and behavior should be independent from the trigger for interoperable styles
• RESOLVED: the opt-in for interoperable styling should be a new value for the `appearance` property, such as `base-select` or maybe `base`.
• RESOLVED: Use a new attribute (name TBD) to opts that <select> into the new behaviors and DOM structure

The full IRC log of that discussion

<dbaron> s/Regrets: hdv//
<jarhar> gregwhitworth: this is scoped to select as we noted two weeks ago
<jarhar> gregwhitworth: two weeks ago, we discussed that theres a bunch of potential pivots we could take to produce an interoperable select
<jarhar> gregwhitworth: i tried to outline some approaches
<jarhar> gregwhitworth: technically we can mix and match them
<jarhar> gregwhitworth: we can take a solution of producing interoperable dom behaviors and styles based on some mechanism
<jarhar> gregwhitworth: we can introduce interoperable dom and behaviors on some mechnism, and then we can have interoperable styles based on some mechanism
<jarhar> gregwhitworth: in order to achieve a majority of the demos. in order to fully interop you would need multiple solutions
<jarhar> gregwhitworth: we have css appearance base
<jarhar> gregwhitworth: it does have a good developer experience
<jarhar> gregwhitworth: as una pointed out, it does make you feel like youre only changing styles even though youre changing dom and behaviors
<jarhar> gregwhitworth: anne prefers this path
<masonf> q+
<jarhar> gregwhitworth: the cons of this approach is what i just stated: its doing more than just changing styles
<jarhar> gregwhitworth: there is a premise in my mind, that maybe that isnt the case, thats why the csswg said we dont want it to be a css property, is that we would get to style computation and we would have to go back and do dom restructuring based on that style recalc
<jarhar> gregwhitworth: joey had raised that theoretically it could be possible to not make that happen
<jarhar> gregwhitworth: the other one is html attribute. you would have some type of attribute, like type or base
<jarhar> gregwhitworth: pros of this is that you can adjust the dom for sure at dom creation time
<jarhar> gregwhitworth: if you are writing raw html and js you have to apply that to every element instead of the style one
<jarhar> gregwhitworth: that one also doesnt really have multi implementor support, so pretty large con
<jarhar> gregwhitworth: html element, this is where we started
<jarhar> gregwhitworth: this would be a new element that we introduce
<jarhar> gregwhitworth: comes with all the key pros as the attribute
<jarhar> gregwhitworth: con is that it can result in developer confusion since they have to pick one
<jarhar> gregwhitworth: keeping this scoped to select, this is unlikely to get support and doesnt have progressive enhancement
<jarhar> gregwhitworth: 4 is assuming an element or attribute exists, and then we have interoperable styles
<jarhar> gregwhitworth: the 5th one where were at today is when we get to a certain child we biforcate and go to interoperable dom, we then pivot to the interoperable dom structure
<jarhar> gregwhitworth: we dont necessarily go to the interoperable styles
<jarhar> gregwhitworth: i have proposed resolutions for all of those which i have already written
<jarhar> gregwhitworth: we are keeping this scoped to select, we can talk about other elements and things as we come to them
<jarhar> gregwhitworth: within this hour i want to get to a resolution with select
<jarhar> gregwhitworth: ultimately we need to take this to whatwg and csswg and say here is openui's proposal
<scotto_> q+
<gregwhitworth> ack masonf
<jarhar> masonf: i am in support of option 5
<jarhar> masonf: the fact is that we have two different things we are talking about. one is the dom structure and behaviors: can you put multiple buttons in this thing? does it use popover? and the corresponding shadowroot structure
<jarhar> masonf: and the other question is how is this thing styled? is it based on the browser or is it interoperable
<jarhar> masonf: i think 5 allows you to opt in or out of those things as you see fit
<jarhar> masonf: number 1 is a single opt in for both things, appearance base which opts you in to new structure and new styles. listed as having apple support but they have been clear that they are only ok with proprietary styling by default. since this one does that by default you cant have ua styling and new behavior, its all or nothing. i think that number 5
<jarhar> masonf: is the only one which has apple support
<bkardell_> q+
<jarhar> masonf: number 3 is unlikely to get support because the requirement is that we have proprietary styling by default
<jarhar> gregwhitworth: number 1 doesnt work because we need to mix and match?
<jarhar> gregwhitworth: so theres a 1a which is remove the dom changes and we now have one solution
<jarhar> gregwhitworth: i hinted at the other ones that there needs to be a css approach if you just take the attribute then you need a styling approach
<jarhar> gregwhitworth: i can modify it and rearticulate the numbers
<jarhar> scotto_: that was my understanding of this too. when i was reading through the apple support, we support allowing people to restyle the select element, but a lot of what we are talking about is modifying the select element to be more than it currently is
<jarhar> scotto_: those things - i never interpreted that as being supported
<jarhar> scotto_: some of the things we want to do with selectlist are new semantics that dont neatly map with select
<gregwhitworth> ack scotto_
<gregwhitworth> ack dbaron
<gregwhitworth> q+
<jarhar> dbaron: i felt nervous about the idea of css that goes back and influences the dom, and while you were talking about it i realized why i feel nervous about it
<jarhar> dbaron: xb1 as implmemented in mozilla did something similar
<jarhar> dbaron: attached via a css property called -moz-binding and that messed with the dom
<jarhar> dbaron: caused performance and other issues, they are happy to have gotten rid of it and would not be happy about reintroducing
<jarhar> dbaron: i suspect emilio would share that opinion
<jarhar> dbaron: xbl did this and it was viewed as a design mistake
<jarhar> gregwhitworth: yeah that was why the csswg said no
<jarhar> sasha: css is used after html, why does that not conern you?
<jarhar> gregwhitworth: performance implications would be drastic, there would be other form controls that follow this
<jarhar> dbaron: the other thing about :before and :after are that they look like dom but they dont require going back in the system like these other things would
<gregwhitworth> ack bkardell_
<jarhar> bkardell_: we got similar feedback with my affordances idea. it would switch the dom nodes projected into
<dbaron> s/xb1/XBL1/
<jarhar> bkardell_: there were concerns that it would change the semantics
<jarhar> bkardell_: its worth debating and figuring out,
<jarhar> bkardell_: its not far from what we want to do in a lot of cases
<jarhar> bkardell_: bringing it up here because maybe it is worth acknowledging the complexity because we are setting a precedent
<jarhar> bkardell_: its worth thinking if theres a way we can make that work
<jarhar> bkardell_: its more elegant if we could figure out a way to do that
<jarhar> q?
<jarhar> gregwhitworth: going back to what mason brought up, im going to be pedantic
<jarhar> gregwhitworth: can we resolve first before we decide on solutions that dom structure and behaviors should be independently triggered from interoperable styles which is what mason was bringing up earlier
<jarhar> gregwhitworth: zooming out a little bit of this problem
<masonf> +1 to that resolution
<jarhar> gregwhitworth: do we want to change them individually
<jarhar> gregwhitworth: brian what you said is that you would prefer that to not be the case?
<jarhar> gregwhitworth: that you would prefer one toggle?
<jarhar> bkardell_: yeah i dont know
<luke> I -1 having them separate personally
<jarhar> bkardell_: whether its one or not isnt really necessarily the question for me. i could be ok with that i think
<jarhar> luke: i object to having them separate
<brecht_dr> i agree to that... one opt in
<jarhar> gregwhitworth: so you would prefer one thing that gets you interoperable everything
<jarhar> masonf: could you clarify why?
<scotto_> q+
<jarhar> luke: i think most people are going to want something that just works, and having to do two separate things and account for a third thing where youre opted in to new dom but not styles and vice versa could get messy
<gregwhitworth> ack gregwhitworth
<gregwhitworth> q+
<jarhar> luke: if youre writing a component that other people use where you dont have control over everything, and you have to somewhat deal with it
<jarhar> luke: to me it feels like if we have a new attribute to get a new dom structure then you should get the styles anyway
<jarhar> luke: people dont want ua styles, they just want to style the thing
<jarhar> masonf: you put the attribute in, but then you want to ... if you put a button in then you also have to add the attribute
<jarhar> luke: my preference is that you dont need the attribute and its just based on the content, but yeah
<una> +1
<jarhar> masonf: so youre pushing for option 5, the contents of the select opt you in, but you dont want the css property to opt you in
<gregwhitworth> ack scotto_
<una> q+
<jarhar> scotto_: i might be repeating luke, but the option is ... if i could just put new html in, then it should just style automatically
<jarhar> scotto_: but is the alternative that you put an attribute on the select element and then i could add just images to my option in select? do i have to add a button and a datalist too? if you want to style this you have to put a button and a datalist inside the select?
<luke> q+
<jarhar> masonf: so youre talking about option 2, and i think the proposal in that case is that you dont require the other elements. you could have a select with that attribute and a bunch of options and then it just works
<jarhar> luke: the one thing i want to point out is that breaks the premise that select gives us is progressive enhancement. for old browsers they use options in the root of the select, new ones use the one in the datalist
<jarhar> masonf: thats not correct - in old browsers, today, if you put another element inside of a select like a datalist and options inside of it, the parser will throw away the datalist and youll be left with a select with the options in it
<jarhar> gregwhitworth: and the attribute would work the same way?
<jarhar> gregwhitworth: the end result is the same if you use an attribute?
<jarhar> masonf: yes, because theres no datalist to remove
<jarhar> gregwhitworth: even if you add a datalist, you get the new parsing behavior
<jarhar> luke: i had a fundamental misunderstanding
<jarhar> gregwhitworth: you can throw images in your options today but they just get thrown away
<jarhar> gregwhitworth: however you opt in to that new dom structure, you get that parsing that throws away anything complex
<jarhar> gregwhitworth: i will state that i think its more important for us to get this out there than my passion about the simplicity
<una> q-
<jarhar> gregwhitworth: my qualm with keeping them separate is that the image scenario is that its probably ok. if i just want to change borders, then its probably alright
<jarhar> gregwhitworth: the second that i get more complex, the way you style those dom parts but we havent standardized styles drastically impacts how my stuff lays out.
<jarhar> gregwhitworth: if you use flex then you need to opt in to those styles
<jarhar> gregwhitworth: theres a strong statement of i want to be able to have more control over this select
<jarhar> gregwhitworth: i am not so passionate about - because i just envision a good 90% of devs either using their own or using a design system, this will be abstracted away from them
<jarhar> gregwhitworth: while i would prefer all of them being adjusted using some system, i am ok with this because theres more implementor support
<gregwhitworth> ack gregwhitworth
<jarhar> gregwhitworth: i am +1ing the they are separate - one for dom and behavior, and another for css that will opt you in to interoperable styles
<gregwhitworth> ack luke
<una> +1ing keep them seperate
<flackr> +1 keeping them separate
<masonf> Proposed resolution: dom structure and behaviors should be independently triggered from interoperable styles
<dbaron> maybe rephrase as: trigger for dom structure and behavior should be independent from the trigger for interoperable styles
<jarhar> gregwhitworth: is there anyone opposed to this?
<jarhar> gregwhitworth: we could do a poll
<masonf> Proposed resolution: trigger for dom structure and behavior should be independent from the trigger for interoperable styles
<masonf> RESOLVED: trigger for dom structure and behavior should be independent from the trigger for interoperable styles
<jarhar> gregwhitworth: ok, now lets start with dom and behaviors
<jarhar> gregwhitworth: css we can probably resolve rather quickly
<jarhar> gregwhitworth: dom and behaviors where we have new element, new attribute, or content within this progressively enhanced element
<jarhar> masonf: this is contentious and will take time, should we just stop with this?
<jarhar> gregwhitworth: sure im fine with that
<luke> q+
<masonf> Proposed resolution: the opt-in for interoperable styles is `appearance: base-select`.
<jarhar> gregwhitworth: the only proposal for css is appearance with base-widget
<flackr> q+
<jarhar> masonf: the reason not just appearance:base is that theres a forwards compatability issue. people could start using *appearance:base and then other things will start breaking
<jarhar> masonf: appearance-base opts you in to the one control that is supported
<gregwhitworth> ack luke
<jarhar> luke: two things: i noticed there was an example with appearance base radio
<jarhar> luke: is that css syntax where you can do a comma separated list or something else
<jarhar> luke: i dont remember appearance accepting multiple values
<bkardell_> I think it is just two examples, this one or that one
<jarhar> luke: so you would just do * appearance:select but that wouldnt opt everything in
<gregwhitworth> * { appearance: base-select, base-radio }
<jarhar> masonf: seems reasonable to only have one value there
<jarhar> luke: without being able to do that you cant do that in one rule
<jarhar> luke: which makes it a bit harder
<gregwhitworth> ack flackr
<jarhar> flackr: if we wanted to try avoiding the compat risk of appearance:base, we could make appearance:base be effectively appearance:none which dont have a base appearance yet, which would make it clearly an error when you apply it to elements which dont support it and then we can upgrade it in the future
<brecht_dr> q+
<jarhar> masonf: weve had other discussions about selectlist, and it does seem less risky and it does not eliminate the risk
<jarhar> masonf: if applying css makes it display:none, they may start relying on that and then when it pops up it breaks them
<bkardell_> +1 I was going to queue to say what masonf just said
<jarhar> flackr: i do like the idea of having a single value, so if that was acceptable i thought it would be worth considering
<jarhar> q+
<bkardell_> I also "like" the idea of a single value, but in practice I don't think it's possible
<gregwhitworth> ack brecht_dr
<jarhar> brecht_dr: wouldnt that mean that you would get a lot of different values into one property as time goes by if you do something like that? seems like an awful experience
<jarhar> masonf: there would be an additional - the path laid out by csswg is that you would eventually get a shorthand value base
<luke> select { appearance: base-select; } input[type="radio"] { appearance: base-radio; }
<jarhar> masonf: the point of base-select is to avoid people using *
<gregwhitworth> select { appearance: base-select } radio { appearance: base-radio}
<gregwhitworth> ack jarhar
<gregwhitworth> jarhar: what if we used appearance: none
<jarhar> gregwhitworth: elika had reasons against appearance:none
<jarhar> gregwhitworth: it was 3 years so i dont recall
<jarhar> luke: for one thing, appearnace:none already exists and does something, so if you want to do something different its going to break
<jarhar> gregwhitworth: she had noted that what base was trying to do was not 1:1 with the definition of none
<jarhar> masonf: there was pushback that none means none, you can argue thats not currently happening, but its supposed to be different
<jarhar> gregwhitworth: theres compromises all of us are making
<jarhar> gregwhitworth: and we acknowledge that
<masonf> proposed resolution: the opt-in for interoperable styling should be a new value for the `appearance` property, such as `base-select` or maybe `base`.
<una> reset.css
<jarhar> gregwhitworth: i envision there being a forms reset stylesheet that everyone puts in their head
<luke> +1
<una> 👍
<brecht_dr> +1
<flackr> +1
<masonf> RESOLVED: the opt-in for interoperable styling should be a new value for the `appearance` property, such as `base-select` or maybe `base`.
<jarhar> gregwhitworth: there has been buy-off on key editors to reusing the select element, so i am going to kick out the new element
<bkardell_> q+
<jarhar> gregwhitworth: does anyone disagree with me kicking out selectlist?
<gregwhitworth> ack bkardell_
<jarhar> gregwhitworth: so there are two options, attribute or content
<jarhar> bkardell_: is there any precedent for this? parsing differently based on an attribute
<jarhar> masonf: attribute definitely, declarative shadowdom
<jarhar> masonf: outside of the element, im not sure
<jarhar> masonf: you could argue that the current select behavior does depend - if you use an image
<jarhar> gregwhitworth: mason you have put forward that what you want is option 5, the content
<flackr> q+
<jarhar> gregwhitworth: can we throw that forward? if you feel strongly about an attribute, please step forward and object
<gregwhitworth> ack flackr
<luke> q+
<jarhar> flackr: i dont want to object, but i do feel strongly that the attribute is more analogous to say the input type=button scenario, and feels less magical than parsing behavior changing based on the presence of certain tags
<jarhar> flackr: in the future we could make is to that you use the new element and then we forget about the attribute altogether because everybody supports the new element
<masonf> q+
<brecht_dr> q+
<jarhar> gregwhitworth: we can always revisit the ui toolkit that comes out the box more ergonomic, where we deprecate select and selectlist becomes the new thing, and we can always improve the dx over time
<gregwhitworth> ack luke
<jarhar> luke: based on my newfound understanding, i want to +1 the attribute
<jarhar> luke: if thats the thing that we already have precedent for doing parsing-wise, also its probably faster
<jarhar> q+
<gregwhitworth> q+
<jarhar> luke: other bit is that most other elements that we want to style wont have children
<jarhar> luke: that we want to change the layout for
<jarhar> luke: wont be able to have children
<jarhar> luke: i suspect that while some form controls will only need new styles and structure will be ok
<jarhar> luke: i suspect that there will be some that we want to change
<jarhar> luke: or they will have to use an attribute because they dont have children because theyre void elements
<jarhar> luke: so if we do that with select that would be good as well
<gregwhitworth> ack masonf
<jarhar> luke: we have has() now, but you could give select interop styles by checking the attribute in css
<jarhar> masonf: i came out strongly last time for the content model, im happy that we resolved on an opt in
<jarhar> masonf: i definitely see the point that luke just made
<jarhar> masonf: there was a question about imperative structure of dom - you cant add the attribute after the fact, and there may be questions about ordering of things. just want to make sure we talked about it
<jarhar> luke: i think that is an issue with image lazy loading
<jarhar> luke: that is a good point
<jarhar> masonf: if you did that, then you would reconstruct the dom when you add the attribute
<jarhar> masonf: much more tractable thing than doing it in css
<jarhar> masonf: very implementable
<gregwhitworth> ack brecht_dr
<jarhar> brecht_dr: i wanted to agree
<jarhar> brecht_dr: reason one is consistency, but also what i like about that is the simplicitly and how you can explain it to people
<jarhar> brecht_dr: heres an attribute and you can do a bunch of things
<jarhar> brecht_dr: if you add an attribute in there then you can have images
<jarhar> brecht_dr: thats kind of where i stand on that
<gregwhitworth> ack jarhar
<gregwhitworth> jarhar: I'm in favor of having the button and datalist approach because it makes the implementation simpler
<luke> q+
<gregwhitworth> jarhar: also, there is something that luke said there is precedant based on attributes. There is more precedant for tags changing then attributes
<gregwhitworth> jarhar: we have declarative shadow DOM but more about elements for tables, select or other things
<gregwhitworth> jarhar: there is this concept where the selectlist default button and if you didn't provide one you get this default button. We have psuedo elements and the marker itself, etc
<gregwhitworth> jarhar: I tried messing around with it and it removed the need for it
<gregwhitworth> jarhar: there are then pseudos for the listbox or button and in trying to implement it I had to work with the style
<flackr> q+
<gregwhitworth> jarhar: with the new elements they have to be in the DOM and thus you can just style it
<gregwhitworth> jarhar: I'm also curious on the opinion of WHATWG
<jarhar> flackr: i have a point on that which may be relevant - we could make the contruction behavior similar to tables - the browser could make
<gregwhitworth> flackr: I was suggesting, if the concern is not knowing whether you have these elements we could make it so that the attribute implictly creates the parts and those are still targetable
<gregwhitworth> masonf: that's foster parenting and it's not fun
<dbaron> i/jarhar: I'm in favor of/ScribeNick: gregwhitworth
<gregwhitworth> masonf: there are XSS issues, etc
<gregwhitworth> luke: it causes hydration mishaps
<dbaron> ScribeNick: jarhar
<gregwhitworth> q?
<flackr> q-
<dbaron> i/flackr: i have a point/ScribeNick: jarhar
<jarhar> gregwhitworth: for select, im again not super passionate here
<dbaron> i/flackr: I was suggesting/ScribeNick: gregwhitworth
<jarhar> gregwhitworth: going back to brects point, do i need to remember this for every element in order to get interoperable dom structures and behaviors
<jarhar> gregwhitworth: i am ok with resolving on 5, but i am concerned that ...
<jarhar> gregwhitworth: when you have an input color, you have to remember all 40 elements you need to add to make the color input interoperable
<jarhar> gregwhitworth: thats the only thing i want to raise, i just really do not want to remember a year from now, nope devs now know
<masonf> q+
<jarhar> gregwhitworth: since were scoping to select, i do not have a passionate problem with resolving on 5
<gregwhitworth> ack gregwhitworth
<jarhar> luke: i earlier said that you ... the problem with that is that it doesnt take into account feature detection
<jarhar> luke: whereas, if you did it using has(), the old parser would throw it away, it wouldnt match because datalist would get thrown away
<gregwhitworth> ack luke
<gregwhitworth> ack masonf
<dbaron> s/has()/:has()/
<jarhar> masonf: this is nuanced. thats a good point, but if you built your select imperatively, it would contain those elements so it would match
<jarhar> masonf: there is a css thing to match a pseudo class that only matches when youre in the new mode
<jarhar> masonf: i wanted to throw out one more thing
<jarhar> masonf: using the current proposal 5 allows more flexibility
<jarhar> masonf: if you put just a button and not a datalist, you can get a stylable button gives you the old style pop out of the window that doesnt suport content but at least it pops out
<brecht_dr> q+
<jarhar> masonf: or vice versa, you can mix and match
<gregwhitworth> ack brecht_dr
<jarhar> masonf: thats a feature that fell out, not sure how valuable it is, kind of leaning towards the attribute
<jarhar> brecht_dr: you can already do that with the select, you can style it and get the original listbox, that part is already taken care of
<masonf> Proposed resolution 1: Adding a <button> or a <datalist> to a <select> (declaratively or imperatively) opts that <select> into the new behaviors and DOM structure.
<masonf> Proposed resolution 2: Use a new attribute (name TBD) to opts that <select> into the new behaviors and DOM structure.
<masonf> 2
<flackr> 2
<jarhar> 1
<brecht_dr> 2
<luke> 2
<gregwhitworth> 2
<keithamus> 2
<dbaron> abstain
<masonf> sasha: 1
<gregwhitworth> jarhar: if we go with 2, that's great but my spidey senses there will be pushback
<gregwhitworth> jarhar: I want to have a concrete list of reasons to why the attribute reasons as to why
<masonf> RESOLVED: Use a new attribute (name TBD) to opts that <select> into the new behaviors and DOM structure
<dbaron> s/pushback/pushback from whatwg/
<dandclark> I personally like 2 but my main priority is seeing this shipped; would be OK with 1 if we can't get 2 through.
<dbaron> i/jarhar: if we go with 2/ScribeNick: gregwhitworth
<dbaron> ScribeNick: jarhar
<dbaron> ScribeNick: dbaron
<dbaron> gregwhitworth: I'd like to understand reasoning in the other direction as well, so we can understand why others are objecting to the things that we're proposing.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.