# Pastebin 1oL6QOWj
	• Greg: specific area where Open UI and CSS WG overlap is pseudo elements. Concrete example, select control, which is the furthest along…
	• Greg: parsing out what gets accessed as a pseudo-element, what is a new element
	• Greg: as we land these parts, should we come to CSS WG as, we recommend this part as a pseudo element? Inversely, when new pseudo els come into CSS WG, should we have a part described in Open UI?
	• Florian: regarding pseudos, a little uncertain how it will unfold. Have appearance prop, when you appearance none things, it removes UA styling, falls back to pure CSS styling. Way it's specced is different from legacy. Legacy version, millions of values. Specced version, auto and none. How this relates is that if you do appearance: none that might have subcomponents, slots, or pseudos, the appearance: none applies to the whole thing. Part of the reasoning is pseudo els might non-standard. appearance: none on element itself CSS-ifies everything in the component. If we define pseudo els, we might want to keep that behavior or we might not. This feels like it should be revisited.
	• Greg: Open UI: we don't intend to standardize default appearance, we do intend an author to reset. That's a good example of what I'd expect to bring this to a collaboration [between Open UI + CSS]. 
	• Greg: currently in proposal for select, there's an open state. Assumption from research across all selects. Majority are hidden by default and then are shown. Should appearance: none still have default expectations that the listbox by default is a display: none. That's where I'm trying to figure out where CSS wants to fit into Open UI in those questions. Base stylesheet for select?
	• Florian: that's an open issue, visual style might be different but should be recognizable and operable as what it's supposed to be. What that style is, is an open question.
	• Greg: because that gets into appearance: none, that should live in CSS. "We don't define styles in Open UI" might still be true