22:13:30 <RRSAgent> RRSAgent has joined #css
22:13:30 <RRSAgent> logging to https://www.w3.org/2020/08/18-css-irc
22:13:52 <tantek> present+
22:13:53 <tantek> q?
22:14:32 <tantek> Topic: Open UI / CSS meeting
22:15:12 <jeff> jeff has joined #css
22:16:20 <melanierichards> present+
22:17:06 <heycam> q+
22:20:36 <masonfreed> masonfreed has joined #css
22:20:37 <florian> q+
22:20:46 <gregwhitworth> present+
22:20:50 <una> una has joined #css
22:20:55 <gregwhitworth> q?
22:21:03 <una> present+
22:21:10 <Guest60> present+
22:21:13 <Guest60> q+
22:21:17 <Guest60> present-
22:21:24 <florian> present+
22:21:26 <jensimmons> present+
22:22:40 <melanierichards> https://www.irccloud.com/pastebin/1oL6QOWj/
22:23:08 <melanierichards> 	• Greg: specific area where Open UI and CSS WG overlap is pseudo elements. Concrete example, select control, which is the furthest along…
22:23:08 <melanierichards> 	• Greg: parsing out what gets accessed as a pseudo-element, what is a new element
22:23:08 <melanierichards> 	• 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?
22:23:08 <melanierichards> 	• 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
22:23:08 <melanierichards> 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.
22:23:09 <melanierichards> 	• 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].
22:23:09 <melanierichards> 	• 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?
22:23:09 <melanierichards> 	• 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.
22:23:10 <melanierichards> 	• Greg: because that gets into appearance: none, that should live in CSS. "We don't define styles in Open UI" might still be true
22:23:18 <melanierichards> scribe: melanierichards
22:24:17 <melanierichards> 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
22:25:13 <melanierichards> fantasai: if you're in charge of structure, you can change that later. Author might start making assumptions how that calendar control is structured...styling of those pieces may not work in the way author envisioned originally. That's my concern on exposing too many parts of native controls
22:25:26 <melanierichards> fantasai: vs author implementing own control
22:25:43 <tantek> tantek has joined #css
22:25:47 <tantek> q?
22:25:48 <tantek> q+
22:25:53 <melanierichards> fantasai: we should standardize native form control, but I don't think standardizing on parts and part names is not necessarily way to do it for form controls
22:25:56 <florian> q-
22:26:03 <fantasai> s/standardize/make it possible to style/
22:26:12 <fantasai> s/for form/for such/
22:26:27 <dandclark> dandclark has joined #CSS
22:26:37 <fantasai> s/change that later/change that in conjunction with the styling/
22:26:40 <tantek> q+ to agree with no more appearance none complexity, and authors need more info about per-OS/platform control part structures in order to style them (conditional pseudos?)
22:26:47 <fantasai> s/that calendar contro/native calendar contro/
22:27:10 <fantasai> s/originally/originally when applied to a calendar control that is differently structured on a different device/
22:27:44 <melanierichards> 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
22:28:17 <fantasai> gregwhitworth: 'appearance: none' would fall back to base styles that are agreed on
22:28:25 <fantasai> fantasai: Might not necessarily be true across devices
22:28:33 <fantasai> heycam: Might not look like native form controls, but
22:28:41 <melanierichards> scribe: fantasai
22:29:15 <tantek> scribenick: fantasai
22:29:53 <fantasai> 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
22:30:16 <fantasai> gregwhitworth: Time control, could be laid out in any number of ways, don't want to restrict that
22:30:27 <fantasai> gregwhitworth: e.g. MSFT often comes up with new form factors
22:30:38 <fantasai> gregwhitworth: behaviors and controller code often follwos MVC model
22:30:46 <fantasai> gregwhitworth: select takes options, zero to N, doesn't change the layout
22:30:49 <fantasai> gregwhitworth: let's ratify that model
22:30:57 <fantasai> gregwhitworth: but also say, on desktop they're all different
22:31:01 <fantasai> gregwhitworth: the models are still identical
22:31:05 <fantasai> gregwhitworth: layouts and styling vary
22:31:16 <fantasai> gregwhitworth: Apple watch: model has not changed, but behaviors are still the same
22:31:27 <fantasai> gregwhitworth: keyboard still wired up, but not going to work unless bluetooth keyboard attached
22:31:43 <fantasai> gregwhitworth: One beign input that looks like text, vs other being radio
22:31:46 <fantasai> gregwhitworth: showing slots
22:32:02 <fantasai> gregwhitworth: Potential changes, ::part has more meaning based on thismodel not just styling
22:32:05 <fantasai> gregwhitworth: parts have meaning
22:32:10 <fantasai> gregwhitworth: can slot in whatever you want as an author
22:32:16 <fantasai> gregwhitworth: so time input being a text field
22:32:20 <fantasai> gregwhitworth: click on it pops up
22:32:28 <fantasai> gregwhitworth: someone comes along, input above, want it to be just text
22:32:34 <fantasai> gregwhitworth: when pop-up appears, odn't want it to be just text
22:32:42 <fantasai> gregwhitworth: will apply a part for controller code
22:32:53 <fantasai> gregwhitworth: wanted to show that with this bootstrap example
22:32:57 <fantasai> gregwhitworth: defining the part
22:33:00 <jensimmons> q?
22:33:03 <fantasai> gregwhitworth: wired up necessary ARIA stuff
22:33:14 <fantasai> gregwhitworth: completely different layout and appearance, but the model is the same
22:33:22 <florian> q+
22:33:26 <fantasai> gregwhitworth: To Cameron's point, we wanted to make it easier for authors to style
22:33:35 <fantasai> gregwhitworth: key aspect of styling, need a base style sheet to start from
22:33:45 <fantasai> gregwhitworth: if we do agree, then we want to modify the form control
22:33:54 <fantasai> gregwhitworth: will be shipped with web components, so rendered with web tech
22:34:01 <fantasai> gregwhitworth: would have access to those pieces with parts
22:34:09 <fantasai> gregwhitworth: but if everyone lays out list box differently
22:34:15 <fantasai> gregwhitworth: one uses flex, one needs grid
22:34:23 <fantasai> gregwhitworth: then need something new
22:34:28 <fantasai> gregwhitworth: to get to base style
22:34:45 <fantasai> gregwhitworth: We're aware of other form factors, didn't want to hinder
22:34:49 <fantasai> gregwhitworth: important aspect of design model
22:35:10 <gregwhitworth> q?
22:35:12 <fantasai> fantasai: Not sure you entirely understood what I was saying, but queue is long, let's come back to it
22:35:31 <fantasai> jensimmons: I think fantasai was trying to articulate some important things to understand
22:35:46 <fantasai> jensimmons: I think we have good agreement on goals, to allow authors be able to style things
22:36:05 <fantasai> jensimmons: Don't want authors to replace form conrols with their own
22:36:11 <fantasai> jensimmons: Also want authors to be able to style things
22:36:22 <fantasai> jensimmons: Also agreed that default styling will not match across browsers
22:36:29 <fantasai> jensimmons: room for differences
22:36:37 <fantasai> jensimmons: thoughts on `appearance: none` as a togge
22:36:49 <fantasai> jensimmons: either get native controls styling, or click into styleability
22:37:02 <fantasai> jensimmons: if we had a time machine, maybe we'd come up with more consistency, but can't
22:37:20 <fantasai> 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
22:37:28 <fantasai> jensimmons: where 'appearance' would trigger that structure
22:37:34 <fantasai> jensimmons: ...
22:37:45 <fantasai> jensimmons: HTML and CSS vs form controls are very different
22:37:55 <fantasai> jensimmons: Would be nice to style border / background but inherit rest of form contorl
22:38:03 <fantasai> jensimmons: I'm not sure we can do what you're talking about gregwhitworth
22:38:16 <fantasai> jensimmons: I think we need a hybrid of the proposals written up in CSSWG a couple months ago
22:38:19 <fantasai> jensimmons: Less prescriptive
22:38:27 <fantasai> jensimmons: Maybe we really need to look at what things to authors want to style the most
22:38:33 <fantasai> jensimmons: and how can we give them ability to do that
22:38:37 <fantasai> jensimmons: with more generic pseudo-classes
22:38:43 <una> q+ to answer Jen if possible
22:38:50 <fantasai> jensimmons: not so presectiptive, don't match exactly an exact web-component based model
22:38:52 <masonfreed> q+
22:38:54 <fantasai> jensimmons: give authors what they want and need
22:39:01 <fantasai> jensimmons: we also need to give implementers the flexibility that they need
22:39:27 <heycam> I feel like the appearance (or whatever mechanism toggle) is the thing that allows us to have a standardized control implementation and styling
22:39:28 <fantasai> tantek: Let me see if I can build on what fantasai and jensimmons said, because 100% agree
22:39:43 <fantasai> tantek: I agree it's a bad idea for 'appearance' to be repuprposed for components model
22:40:00 <fantasai> tantek: seems hacky, lots of constraints, would not want to go there
22:40:07 <fantasai> tantek: point that I think fantasai made and jensimmons expanded on
22:40:17 <fantasai> tantek: different browsers and potentialy different OSes, providing different views
22:40:22 <fantasai> tantek: number of parts, structure of parts
22:40:25 <fantasai> tantek: is spot on
22:40:37 <fantasai> tantek: it's possible exact same browser in two different layouts, depending on width of windoe e.g.
22:40:46 <fantasai> tantek: could provide completely different part hierarchies
22:40:49 <fantasai> tantek: intentionally
22:41:00 <fantasai> tantek: I don't think we can make any assumptions about what kind of pseudo elements an author could depend on or not
22:41:10 <fantasai> tantek: and any that we did provide, would give author an artificial sense of control
22:41:14 <fantasai> tantek: that these things are fixed
22:41:23 <fantasai> tantek: they aren't, across impls, platforms, even different views in same impl
22:41:37 <fantasai> tantek: What I think we need is a model where both the browser has the freedom to alter part hierarchy per control
22:41:44 <fantasai> tantek: based on things like dimensions of user's window or other things
22:41:47 <fantasai> tantek: but also for things like a11y
22:42:04 <fantasai> tantek: and where the author somehow has the ability to access what decisions the browsers has made wrt part hierarchy
22:42:13 <fantasai> tantek: and be able to style the different possible expressions of that hierarchy
22:42:24 <fantasai> tantek: consider mobile vs other, differences are complex
22:42:29 <fantasai> tantek: and it's getting worse
22:42:33 <fantasai> s/worse/more complex
22:42:43 <fantasai> gregwhitworth: I would like to see what differences you're seeing , that Open UI didn't figur eout
22:42:51 <fantasai> tantek: Not saying anatomy is wrong. Your existing research demonstrates this.
22:43:02 <fantasai> tantek: the part hierarchies that you have are way more reflective of spectrum of possibilities
22:43:11 <fantasai> tantek: than people's assumptions about e.g. input[type=file]
22:43:13 <fantasai> tantek: or datepickers
22:43:20 <fantasai> tantek: those are going to be extremely different across different things
22:43:28 <fantasai> tantek: maybe you've already modeled part hierarchy for datetime?
22:43:37 <fantasai> greg: we're trying to tackle most frustrating first
22:43:45 <fantasai> greg: I think maybe we're talking past each other
22:43:59 <fantasai> greg: are we referring to DOM, just parts? name of parts? or referring to layout structure of parts? all of these very different
22:44:02 <fantasai> greg:
22:44:05 <fantasai> greg: all of these are not defined by Open UI
22:44:09 <fantasai> tantek: I'm referring to both
22:44:24 <fantasai> greg: ???
22:44:32 <fantasai> tantek: layout is one, vs DOM is another
22:44:47 <fantasai> greg: and then there's the part, which doesn't require ither
22:44:58 <fantasai> jensimmons: some of us might be meaning the componetns, the code, how the form controls is made
22:45:39 <masonfreed> q?
22:45:41 <fantasai> fantasai: I think making assumptions about either layout or DOM structure, relationship of parts to each other, is going to be problematic
22:45:45 <tantek> fantasai: making assumptions about the dom, structure, or parts may be bad because those things are likely to change
22:45:47 <tantek> q-
22:45:47 <fantasai> fantasai: because those can change
22:46:58 <fantasai> fantasai: Open UI did a lot of great research on what the abstract parts and relationships
22:47:17 <fantasai> fantasai: so that could implement a control that maps those parts, and browser could map in the behavior / events / a11y etc.
22:47:28 <fantasai> greg: ...
22:47:34 <fantasai> greg: could implement without web compent tech
22:47:55 <fantasai> s/etc./etc. and could have any layout or dom structure you ant/
22:48:11 <fantasai> greg: ppl don't build the web component the same way. Model and parts are the same, but dom structure and layout are different
22:48:50 <fantasai> fantasai: browsers will have similarly wide differences, and so exposing parts for styling will not work
22:49:22 <fantasai> fantasai: I think it makes sense for us to tackle this problem from two different directions
22:49:42 <heycam> 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
22:49:47 <falken> falken has joined #css
22:49:58 <heycam> ... and by using the component model, tell the browser what the model is, and have the browser fill in the behavior / events/ a11y pieces
22:50:12 <heycam> ... and maybe hook into some aspects of behavior, but there are defined hooks for that
22:50:14 <heycam> ... I think you've built up the framework for taht
22:50:19 <heycam> ... which we can then implement in the browser
22:50:29 <heycam> ... the opposite direction is to take the native browser controls and make them more stylable
22:50:40 <heycam> ... don't think the way to do that is expose the natvie controls as if they were native components with parts
22:50:50 <heycam> ... that structure is something the author doesn't know
22:51:01 <heycam> ... they cannot make an assumption based on "this is a part, if I style it this way it will make sense"
22:51:08 <masonfreed> q-
22:51:11 <heycam> ... so in order to make things stylable, you can't take the same approach
22:51:23 <majidvp> majidvp has joined #css
22:51:24 <heycam> ... the reason exposing the components works for the authors is that they control the styling and the structure and the layout
22:51:26 <una> q-
22:51:30 <heycam> ... it's not going to change under them
22:51:34 <foolip> foolip has joined #css
22:51:46 <heycam> ... so I think we've had some discussions about how to create styling for controls at an abstract level
22:51:48 <heycam> ... one is accent-color
22:52:04 <heycam> ... another proposal was defining archetypical component pieces, and having browsers extrapolate from that
22:52:16 <tantek> q?
22:52:22 <heycam> ... but the research you've done in figuring out the archetypes of form controls is a really good foundation for this
22:52:32 <heycam> ... but it'll be a different approach than trying to make these two systems come together in the middle
22:52:44 <heycam> ... 2 approaches based on the same abstract model
22:52:59 <heycam> florian: I agree with a lot of things fantasai and tantek and jenn have been saying
22:53:16 <heycam> ... as long as appearnce is auto, we expect native controls, and all of what you've said is true
22:53:32 <heycam> ... while that is true, it's hopeless for the author to guess waht the parts are
22:53:43 <heycam> ... but when you do appearance:none, thisi s a request for the component not to be a native one
22:53:50 <heycam> ... so any and all parts can be overridden by the author
22:53:52 <gregwhitworth> gregwhitworth has joined #css
22:54:00 <bkardell_> bkardell_ has joined #css
22:54:00 <Travis> Travis has joined #css
22:54:02 <heycam> ... so if we don't make assumptions / spec these, authors will make assumptions
22:54:51 <heycam> ... having it defined with a dom hierarchy, a thing that's compatible with the openui model, with a known ua style sheet
22:55:04 <heycam> ... but for sure once you switch to appearance:auto, then all these assumptions are gone
22:55:15 <heycam> I agree with florian
22:55:24 <heycam> jenn: I don't think we will get interop on that
22:55:29 <heycam> ... I think we should think what else is possible
22:55:53 <heycam> gregwhitworth: basically I feel like what elika and jenn are touching on is partial styling
22:56:01 <heycam> ... chromium decided to have a drop shadow on something
22:56:05 <heycam> ... other browsers haven't
22:56:07 <kereliuk> kereliuk has joined #css
22:56:12 <jensimmons> q+
22:56:13 <heycam> ... does it have one on android? no idea. so I need to reset to some base
22:56:26 <heycam> ... if I understand fantasai correctly, the approach that will probably come into play, is what is similar to the password reveal thing
22:56:33 <yoichio> yoichio has joined #css
22:56:33 <drott> drott has joined #css
22:56:36 <heycam> ... we'll define a part, in a similar way to how pseudos have been used in the past
22:56:42 <heycam> ... we're going to assume these things are locked down
22:56:45 <heycam> ... to allow this partial styling
22:56:51 <heycam> ... we can't allow it to be display:grid for example
22:57:00 <NavidZ_> NavidZ_ has joined #css
22:57:18 <heycam> ... I would love to see a base style sheet, and then any form factor can add on top of that
22:57:40 <heycam> ... with password reveal on amazon, the icon is different
22:57:43 <heycam> ... for branding reasons
22:57:59 <heycam> ... if iOS uses an eyeball I don't agree with, then I'll not leverage that
22:58:14 <heycam> ... so based on the research I've seen, I think this discards some of the reality we have
22:58:51 <heycam> gregwhitworth: could we have more discussions of this types? in the CSSWG / at TPAC?
22:59:04 <heycam> ... figure out what makes sense from the CSSWG perspective
22:59:13 <heycam> ... I can present some research based on that angle
22:59:27 <jensimmons> q-
22:59:32 <fantasai> heycam: agree witha lot of FLorian said
22:59:40 <fantasai> heycam: Key thing is opt in for customizable control
22:59:47 <fantasai> heycam: that's how we can allow authors to rely on how controls are implemented
22:59:53 <jensimmons> q+
22:59:56 <tantek> I think we should consider the reverse, defaulting to a customizable control
22:59:58 <fantasai> heycam: without redefining native controls in ways that might not even be possible
23:00:29 <fantasai> gregwhitworth: Appreciate the discussion. Will go from email forward
23:01:39 <tantek> present+ heycam gregwhitworth jensimmons melanierichards
23:01:43 <tantek> zakim, who is here?
23:01:43 <Zakim> Present: tantek, melanierichards, gregwhitworth, una, florian, jensimmons, heycam
23:01:46 <Zakim> On IRC I see NavidZ_, drott, yoichio, kereliuk, Travis, bkardell_, gregwhitworth, foolip, majidvp, falken, dandclark, tantek, una, masonfreed, jeff, RRSAgent, Zakim, Karen, jess,
23:01:46 <Zakim> ... dtapuska, sanketj, emilio, jcraig, svoisen, achraf, slightlyoff, jensimmons, dauwhe_, SimonSapin, zcorpan, geheimnis`, gsnedders, spectranaut, innovati, sylvaing, shans,
23:01:50 <Zakim> ... Rossen, leaverou, projector, hayato, timeless, cbiesinger, shane, sangwhan, nainar, ojan, Letze, jyasskin, JonathanNeal, surma, liam, github-bot, Mek, dustinm, CSSWG_LogBot,
23:01:50 <Zakim> ... ondrejko
23:01:57 <tantek> RRSAgent: make minutes
23:01:57 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/18-css-minutes.html tantek
23:01:59 <gregwhitworth> truly loved that chat - thank you all so much for the time :)
23:12:11 <jensimmons> how do we get permissions to look at https://www.w3.org/2020/08/18-css-minutes.html ??
23:13:21 <jensimmons> rrsagent, make logs public
23:14:21 <tantek> RRSAgent, pointer?
23:14:21 <RRSAgent> See https://www.w3.org/2020/08/18-css-irc#T23-14-21
23:16:14 <fantasai> i/<fantasai> gregwhitworth: 'appearance: none' would fall back/scribenick: fantasai/
23:16:26 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/18-css-minutes.html fantasai
23:16:57 <fantasai> i/fantasai: one direction/scribenick: heycam/
23:17:00 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/18-css-minutes.html fantasai
23:17:30 <fantasai> s/• //g
23:17:31 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/18-css-minutes.html fantasai
23:18:40 <fantasai> s/thing. Part of the reasoning/Florian: Part of the reasoning/
23:19:42 <fantasai> i/heycam: agree witha/scribenick: fantasai/
23:19:48 <fantasai> s/witha lot/with a lot/
23:19:56 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/18-css-minutes.html fantasai
23:20:02 <hober> I'm so sorry I missed this meeting! Was it announced somewhere?
23:26:54 <gregwhitworth> hober: I'm so sorry, it was during the CSSWG F2F meeting
23:27:23 <gregwhitworth> hober: I'll add you to the follow up email as I think we'll figure out a CSSWG topic
23:29:43 <astearns> gregwhitworth: could you announce things like this to one of our mailing lists?
23:30:20 <astearns> Or one of OpenUI's? I went looking for a meeting pointer once I noticed it had started and could not find anything
23:30:37 <gregwhitworth> astearns: for sure, I apologize - I kept it to the Doodle folks that showed interest
23:30:49 <astearns> no worries - thanks for organizing it!
23:33:59 <hober> I was in and out of the F2F & (many) conflicting meetings, so I must have missed that part.
23:34:23 <jeff> jeff has joined #css