Meeting minutes
Open UI / CSS meeting
https://www.irccloud.com/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
Florian: 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
fantasai: one of the concerns I have, reason we haven't introduced tons of pseudo els, if you start introducing ability to support styling of complex form control, offering author assumptions about how the control is structured. And once you make those assumptions, you lock in that structure for implementation
fantasai: if you're in charge of structure, you can change that in conjunction with the styling. Author might start making assumptions how native calendar control is structured...styling of those pieces may not work in the way author envisioned originally when applied to a calendar control that is differently structured on a different device. That's my concern on exposing too many parts of native controls
fantasai: vs author implementing own control
fantasai: we should make it possible to style native form control, but I don't think standardizing on parts and part names is not necessarily way to do it for such controls
heycam: related concerns, without defining styling of customizable controls, authors will make assumptions for a particular browser...also want mandated UA stylesheet...make them work w/o additional styling, dependable base for authors to rely on and customize on top of instead of rewriting shared styles
<fantasai> gregwhitworth: 'appearance: none' would fall back to base styles that are agreed on
<fantasai> fantasai: Might not necessarily be true across devices
<fantasai> heycam: Might not look like native form controls, but
fantasai: example of maybe form control that's time is text input, vs on a different device is an analog pop-up or osmething. Styling for one will not translate to the other
gregwhitworth: Time control, could be laid out in any number of ways, don't want to restrict that
gregwhitworth: e.g. MSFT often comes up with new form factors
gregwhitworth: behaviors and controller code often follwos MVC model
gregwhitworth: select takes options, zero to N, doesn't change the layout
gregwhitworth: let's ratify that model
gregwhitworth: but also say, on desktop they're all different
gregwhitworth: the models are still identical
gregwhitworth: layouts and styling vary
gregwhitworth: Apple watch: model has not changed, but behaviors are still the same
gregwhitworth: keyboard still wired up, but not going to work unless bluetooth keyboard attached
gregwhitworth: One beign input that looks like text, vs other being radio
gregwhitworth: showing slots
gregwhitworth: Potential changes, ::part has more meaning based on thismodel not just styling
gregwhitworth: parts have meaning
gregwhitworth: can slot in whatever you want as an author
gregwhitworth: so time input being a text field
gregwhitworth: click on it pops up
gregwhitworth: someone comes along, input above, want it to be just text
gregwhitworth: when pop-up appears, odn't want it to be just text
gregwhitworth: will apply a part for controller code
gregwhitworth: wanted to show that with this bootstrap example
gregwhitworth: defining the part
gregwhitworth: wired up necessary ARIA stuff
gregwhitworth: completely different layout and appearance, but the model is the same
gregwhitworth: To Cameron's point, we wanted to make it easier for authors to style
gregwhitworth: key aspect of styling, need a base style sheet to start from
gregwhitworth: if we do agree, then we want to modify the form control
gregwhitworth: will be shipped with web components, so rendered with web tech
gregwhitworth: would have access to those pieces with parts
gregwhitworth: but if everyone lays out list box differently
gregwhitworth: one uses flex, one needs grid
gregwhitworth: then need something new
gregwhitworth: to get to base style
gregwhitworth: We're aware of other form factors, didn't want to hinder
gregwhitworth: important aspect of design model
fantasai: Not sure you entirely understood what I was saying, but queue is long, let's come back to it
jensimmons: I think fantasai was trying to articulate some important things to understand
jensimmons: I think we have good agreement on goals, to allow authors be able to style things
jensimmons: Don't want authors to replace form conrols with their own
jensimmons: Also want authors to be able to style things
jensimmons: Also agreed that default styling will not match across browsers
jensimmons: room for differences
jensimmons: thoughts on `appearance: none` as a togge
jensimmons: either get native controls styling, or click into styleability
jensimmons: if we had a time machine, maybe we'd come up with more consistency, but can't
jensimmons: But idea that we would now agree to web components, and all agree to very specific structure, and then have pseudos to style that structure
jensimmons: where 'appearance' would trigger that structure
jensimmons: ...
jensimmons: HTML and CSS vs form controls are very different
jensimmons: Would be nice to style border / background but inherit rest of form contorl
jensimmons: I'm not sure we can do what you're talking about gregwhitworth
jensimmons: I think we need a hybrid of the proposals written up in CSSWG a couple months ago
jensimmons: Less prescriptive
jensimmons: Maybe we really need to look at what things to authors want to style the most
jensimmons: and how can we give them ability to do that
jensimmons: with more generic pseudo-classes
jensimmons: not so presectiptive, don't match exactly an exact web-component based model
jensimmons: give authors what they want and need
jensimmons: we also need to give implementers the flexibility that they need
<heycam> I feel like the appearance (or whatever mechanism toggle) is the thing that allows us to have a standardized control implementation and styling
tantek: Let me see if I can build on what fantasai and jensimmons said, because 100% agree
tantek: I agree it's a bad idea for 'appearance' to be repuprposed for components model
tantek: seems hacky, lots of constraints, would not want to go there
tantek: point that I think fantasai made and jensimmons expanded on
tantek: different browsers and potentialy different OSes, providing different views
tantek: number of parts, structure of parts
tantek: is spot on
tantek: it's possible exact same browser in two different layouts, depending on width of windoe e.g.
tantek: could provide completely different part hierarchies
tantek: intentionally
tantek: I don't think we can make any assumptions about what kind of pseudo elements an author could depend on or not
tantek: and any that we did provide, would give author an artificial sense of control
tantek: that these things are fixed
tantek: they aren't, across impls, platforms, even different views in same impl
tantek: What I think we need is a model where both the browser has the freedom to alter part hierarchy per control
tantek: based on things like dimensions of user's window or other things
tantek: but also for things like a11y
tantek: and where the author somehow has the ability to access what decisions the browsers has made wrt part hierarchy
tantek: and be able to style the different possible expressions of that hierarchy
tantek: consider mobile vs other, differences are complex
tantek: and it's getting more complex
gregwhitworth: I would like to see what differences you're seeing , that Open UI didn't figur eout
tantek: Not saying anatomy is wrong. Your existing research demonstrates this.
tantek: the part hierarchies that you have are way more reflective of spectrum of possibilities
tantek: than people's assumptions about e.g. input[type=file]
tantek: or datepickers
tantek: those are going to be extremely different across different things
tantek: maybe you've already modeled part hierarchy for datetime?
greg: we're trying to tackle most frustrating first
greg: I think maybe we're talking past each other
greg: are we referring to DOM, just parts? name of parts? or referring to layout structure of parts? all of these very different
greg:
greg: all of these are not defined by Open UI
tantek: I'm referring to both
greg: ???
tantek: layout is one, vs DOM is another
greg: and then there's the part, which doesn't require ither
jensimmons: some of us might be meaning the componetns, the code, how the form controls is made
fantasai: I think making assumptions about either layout or DOM structure, relationship of parts to each other, is going to be problematic
<tantek> fantasai: making assumptions about the dom, structure, or parts may be bad because those things are likely to change
fantasai: because those can change
fantasai: Open UI did a lot of great research on what the abstract parts and relationships
fantasai: so that could implement a control that maps those parts, and browser could map in the behavior / events / a11y etc. and could have any layout or dom structure you ant
greg: ...
greg: could implement without web compent tech
greg: ppl don't build the web component the same way. Model and parts are the same, but dom structure and layout are different
fantasai: browsers will have similarly wide differences, and so exposing parts for styling will not work
fantasai: I think it makes sense for us to tackle this problem from two different directions
fantasai: one direction that I think you've built up the framework for already is to allow the author, when it's necessary, to build up a form control from their own markup and layout
… and by using the component model, tell the browser what the model is, and have the browser fill in the behavior / events/ a11y pieces
… and maybe hook into some aspects of behavior, but there are defined hooks for that
… I think you've built up the framework for taht
… which we can then implement in the browser
… the opposite direction is to take the native browser controls and make them more stylable
… don't think the way to do that is expose the natvie controls as if they were native components with parts
… that structure is something the author doesn't know
… they cannot make an assumption based on "this is a part, if I style it this way it will make sense"
… so in order to make things stylable, you can't take the same approach
… the reason exposing the components works for the authors is that they control the styling and the structure and the layout
… it's not going to change under them
… so I think we've had some discussions about how to create styling for controls at an abstract level
… one is accent-color
… another proposal was defining archetypical component pieces, and having browsers extrapolate from that
… but the research you've done in figuring out the archetypes of form controls is a really good foundation for this
… but it'll be a different approach than trying to make these two systems come together in the middle
… 2 approaches based on the same abstract model
florian: I agree with a lot of things fantasai and tantek and jenn have been saying
… as long as appearnce is auto, we expect native controls, and all of what you've said is true
… while that is true, it's hopeless for the author to guess waht the parts are
… but when you do appearance:none, thisi s a request for the component not to be a native one
… so any and all parts can be overridden by the author
… so if we don't make assumptions / spec these, authors will make assumptions
… having it defined with a dom hierarchy, a thing that's compatible with the openui model, with a known ua style sheet
… but for sure once you switch to appearance:auto, then all these assumptions are gone
I agree with florian
jenn: I don't think we will get interop on that
… I think we should think what else is possible
gregwhitworth: basically I feel like what elika and jenn are touching on is partial styling
… chromium decided to have a drop shadow on something
… other browsers haven't
… does it have one on android? no idea. so I need to reset to some base
… if I understand fantasai correctly, the approach that will probably come into play, is what is similar to the password reveal thing
… we'll define a part, in a similar way to how pseudos have been used in the past
… we're going to assume these things are locked down
… to allow this partial styling
… we can't allow it to be display:grid for example
… I would love to see a base style sheet, and then any form factor can add on top of that
… with password reveal on amazon, the icon is different
… for branding reasons
… if iOS uses an eyeball I don't agree with, then I'll not leverage that
… so based on the research I've seen, I think this discards some of the reality we have
gregwhitworth: could we have more discussions of this types? in the CSSWG / at TPAC?
… figure out what makes sense from the CSSWG perspective
… I can present some research based on that angle
heycam: agree with a lot of FLorian said
heycam: Key thing is opt in for customizable control
heycam: that's how we can allow authors to rely on how controls are implemented
<tantek> I think we should consider the reverse, defaulting to a customizable control
heycam: without redefining native controls in ways that might not even be possible
gregwhitworth: Appreciate the discussion. Will go from email forward
<tantek> RRSAgent: make minutes
<gregwhitworth> truly loved that chat - thank you all so much for the time :)
<jensimmons> how do we get permissions to look at https://www.w3.org/2020/08/18-css-minutes.html ??
<fantasai> i/<fantasai> gregwhitworth: 'appearance: none' would fall back/scribenick: fantasai/