Matthew: Still looking into that...

Matthew: some questions after reading the explainer... one that caught my attention - there are interactive elements allowed inside the list box - really want to dive into that in more detail. [Need to do more work.]

Peter: punt to brekout C?

Matthew: one naming issue... if you want to make a custom style-able select box widget you use base-select - which sounds like the default one to me. Is there a precedent?

Jeffrey: the default is AUTO which feels right. NONE means no appearance. BASE seems reasonable. They are worried that people styling it by accident with * so it's this way so they opt into one element in a time

Tess: this is a route to get to...

Peter: base to me didn't imply this is the style-able version.

Tess: appearance none should be called appearance cliff...? The name base is coming from "this is a base you can build on".

Peter: makes sense when you think about it. A lot of people spent a lot of time thinking about this so don't want to jump in. But it seems weird, but there are probably reasons for the weirdness.

Tess: select is unique in that it's really really weird. More weird than other form controls. There are three pieces of it. The normal select is a drop down, a control in the page you activate, and there's the thingie that shows up that you can pick stuff in. This concept of a picker. There are other controls that when you activate it something comes up - the picker. Select is unique in you can style it in a way that instead of having an element on the page that casues the thing to come up, it inlines the thing that would have come up. Eg. for multiple selection, a list box in the page.

Peter: that's done by attribute not by style

Tess: you want to be able to apply styles to the thing that pops up that are the same as the thing embedded in the page. It gets messy. It's great they're tackling select first because it's the most complex one and they have to work through all of that. The subsequent ones will be easier. But initially seems weird.

Peter: layering violation? appilcation of the css here changes the html parser algorithm

jeffrey: I talked to them about that. I thought that was a request from the aria folks, but the answer was they do it by adjusting the display .. they generate all three possible html structures and then the css says display:none on two of them. Which is gross.

Peter: I wonder if.. because when we start styling older controls we have to do something strange for compat reasons, would we be better off by making a new element that is a stylable select

Tess: OpenUI people started with a new element. That wasn't very palatable to a bunch of other constituents. The eventual consensus after a lot of head bashing on that is to try to augment the existing select element as much as possible. A strong reluctance to introduce redundancy in html elements. Generally a mistake in the past. Sometimes understandable, eg. input and button. Bemoans lack of time machine.

Peter: should that be revisted? Don't want to throw a wrench in, but curious..

Tess: they've already gone in these circles. On balance, consesnus was to augment the existing element. There are still people who would prefer the new element approach.

Peter: I've seen this happen in other technologies.. a decision like that, you settle on rough consensus, then you go down that path and you find out more information, maybe then worth revising original decision.

Tess: that's exactly what happened

Peter: I wonder if the parser change was fully considered when they made that decision, and should go back. But also understand the desire not to do that.

Tess: I don't think there is significant new information that would cause them to revisit.

Jeffrey: they knew they would have to adjust the structure based on the css attribute.