IRC log of css on 2020-08-18
Timestamps are in UTC.
- 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