IRC log of css on 2020-10-20

Timestamps are in UTC.

00:05:53 [zcorpan]
zcorpan has joined #css
00:27:38 [zhengxu]
zhengxu has joined #css
01:02:52 [RRSAgent]
I have made the request to generate https://www.w3.org/2020/10/20-css-minutes.html fantasai
01:03:21 [RRSAgent]
I have made the request to generate https://www.w3.org/2020/10/20-css-minutes.html fantasai
01:18:47 [zhengxu]
zhengxu has joined #css
04:29:57 [smfr]
smfr has joined #css
04:30:16 [smfr]
i am trying to make sense of this text in cssom-view-1: “Elements and viewports have an associated scrolling box if the element or viewport has a scrolling mechanism or it overflows its content area and the used value of the overflow-x or overflow-y property is hidden. [CSS3-BOX]”
04:30:26 [smfr]
is *not* hidden?
04:37:25 [liam]
yeah, i think so too, for what it's worth
04:45:30 [smfr]
and it should be “not hidden or clip” now
04:47:48 [fantasai]
what's "it"?
04:48:03 [fantasai]
The viewport overflows its content area?
04:48:06 [fantasai]
what???
04:48:17 [fantasai]
what about if it overflows the content area but not the padding box?
04:48:34 [fantasai]
why would that make any difference
04:54:29 [liam]
this shuld be two or three separate sentences
04:57:34 [anssik]
anssik has joined #css
04:57:59 [smfr]
yeah there are some missing words
05:07:57 [smfr]
smfr has joined #css
20:02:08 [RRSAgent]
RRSAgent has joined #css
20:02:08 [RRSAgent]
logging to https://www.w3.org/2020/10/20-css-irc
20:02:10 [Zakim]
RRSAgent, make logs Public
20:02:11 [Zakim]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
20:02:18 [Rossen_]
present+
20:02:21 [Morgan]
present+
20:02:22 [dlibby]
present+
20:02:23 [astearns]
present+
20:02:24 [florian]
present+
20:02:24 [vmpstr]
present+
20:02:25 [oriol]
present+
20:02:28 [faceless2]
present+
20:02:41 [alisonmaher]
present+
20:02:43 [TYLin]
present+
20:02:56 [smfr]
smfr has joined #css
20:03:21 [bkardell_]
present+
20:03:22 [heycam]
present+
20:03:25 [myles]
present+ myles
20:03:35 [Guest60]
I'm waiting to allowed in
20:03:46 [dlibby]
we missed the last MQ discussion yesterday, can we start there?
20:03:54 [smfr]
present_
20:03:57 [smfr]
present+
20:04:35 [miriam]
present+
20:04:40 [fantasai]
present+
20:05:08 [Rossen_]
Rossen Atanassov, Microsoft
20:05:11 [rego]
present+
20:05:15 [cbiesinger]
present+
20:05:15 [Morgan]
Morgan Reschenberg, Mozilla
20:05:15 [plinss]
present+
20:05:16 [astearns]
Alan Stearns, Adobe
20:05:16 [myles]
Myles C. Maxfield, Apple Inc.
20:05:17 [smfr]
Simon Fraser, Apple
20:05:20 [rego]
Manuel Rego, Igalia
20:05:21 [cbiesinger]
Christian Biesinger, Google
20:05:22 [plinss]
Peter Linss, Invited Expert
20:05:22 [bkardell_]
Brian Kardell, Igalia
20:05:23 [GameMaker]
GameMaker has joined #css
20:05:24 [vmpstr]
Vladimir Levin, Google
20:05:25 [oriol]
Oriol Brufau, Igalia
20:05:26 [TabAtkins]
Tab Atkins-Bittner, Google
20:05:26 [florian]
Florian Rivoal, Invited Expert
20:05:27 [brandonferrua]
brandonferrua has joined #css
20:05:28 [alisonmaher]
Alison Maher, Microsoft
20:05:31 [GameMaker]
present+
20:05:32 [jensimmons]
present+
20:05:33 [brandonferrua]
present+
20:05:36 [GameMaker]
Megan Gardner, Apple
20:05:44 [brandonferrua]
Brandon Ferrua, Salesforce
20:05:45 [miriam]
Miriam Suzanne, Invited Expert
20:05:48 [TYLin]
Ting-Yu Lin, Mozilla
20:05:59 [heycam]
Cameron McCormack, Mozilla
20:06:04 [jensimmons]
Jen Simmons, Apple, Inc.
20:06:05 [fremy]
fremy has joined #css
20:06:09 [fantasai]
Elika Etemad aka fantasai, Invited Expert
20:06:12 [fantasai]
Topic: Masonry Layout
20:06:14 [fantasai]
ScribeNick: fantasai
20:06:18 [chrishtr]
Chris Harrelson, Google
20:06:18 [fremy]
present+
20:06:21 [chris]
chris has joined #css
20:06:24 [fantasai]
mats_: I wrote the Masonry spec
20:06:29 [fantasai]
https://raw.githack.com/mozilla/gecko-dev/master/layout/docs/css-grid-3/Overview.html
20:06:56 [dholbert]
dholbert has joined #css
20:06:59 [fantasai]
mats_: That's what we'll discuss today. I didn't prepare any presentatin of it, but happy to answer any technical questions you might have
20:07:06 [kzms2]
present+
20:07:10 [fantasai]
heycam: Last time I presented the explainer based on Mats's gh issue
20:07:15 [fantasai]
heycam: Mats turned that into spec text
20:07:19 [dholbert_]
dholbert_ has joined #css
20:07:26 [fantasai]
heycam: Main thing we want today is, ask to put this into a draft
20:07:32 [fantasai]
heycam: and secondly, which spec does that go into
20:07:36 [fantasai]
heycam: is it Grid 3 or something else
20:07:46 [dlibby_]
dlibby_ has joined #css
20:07:55 [fantasai]
Rossen_: Last time discussed in F2F, was at Igalia
20:08:09 [fantasai]
Rossen_: Have there been any major changes since then?
20:08:19 [fantasai]
Rossen_: Some of the early conversation was should it be part of grid or own display value.
20:08:27 [fantasai]
Rossen_: Did we resolve on this? Current proposal uses grid
20:08:33 [fantasai]
fantasai is in favor of using grid
20:08:40 [fantasai]
heycam: That hasn't changed in the spec
20:08:48 [drousso]
drousso has joined #css
20:08:51 [TabAtkins]
q+
20:08:53 [jensimmons]
q+
20:08:54 [drousso]
present+
20:08:54 [fantasai]
heycam: Initial proposal was tied into grid and not a separate layout model
20:09:01 [fantasai]
heycam: Not sure if that's captured as an issue in the spec itself
20:09:09 [fantasai]
heycam: Mats, could you talk about open issues listed in the spec?
20:09:29 [fantasai]
mats_: [garbled]
20:09:42 [fantasai]
mats_: A few issues in the spec, but mostly resolving edge cases
20:09:42 [gregwhitworth]
present+
20:09:59 [dholbert]
present+
20:10:34 [fantasai]
Rossen_: We should make the issue clear
20:10:53 [fantasai]
Rossen_: Do we want to adopt this module?
20:11:05 [fantasai]
heycam: Maybe easier to resolve on that first, then file specific issues in GH
20:11:16 [Rossen_]
q?
20:11:21 [fantasai]
iank_: Unsure if there was much follow-up discussion about in grid vs separate display tpe
20:11:24 [fantasai]
s/tpe/type
20:11:51 [chrishtr]
q+
20:11:59 [fremy]
q+
20:12:08 [Rossen_]
ack TabAtkins
20:12:18 [fantasai]
TabAtkins: First, I was looking for where the proposal was and had trouble finding it. Have URL now
20:12:32 [fantasai]
TabAtkins: looking in the thread, back in January we already agreed to adopt this proposal
20:12:39 [fantasai]
TabAtkins: editors me, mats, fantasai, jensimmons
20:12:49 [fantasai]
TabAtkins: We haven't done anything with it, but it seems like we already agreed to adopt it
20:12:58 [fantasai]
TabAtkins: so should dive into structural questions like is it grid or not
20:13:07 [Rossen_]
ack jensimmons
20:13:22 [fantasai]
jensimmons: So not even sure what we're debating, but have comments on whether should be part of grid display type or own display type
20:13:29 [fantasai]
jensimmons: Seems we haven't resolved that
20:13:38 [fantasai]
jensimmons: I think it should be part of the grid display tpe
20:13:44 [fantasai]
jensimmons: I really like how this proposal works. Read it again today.
20:13:45 [jarhar]
jarhar has joined #css
20:13:53 [fantasai]
jensimmons: I've been thinking about it the last few months, but re-reading again
20:14:06 [fantasai]
jensimmons: think it would be awful lot of work to figure out making it not grid, in the other dimension etc.
20:14:12 [fantasai]
jensimmons: and would perhaps settle on something simplistic
20:14:19 [iank_]
q+
20:14:31 [fantasai]
jensimmons: by making part of Grid, get an incredible body of work, resolved on gaps, alignment, repetition of tracks, etc.
20:14:34 [TabAtkins]
If we did it as a separate thing, we would explicitly just do "exactly what Grid does" in everything that overlaps.
20:14:36 [fantasai]
jensimmons: using minmax, etc.
20:14:42 [fantasai]
jensimmons: Don't know why we would want to give authors a separate set of tools
20:14:48 [fantasai]
jensimmons: Don't want to give authors two sets of things to learn
20:15:02 [fantasai]
jensimmons: Argument from before, word "grid" means everything lines up in 2D but masonry is packing
20:15:05 [fantasai]
jensimmons: but I think that's a pedantic argument
20:15:09 [florian]
q+
20:15:10 [TabAtkins]
It would just let us get a slightly more optimized syntax for declaring the masonry, basically.
20:15:19 [fantasai]
jensimmons: I don't think "grid" can't encompass this
20:15:32 [fantasai]
jensimmons: I think it should be part of grid, and I really like the direction this is going so far
20:15:47 [Rossen_]
ack chrishtr
20:16:07 [fantasai]
chrishtr: I'm wondering if, related to point already made about relation to grid, do you have data to show about how hard to implement or how much it re-uses the concept of grid?
20:16:36 [fantasai]
mats_: It was pretty easy to fit into existing CSS grid code that we have
20:16:44 [fantasai]
mats_: CSS grid, all the algorithms, are pretty standalone per axis
20:16:51 [fremy]
q!
20:16:52 [fantasai]
mats_: so our code at least, just run the code for one axis
20:17:01 [fantasai]
mats_: ...
20:17:04 [fantasai]
mats_: It shouldn't be hard
20:17:13 [fantasai]
mats_: to implement for an existing CSS Grid implementatin
20:17:14 [fremy]
fantasai: what's the keyword for moving yourself at the bacvk of the queue again?
20:17:20 [fantasai]
mats_: get a lot of free structural [?]
20:17:35 [Rossen_]
ack fremy
20:17:42 [fremy]
q+
20:17:56 [fantasai]
iank_: I think my concerns from last time still hold
20:18:09 [fantasai]
iank_: Unless I'm wrong, a few things in the grid model that not in the masonry model
20:18:13 [fantasai]
iank_: e.g. grid-area
20:18:17 [fantasai]
iank_: right?
20:19:05 [fantasai]
iank_: If I have grid-area: 1/2 it will ignore one of the axes
20:19:10 [TabAtkins]
I strongly suspect we'd just literally build Masonry stuff into the Grid Layout Algo, even if we did Masonry as a separate spec.
20:19:10 [Rossen_]
q?
20:19:16 [Rossen_]
ack iank_
20:19:23 [fantasai]
mats_: yes
20:19:25 [chris]
present+
20:19:26 [fantasai]
iank_: That concerns me
20:19:37 [fantasai]
iank_: Also, want to do things like splitting content over two grid areas
20:19:42 [fantasai]
iank_: can re-use concepts
20:19:48 [fantasai]
iank_: but I'd be hesitant to jump the gate
20:20:03 [fantasai]
florian: I agree more with Jen than Ian
20:20:11 [fantasai]
florian: Almost all the tools that work in Grid also should work here
20:20:28 [fantasai]
florian: So theoretically we could have 'display: masonry' that either uses all the grid properties or has duplicate properties
20:20:28 [chris]
q?
20:20:32 [fantasai]
florian: but do we really need this?
20:20:40 [fantasai]
florian: Having a few properties not apply some of the time is really OK
20:20:44 [TabAtkins]
q+ about the set of properties applying to grid vs masonry
20:20:53 [Rossen_]
q?
20:20:57 [fantasai]
florian: Other question, If you're trying to fall back from masonry, what happens?
20:20:58 [Rossen_]
ack florian
20:21:01 [TabAtkins]
q+
20:21:18 [fantasai]
florian: If separate display type, you fall back to block. Grid is probably a better naive fallback.
20:21:28 [fantasai]
florian: But I'm leaning towards keeping it a grid variation rather than a separate thing
20:21:36 [fantasai]
florian: and not too concerned about Ian's concern
20:21:42 [fremy]
q- later
20:21:52 [TabAtkins]
fantasai: I also think it makes sense to integrate it with grid, for all the reasons mentioned
20:21:58 [Rossen_]
ack fantasai
20:22:13 [TabAtkins]
fantasai: in terms of various things not applying, if we wantt hem to apply i think we could have a masonry layout and grid layout if we wanted to
20:22:31 [TabAtkins]
fantasai: So if you assign it to row 1 it's in a masonry layout in row 1, then if you put it in row 2 it's in a separate masonry layout
20:22:40 [TabAtkins]
fantasai: Woudl be happy to adopt as an ED and possibly as a fpwd
20:22:44 [Rossen_]
ack TabAtkins
20:22:53 [fantasai]
TabAtkins: Looking over the set of grid properties and whether or not they apply
20:23:10 [fantasai]
TabAtkins: It is absolutely the case that Masonry should be built on Grid algorithm
20:23:14 [fantasai]
TabAtkins: but as for property set
20:23:26 [fantasai]
TabAtkins: Most of them will have weirdness that only one of the pair works in masonry layout
20:23:37 [fantasai]
TabAtkins: grid-auto-rows vs grid-auto-columns
20:23:47 [fantasai]
TabAtkins: We have different flow values for masonry that do something similar but distinct
20:23:52 [fantasai]
TabAtkins: similar to placement properties
20:24:08 [fantasai]
TabAtkins: and then I guess row gap vs column gap work similarly
20:24:20 [fantasai]
TabAtkins: I think we should make a new display value with its own properties
20:24:25 [fantasai]
TabAtkins: but have a single layout algorithm
20:24:50 [fantasai]
TabAtkins: but I think we have a good opportunity to have a better developer-facing API instead of trying to re-use and half-ignore the grid properties.
20:24:59 [Rossen_]
q?
20:25:00 [fantasai]
TabAtkins: but happy to be wrong, but I want to play around with making a new set of things just in case
20:25:08 [Rossen_]
ack fremy
20:25:14 [fantasai]
fremy: I think I agree with Tab on this mostly
20:25:25 [fantasai]
fremy: but also, want to accept as WD
20:25:35 [fantasai]
fremy: I took a look, there's like one new property, masonry-auto-flow
20:25:41 [fantasai]
fremy: but no definition of what the values do
20:25:48 [fantasai]
fremy: Hesitant to accept when there's no definition
20:25:58 [fantasai]
fremy: I feel like it's not working great
20:26:12 [fantasai]
fremy: So leaning towards saying, let's make this something different and if in the end we find we re-use most of the things
20:26:22 [myles]
q+
20:26:26 [fantasai]
fremy: but first let's define standalone and then later on if we find convergence, I think it would be more logical
20:26:45 [Rossen_]
ack myles
20:26:55 [fantasai]
myles: Understand idea that some grid properties won't apply to masonry. And in the future, some masonry properties won't apply to grid either
20:27:19 [fantasai]
myles: And understand argument that even if different specs, even if properties with different names in different specs, can share algorithm
20:27:32 [fantasai]
myles: The strongest differentiator between the two solutions is what the fallback is
20:27:47 [fantasai]
myles: is it better to have masonry fall back to block, or to have some properties that apply just to grid
20:27:58 [TabAtkins]
q+
20:28:01 [fantasai]
myles: If masonry layout falls back to block, much worse than falling back to grid with some properties ignored
20:28:13 [fantasai]
fremy: You can also fall back using @supports
20:28:24 [fantasai]
fremy: There's no good reason to limit yourself because of fallback
20:28:32 [iank_]
```display: grid; display: masonry;``` is what a lot of folks will do for this case.
20:28:33 [fantasai]
fremy: Even if the properties work similarly, not quite the same
20:28:46 [Karen]
Karen has joined #css
20:28:50 [fantasai]
myles: The argument there is about what authors get by default
20:29:00 [Rossen_]
ack TabAtkins
20:29:02 [jensimmons]
q+
20:29:04 [fantasai]
myles: of course you can do anything, but what about authors who don't think about these cases
20:29:19 [fantasai]
TabAtkins: This is the same argument that led to multicol being built on block and not being a separate display tpe
20:29:33 [fantasai]
TabAtkins: Multicol is different of block, and having one be variant of other is weird
20:29:47 [florian]
q?
20:29:51 [fantasai]
TabAtkins: The fact that it's a "block container" is awkward, and I'm afraid we'll run into the same problem again
20:30:04 [fantasai]
TabAtkins: But because going to be slightly different
20:30:18 [fantasai]
TabAtkins: I suspect we'll end up writing ourselves into awkward corners if one different from other
20:30:39 [fantasai]
heycam: I think the comparison to multicol is interesting in another way because we have this precedent of having the gap properties, which apply to flex and grid etc.
20:30:48 [fantasai]
heycam: we gave them one name to apply across multiple layout models
20:30:59 [fantasai]
heycam: Here we have grid-specific properties, but if we considered masonry separate from grid
20:31:03 [fantasai]
heycam: names ... obvious
20:31:21 [fantasai]
Rossen_: Want to make the discussion more action-oriented. Repeating previous discussions
20:31:32 [heycam]
s/names ... obvious/names of some grid properties could be changed so that the commonalities are more obvious/
20:31:33 [fantasai]
Rossen_: want to make sure we arrive at an actual resolution of what we're doing with the current spec
20:31:48 [fantasai]
Rossen_: keep separating the leading sort of differences on the table
20:32:10 [fantasai]
Rossen_: implementers and what they prefer vs. fallback mechanism vs. users and authors and how they will perceive from an ergonomic point of view
20:32:27 [Rossen_]
ack jensimmons
20:32:39 [fantasai]
jensimmons: The way I see it, alignment was created to go with flexbox and then folks realized it would be great to do in grid
20:32:53 [fantasai]
jensimmons: and rather than come up with new set of keywords and values, because they do work slightly differently
20:33:12 [heycam]
github: https://github.com/w3c/csswg-drafts/issues/4650
20:33:13 [fantasai]
jensimmons: but the argument that authors, it'll be too hard to say 'grid-template-rows: masonry' and then 'grid-auto-rows: ??' to set the default
20:33:23 [fantasai]
jensimmons: but 'grid-auto-rows' doesn't aply
20:33:27 [fantasai]
jensimmons: I don't think authors will be confused
20:33:31 [fantasai]
jensimmons: to me it's very similar to alignment
20:33:54 [Rossen_]
q?
20:33:59 [fantasai]
jensimmons: for alignment, making a separate set of syntax would have been much much more confusing
20:34:02 [fantasai]
jensimmons: I'm really glad they share syntax
20:34:06 [fantasai]
jensimmons: and that's my thought son this
20:34:14 [fantasai]
jensimmons: It doesn't seem like a completely different layout model
20:34:19 [fantasai]
jensimmons: It's an option in something bigger
20:34:26 [fantasai]
jensimmons: and that is something that looks a lot like grid
20:34:35 [fantasai]
jensimmons: Don't want duplication, new set of names and properties, etc.
20:34:58 [fantasai]
jensimmons: Not just doing the simplest things possible in masonry.js, but much more powerful because built on Grid
20:35:25 [TabAtkins]
fantasai: my proposal is that we adopt this as an ED, and i dont' reallyc are if we temporarily name it css-masonry or css-grid-3
20:35:32 [TabAtkins]
fantasai: and think we should fill out the missing dfns, etc
20:36:11 [TabAtkins]
fantasai: and come back to this topic and decide if we want to take it as fpwd as either name, and let Tab try his attempt at different names, let Jen survey authors, and come back to it in a month or two
20:36:18 [TabAtkins]
fantasai: but adopt it for now as an official ed
20:36:29 [TabAtkins]
fantasai: It'll be a diff spec built on top of grid anyway, at least at first
20:36:31 [florian]
+1
20:36:55 [fantasai]
fantasai: and publish FPWD when we think we're ready to show something to the world
20:37:06 [fantasai]
Rossen_: Internally uses grid, but also is masonry layout
20:37:37 [fantasai]
Rossen_: suggest adopt as-is and then decide upon FPWD
20:37:56 [fantasai]
myles: We support progress on Masonry, and agree with fantasai, let's take the step we can take immediately
20:38:14 [fantasai]
Rossen_: and might have other things to add to css-grid-3 also
20:38:31 [fantasai]
fantasai: We have a list of stuff that's going into Grid 3 already, already resolved, just needs edits ...
20:38:37 [fantasai]
RESOLVED: Adopt Mats's draft as ED
20:38:50 [fantasai]
Rossen_: Mats, before you transition over, do you want to add the rest of the editors to this spec?
20:39:15 [fantasai]
Rossen_: Jen, are you up to it?
20:39:23 [fantasai]
jensimmons: yes, I would love to! yay new company that let's me do things
20:39:57 [fantasai]
heycam: Firefox has recently gained a new experiments stage in the preferences
20:40:03 [fantasai]
s/company/boss/
20:40:10 [fantasai]
heycam: can turn it on and play with it
20:40:18 [fantasai]
heycam: Settings options preferences
20:40:23 [fantasai]
heycam: I think you have to be using Nightly
20:40:31 [fremy]
q+
20:40:58 [Rossen_]
ack fremy
20:41:07 [fantasai]
fremy: Now that we adopted the ED, that sounds cool, but would like to discuss content of the draft
20:41:28 [fantasai]
fremy: I'm not sure I understand the reason why we have all the keywords in 'masonry-auto-flow'
20:41:39 [fantasai]
fremy: But reading the algorithms section, I'm not sure what's the goal
20:41:46 [fantasai]
fremy: I think it would be a good idea to clarify a bit
20:42:00 [fantasai]
Rossen_: We'll have the ED in the csswg repo pretty soon, hopefully by the end of the week
20:42:08 [fantasai]
Rossen_: once this is the case, you can go ahead and file as many issues as you want
20:42:14 [fantasai]
Rossen_: First issue might be display type
20:42:27 [fantasai]
Rossen_: as well as everything else that is currently unclear, but at this point spent a lot of time and other agenda items
20:42:33 [fantasai]
Rossen_: so please open issues
20:42:34 [fantasai]
fremy: sure
20:42:47 [Rossen_]
q?
20:43:19 [fantasai]
Topic: What Topic
20:43:32 [fantasai]
Rossen_: MQ issue didn't take up yesterday, any others we missed?
20:43:57 [fantasai]
Topic: media queries for foldable and dual-screen devices
20:44:27 [TabAtkins]
ScribeNick: TabAtkins
20:44:33 [TabAtkins]
Topic: Foladable screens
20:44:38 [TabAtkins]
Topic: Foldable screens
20:44:45 [astearns]
github: https://github.com/w3c/csswg-drafts/issues/5621
20:45:10 [TabAtkins]
dlibby_: This is an updated proposal for primitives we'd like to introduce for dual-screen and foldable devices
20:45:23 [TabAtkins]
dlibby_: This one is a new media feature that describes the number of logical display regions a viewport is spanning across
20:45:36 [TabAtkins]
dlibby_: Not th edevice itself, the relationship of the viewport to the device regions
20:45:48 [TabAtkins]
dlibby_: The syntax is in two axises to allow for future form factors to use the same feature
20:46:08 [TabAtkins]
dlibby_: goes hand-in-hand with the environment vars we discussed yesterday
20:46:24 [heycam]
q+
20:46:25 [TabAtkins]
dlibby_: Looking for opinions on this and if it's okay to add to mq5
20:46:39 [TabAtkins]
q+ myles
20:46:42 [florian]
q+
20:46:50 [myles]
q+
20:46:55 [Rossen_]
ack heycam
20:47:24 [TabAtkins]
heycam: my initial thoughts about this is whether these features are, don't wanna say complex bc the syntax isn't complex, but wondering if really there will be that many arrangements of displays that we need a feature shaped like this, as opposed to something simpler
20:47:41 [TabAtkins]
dlibby_: in our original proposal we wer emore scoped, but that came with the baggage that as new form factors appeared, what is the syntax you would use for them?
20:47:59 [TabAtkins]
dlibby_: So we feel this gives a more futur-eproof model, while allowing author to target today's devices
20:48:05 [Rossen_]
ack myles
20:48:08 [dholbert_]
dholbert_ has joined #css
20:48:31 [TabAtkins]
myles: Sof or width queries, for example, if you say (display-span-x: 3), is that *at least* three screens, or exactly 3?
20:48:37 [Rossen_]
q?
20:48:53 [TabAtkins]
dlibby_: Exactly, if you use the : or =. If you use < or > it gives less or more
20:48:54 [smfr]
q+
20:49:16 [TabAtkins]
myles: This also suggests authors might have different layouts for each arrangement - a different for 2x1 vs 1x2 vs 2x2, etc. That's the intent?
20:49:19 [TabAtkins]
dlibby_: Yes.
20:49:36 [Rossen_]
ack fantasai
20:49:36 [Zakim]
fantasai, you wanted to react to myles
20:49:50 [TabAtkins]
fantasai: The mq would give you an exact number, but becuse it's an integer ti can take min/max prefixes as well, so you can just opt into "2 or more displays"
20:49:51 [myles]
fantasai: display-span-x: min(2)?
20:50:00 [dholbert_]
dholbert_ has joined #css
20:50:09 [TabAtkins]
fantasai: To respond to heycam, the reason I didn't want to do simpler syntax, if someone has a 3-fold device we'd need a new MQ
20:50:20 [TabAtkins]
(myles, no, (min-display-span-x: 2))
20:50:40 [TabAtkins]
fantasai: The syntax for this simple case isn't any harder ot use than a more "specialized" one, but it lets us extend to a grid easily
20:50:47 [TabAtkins]
fantasai: it doesn't let us extend to a non-grid, tho
20:51:00 [TabAtkins]
fantasai: but i think most of the cases we'll need to worry about will be a grid or simplification of a grid
20:51:01 [myles]
(TabAtkins: oh! are all number-taking media queries supposed to automatically get min- and max- prefixes?)
20:51:07 [TabAtkins]
fantasai: So didn't want to box us into a corner
20:51:09 [TabAtkins]
(yes)
20:51:10 [Rossen_]
q?
20:51:19 [Rossen_]
ack florian
20:51:23 [TabAtkins]
florian: i think this works nicely
20:51:32 [TabAtkins]
florian: as discussed yesterday, desktops can b emore complex arrangements
20:51:46 [TabAtkins]
florian: but this isn't just windows that can be slightly offset from each other, it's a special display mode
20:52:03 [TabAtkins]
florian: And I think a grid is really the only realistic mode to deal with
20:52:10 [TabAtkins]
florian: [shows off an example]
20:52:23 [TabAtkins]
florian: So i think we're good
20:52:33 [Rossen_]
q?
20:52:39 [Rossen_]
ack smfr
20:52:44 [TabAtkins]
smfr: Does the asnwer to these mqs depend on which screen the browser is on?
20:52:53 [TabAtkins]
smfr: From samsung demos, browser can be on left, right, ro spanning both
20:52:57 [TabAtkins]
smfr: So will these change?
20:53:06 [TabAtkins]
dlibby_: Yes, if you're only on a single screen, your display-span will be 1
20:53:16 [TabAtkins]
smfr: So not about the physical device, about the current configuration
20:53:25 [Rossen_]
ack fantasai
20:53:39 [TabAtkins]
fantasai: On that note, think we need some bikeshedding on this - we use "display" to refer to the physical device
20:53:50 [TabAtkins]
fantasai: so like display-width vs width
20:54:00 [TabAtkins]
fantasai: and we want consisten wording between env() and MQ
20:54:23 [TabAtkins]
TabAtkins: note the MQ word is 'device-', not 'display-'
20:54:34 [TabAtkins]
fantasai: Oh yeah. But the env() is using viewport, so we should be consistent between them
20:54:41 [Rossen_]
q?
20:55:08 [TabAtkins]
Rossen_: So any preferences or opinions?
20:55:19 [TabAtkins]
TabAtkins: No strong opinion on word, but strong opinion towards naming consistency like elika said
20:55:24 [astearns]
device-arrangement
20:55:35 [TabAtkins]
florian: 'viewport' isn't great, it's how your viewport spans
20:55:51 [TabAtkins]
heycam: perhaps something about presentation
20:55:59 [TabAtkins]
fantasai: if you ahve a normal display it'll ahve a value of 1
20:56:00 [dauwhe]
dauwhe has joined #css
20:57:18 [TabAtkins]
heycam: so i think like 'display-span-x' will sound like it should match if your single window spans across both segments even if it's just acting like a normal window
20:57:28 [fantasai]
i/heycam/TabAtkins: If your window spans a folded device, is that span 2 or span 1?
20:57:48 [TabAtkins]
florian: if you're on a device with a seam between screens, then eys absolutely
20:57:50 [dholbert]
present-
20:58:03 [TabAtkins]
florian: But on a device with a seamless pane separation, up to the UA to decide which way it goes
20:58:34 [TabAtkins]
dlibby_: valid point, goes down to what cam was mentioning - if you're in more of a tiled mode that the device is informing the UA about
20:58:49 [TabAtkins]
dlibby_: So possibility of a seamless device not presenting itself as multipane if you're not doing something
20:58:58 [TabAtkins]
smfr: some implication of spanning the whole utility area
20:59:18 [TabAtkins]
smfr: if you span both screens, but half of one screen is filled with a different app, your browser is 1.5 screens wide
20:59:36 [TabAtkins]
smfr: So without information about what size each pane is...
20:59:45 [TabAtkins]
TabAtkins: That's what the env() is for, reporting those pane sizes
21:00:12 [TabAtkins]
Rossen_: So yeah in your example, the shared pane will just have a smaller viewport for the browser in that pane
21:00:30 [TabAtkins]
florian: so my suggestion is to resolve to adopt it, bikeshed naming in github
21:00:43 [TabAtkins]
florian: But i think we're agreeing to the proposal overall, maybe need a few details to be clearer
21:00:47 [TabAtkins]
florian: But not hearing real pushback
21:00:56 [Rossen_]
q?
21:01:01 [myles]
q+
21:01:04 [Rossen_]
ack fantasai
21:01:04 [Zakim]
fantasai, you wanted to comment on querying the gap
21:01:06 [TabAtkins]
fantasai: agree with florian
21:01:30 [TabAtkins]
fantasai: also might be useful to query info about the gap, how big it is and if there's content missing in the gap - if it doesn't paint or if it just jumps across
21:01:49 [TabAtkins]
dlibby_: The env variables are designed let you avoid the gap, but perhaps there's a query to make it clearer up front
21:01:58 [TabAtkins]
myles: are the env() indexed?
21:02:05 [TabAtkins]
dlibby_: discussed that a bit yesterday, yes they are
21:02:29 [TabAtkins]
dlibby_: based on discussion, should match the 2d grid indexing
21:02:38 [fantasai]
The question of whether working on the "explode" model or the "window" model is probably relevant - http://fantasai.inkedblade.net/style/discuss/table-backgrounds/
21:02:49 [TabAtkins]
Rossen_: So any objections to adopting them into MQ5?
21:03:05 [TabAtkins]
RESOLVED: Adopt the multiscreen MQs into MQ5.
21:03:12 [TabAtkins]
<br until=":15">
21:12:36 [astearns]
topic: end
21:14:27 [fantasai]
[side conversations about mixing environment variables and media features in comparisons as media queries]
21:17:11 [fantasai]
[side conversation about breakout rooms]
21:17:34 [fantasai]
[and trying to replicate hallway conversations virtually]
21:18:46 [fantasai]
Topic: Contain
21:19:55 [faceless2]
present-
21:19:56 [fantasai]
Topic: content-visibility: hidden-matchable
21:20:03 [fantasai]
https://github.com/w3c/csswg-drafts/issues/5595
21:20:20 [fantasai]
jarhar: Hi I'm Joey. I'm working on content-visibility: hiddne-matchable
21:20:25 [fantasai]
jarhar: in parallel with HTML feature called ??
21:20:37 [fantasai]
jarhar: A lot of websites have sections, like wikipedia
21:20:40 [heycam]
s/??/beforematch/
21:20:47 [fantasai]
jarhar: and find-in-page doesn't work because it's 'display: none'
21:21:00 [fantasai]
jarhar: When searching for these things, want these things to be findable
21:21:17 [fantasai]
jarhar: so you would send 'content-visiblity: hidden-matchable' which is same as 'content-visibility: hidden'
21:21:25 [fantasai]
jarhar: that'll find the element and fire ??
21:21:34 [fantasai]
jarhar: and page has ability to change the style to reveal the content
21:21:40 [cbiesinger]
s/??/the beforematch event/
21:21:42 [fantasai]
jarhar: and after one RequestAnimationFrame
21:21:45 [fantasai]
jarhar: browser will scroll to it
21:21:46 [florian]
s/??/before match/
21:21:51 [fantasai]
jarhar: and that's pretty much thie ideal
21:21:55 [emilio]
q+
21:21:56 [fremy]
this is a wonderful proposal
21:22:01 [myles]
q-
21:22:01 [fantasai]
s/thie ideal/the idea/
21:22:11 [astearns]
ack fantasai
21:22:24 [florian]
fantasai: I'm curious, in a lot of cases, it seems it should just work
21:22:43 [florian]
fantasai: in the case of a details element, it should just pop open
21:23:02 [florian]
fantasai: I'm a little confused as to why we wouldn't want this to happen as well
21:23:13 [fantasai]
jarhar: Agree supporting content in details element
21:23:17 [fantasai]
jarhar: but separate from CSS property
21:23:33 [fantasai]
jarhar: for DETAILS could just say browser can change the state of DETAILS automatically
21:23:39 [fantasai]
jarhar: but other case don't use DETAILS element, those use display: none
21:23:45 [fantasai]
jarhar: so providing a different way
21:23:47 [smfr]
q+
21:23:56 [fantasai]
jarhar: also CSS state is maintained by page, page has opportunity to change itself
21:24:26 [fantasai]
jarhar: 2nd question?
21:24:28 [TabAtkins]
q+
21:24:30 [bkardell_]
q+
21:24:37 [fantasai]
fantasai: why wouldn't this be the default behavior for 'content-visbility: hidden'
21:24:54 [fantasai]
jarhar: could maybe, but some concern around privacy mitigations
21:24:59 [fantasai]
jarhar: if we fired on hidden content
21:25:16 [fantasai]
jarhar: page, after it gets an event, the page is required to reveal the content or else we lock the page out of using beforematch
21:25:34 [fantasai]
jarhar: we want to prevent the page from trying to figure out what the user is searching for
21:25:42 [fantasai]
jarhar: and hidden-beforematch is what we're using to determine state
21:25:55 [bkardell_]
actually I will just say most of the time that is probably not actually what you want and if you need me to clarify why I can readd to the queue
21:25:56 [fantasai]
jarhar: a lot of pages using 'content-visilibity: hidden' already, and would create lockout, so not great
21:25:57 [bkardell_]
q--
21:26:07 [fantasai]
jarhar: so that's why
21:26:08 [astearns]
ack emilio
21:26:20 [bkardell_]
q-
21:26:23 [fantasai]
emilio: Find-in-page already changes the selection of the document, and that's observable now
21:26:31 [fantasai]
emilio: so how useful is this mitigation
21:26:41 [fantasai]
jarhar: There are other ways to observe find-in-page
21:26:43 [TabAtkins]
So the answer to "why not give 'hidden' this behavior, and then add another value that has the current unmatchable behavior" is "there's already some legacy content that we'd prefer not to break if not necessary"
21:26:47 [fantasai]
jarhar: e.g. by listening to scroll events
21:27:03 [fantasai]
jarhar: in Firefox as you type it fires selection events
21:27:06 [fantasai]
jarhar: makes it easy to detec
21:27:11 [fantasai]
jarhar: in Chromium not the same
21:27:22 [fantasai]
jarhar: the selection is only fired when user dismisses find-in-page dialog
21:27:30 [vmpstr]
q+
21:27:37 [fantasai]
jarhar: so from Firefox point of view, makes sense not to have extra mitigation, but from our side it's needed
21:27:48 [dauwhe]
dauwhe has joined #css
21:27:53 [fantasai]
emilio: Other question is, this makes find-in-page effectively asynchronous, which is not something that happens
21:28:01 [fantasai]
emilio: how does window.find() work and similar things?
21:28:07 [fantasai]
emilio: and why does this have to be a CSS property at all?
21:28:18 [fantasai]
emilio: I think if you find text in a 'display: none' subtree, and if page reacts to it
21:28:21 [fantasai]
emilio: find again or something
21:28:23 [fantasai]
emilio: idk
21:28:33 [fantasai]
jarhar: for async part, it's true, the whole flow is async
21:28:51 [fantasai]
jarhar: first we find the match, then wait for next animation frame, then ?, then wait for next frame, then see if it was revealed
21:28:58 [fantasai]
jarhar: that was seen to be necessary ...j
21:29:10 [fantasai]
jarhar: based on page, which wasn't handling the style change synchronously
21:29:18 [fantasai]
jarhar: but for normal find-in-page use case, whene not 'hidden-matchable'
21:29:21 [fantasai]
jarhar: still keeping it synchronous
21:29:29 [fantasai]
jarhar: not really sure if we'll fire beforematch or window.find
21:29:32 [fantasai]
jarhar: at this point
21:29:50 [fantasai]
jarhar: only motivation for me is to make easier to test across platform, but not aware of any use cases for window.find where you need to search hidden content
21:29:53 [astearns]
ack smfr
21:30:07 [fantasai]
smfr: ...
21:30:09 [fantasai]
smfr: you select into it
21:30:14 [fantasai]
smfr: and then you have to realize all the content
21:30:21 [dholbert]
dholbert has joined #css
21:30:27 [fantasai]
smfr: seems like what you're proposing would bring in content during find, incremental improvement
21:30:30 [astearns]
s/.../from what I remember about content-visibility/
21:30:34 [fantasai]
smfr: but wouldn't select content
21:30:40 [fantasai]
smfr: previously if user did select-all on the document
21:30:47 [melanierichards]
present+
21:30:55 [fantasai]
smfr: because of selection, would realize content for invisible stuff, woudl be slow (?)
21:31:00 [fantasai]
smfr: but find would work in a reasonable way
21:31:03 [Rossen_]
Rossen_ has joined #css
21:31:04 [fantasai]
smfr: with this new thing
21:31:09 [fantasai]
smfr: but why is find special?
21:31:15 [fantasai]
smfr: what about scroll to text?
21:31:20 [fantasai]
smfr: what about seach for addresses, metadata
21:31:23 [fantasai]
smfr: #target
21:31:33 [fantasai]
smfr: ...
21:31:36 [fantasai]
smfr: Why only find?
21:31:47 [fantasai]
jarhar: started with find, could expand to other use cases
21:32:04 [fantasai]
levin: I think auto already supports all these things
21:32:18 [fantasai]
levin: this is adjustment to 'hidden', which is not available to find-in-page
21:32:20 [astearns]
ack TabAtkins
21:32:37 [fantasai]
TabAtkins: You mentioned how a page doesn't respond to the format event by revealing something, we'll remove their ability to do it
21:32:45 [fantasai]
TabAtkins: does that mean we automatically turn the thing visible, or what?
21:32:55 [fantasai]
jarhar: We stop firing the beforematch event
21:32:58 [fantasai]
jarhar: it's invisible
21:33:10 [fantasai]
TabAtkins: so the whole page is broken, not just one aspect of the use
21:33:26 [fantasai]
jarhar: Usually there's some other way to reveal content in the page, just find-in-page would be broken
21:33:45 [fantasai]
TabAtkins: Before you'd walk up and try to find something auto that could fail open rather than failing closed
21:33:57 [fantasai]
myles: So if you catch an event and do nothing, different from not catching the event??
21:34:11 [fantasai]
florian: I don't think anyone said that
21:34:20 [fantasai]
florian: question is if you don't respond to event, do you stay hidden or get auto-revealed
21:34:26 [fantasai]
TabAtkins: Default being to reveal
21:34:36 [fantasai]
TabAtkins: if you're responding on your own, would do CancelDefault
21:34:44 [fantasai]
jarhar: There's no way to possibly have the browser build the content
21:34:52 [fantasai]
jarhar: page is in control of the style, same as 'hidden'
21:34:52 [TabAtkins]
s/CancelDefault/preventDefault()/
21:35:08 [fantasai]
jarhar: CSS property says this is hidden, and until the page reveals, it should stay hidden
21:35:21 [fantasai]
jarhar: There's internal state in the thing, and when you search for it, it would unlock similar to 'auto'
21:35:31 [fantasai]
jarhar: but direction we're going, page maintains state, and it has to remove the CSS property
21:35:36 [fantasai]
TabAtkins: I would like to have more discussion about that
21:35:46 [fantasai]
TabAtkins: feels backwards for bad pages
21:35:48 [fantasai]
TabAtkins: broken JS
21:35:51 [astearns]
ack vmpstr
21:36:00 [fantasai]
levin: Use cases we're targetting here are things like wikipedia collapsed sections
21:36:08 [fantasai]
levin: where there are already handlers that expand the content
21:36:20 [fantasai]
levin: this would add that find-in-page can expand the content
21:36:35 [fantasai]
levin: if there's an error
21:36:57 [fantasai]
levin: It prevents pages from figuring out what character is type by incrementally constructing a DOM but never revealing that content
21:37:06 [fantasai]
levin: somewhat possible now with scroll offsets, but they're visible always
21:37:16 [fantasai]
levin: Content you're searching is visible
21:37:27 [fantasai]
levin: would allow you to search content, and remains visible
21:37:34 [vmpstr]
S/levin/vmpstr/
21:37:39 [fantasai]
TabAtkins: Framing of strict improvement over 'hidden' makes me a little happier
21:37:48 [fantasai]
TabAtkins: but think there should be some discussion about whether that's the right way to go
21:37:52 [TabAtkins]
s/'hidden'/'display:none'/
21:37:59 [fantasai]
+1 to Tab's concern
21:38:06 [fantasai]
and to smfr's
21:38:21 [fantasai]
astearns: Hearing some concerns around what happens when events break
21:38:25 [fantasai]
astearns: ..
21:38:49 [fantasai]
astearns: Wonder if we should take this back to the issue and get more of the proposal fleshed out, and answer questions, then bring back on a regular call
21:38:55 [fantasai]
astearns: Any other discussion?
21:39:13 [fantasai]
fantasai: Just +1 to TabAtkins and smfr's questions and conerns
21:39:23 [fantasai]
Topic: contain: size and aspect-ratio
21:39:29 [TabAtkins]
github: https://github.com/w3c/csswg-drafts/issues/5585
21:39:40 [fantasai]
florian: I think this was oversight in the original specification
21:39:58 [fantasai]
florian: contain:size suppresses intrinsic size, mentions width/height, but forgot to state that it also suppresses intrinsic aspect ratio
21:40:04 [fantasai]
florian: So should say so
21:40:10 [fantasai]
florian: Note this is not about the explicit 'aspect-ratio' property
21:40:14 [fantasai]
florian: but about the intrinsic one
21:40:16 [fremy]
lgtm
21:40:22 [fantasai]
lgtm
21:40:29 [fantasai]
TabAtkins: seems obvious, but this is a REC so need WG approval
21:40:40 [dlibby_]
q+
21:40:55 [fantasai]
astearns: proposed that contain:size suppresses intrinsic aspect ratio
21:40:58 [astearns]
ack dlibby_
21:41:10 [fantasai]
dlibby_: Would it be possible that 0/0 gives us the right behavior for this aspect ratio?
21:41:18 [fantasai]
TabAtkins: what do you mean by both zero?
21:41:52 [fantasai]
fantasai: having an aspect ratio vs having an infinite aspect ratio is different
21:42:10 [fantasai]
florian: We're not doing 0/0, we're doing "no aspect ratio"
21:42:21 [fantasai]
cbiesinger: what if we have 'auto' in the aspect ratio in the property?
21:42:38 [fantasai]
TabAtkins: you wouldn't ignore auto, but you would look up intrinsic aspect ratio and see that you have none
21:42:40 [florian]
q?
21:43:14 [fantasai]
RESOLVED: contain:size suppresses intrinsic aspect ratio
21:43:26 [TabAtkins]
fantasai: We get to the be the guinia pigs for modifying a Rec
21:43:41 [TabAtkins]
fantasai: Do we want to reoslve publishing an updated Rec that contains a candidate change?
21:43:49 [TabAtkins]
chris: Doesn't it have to be published under a particular license?
21:43:56 [TabAtkins]
fantasai: Only if you're adding new features, not fixing errors
21:44:10 [TabAtkins]
florian: there is another change we're likely to do to the same level of this spec
21:44:18 [TabAtkins]
florian: *after that*, sure, but let's resolve just once
21:44:35 [fantasai]
TabAtkins: so no publication yet, but soon. happy to guinea pig
21:44:46 [fantasai]
florian: another change in terminology is proposed
21:45:06 [fantasai]
florian: and another one about the definition of contain:size being phrased sufficiently vaguely that mats didn't disagree with what we were trying to do , but wasn't sure what we were trying to do
21:45:16 [fantasai]
florian: and we found some potential things we might want to change about how it affects grid tracks
21:45:21 [fantasai]
florian: not on agenda today, but can discuss later
21:45:42 [fantasai]
Topic: computed value of shortcuts
21:45:56 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/5511
21:46:02 [fantasai]
TabAtkins: not clear how serialization should work in certain cases
21:46:09 [fantasai]
TabAtkins: the 'content' value is equivalent to 'layout paint'
21:46:19 [fantasai]
TabAtkins: should it serialize as 'content' or 'layout paint'?
21:46:29 [fantasai]
TabAtkins: some differences between browsers
21:46:38 [fantasai]
TabAtkins: if we specify shortest serialization principle to use shorthand when possible
21:46:50 [fantasai]
TabAtkins: that assumes we'll always have a strict hierarchy of shorthand variables
21:46:58 [fantasai]
TabAtkins: if partial overlap, might have multiple shortest-possible serializations
21:47:07 [fantasai]
TabAtkins: I think we can spec our way out of that if needed
21:47:19 [fantasai]
TabAtkins: Right now, means that the exact value is used
21:47:24 [fantasai]
TabAtkins: essentially make ..
21:47:33 [fantasai]
TabAtkins: and then go through and use shortest serialization
21:47:46 [fantasai]
TabAtkins: so I propose that we serialize the 'contain' property using shortest serialization
21:47:53 [fantasai]
TabAtkins: and use shorter values rather than how written
21:48:29 [heycam]
fantasai: worth distinguishing between specified and computed values
21:48:51 [fantasai]
fantasai: if talking about computed values, then just say that 'content' computes to 'layout paint' and it'll serialize appropriately per rules
21:49:04 [fantasai]
fantasai: if talking about specified values, need to be explicit
21:49:24 [fantasai]
oriol: Generally, specified values keep keyword as specified, just normalize the order
21:49:27 [fantasai]
florian: Doesn't that fall out?
21:49:46 [emilio]
q+
21:49:48 [fantasai]
TabAtkins: Then it sorts in a particular order
21:49:56 [astearns]
ack fantasai
21:50:01 [heycam]
fantasai: canonical ordering in our propdef tables
21:50:13 [heycam]
fantasai: it'll look at how you've defined the grammar, and serialize based on that order
21:50:20 [fantasai]
fantasai: unless you define differently
21:50:27 [fantasai]
TabAtkins: I think we need more detail in CSSOM to be clear
21:50:45 [fantasai]
TabAtkins: about computed value, sounds like we can just resolve on doing the normal thing and then write tests
21:50:59 [fantasai]
florian: don't we need to say that the "compute to" each other?
21:51:06 [fantasai]
florian: otherwise they're similar but different values
21:51:11 [astearns]
ack emilio
21:51:17 [fantasai]
emilio: behavior in Firefox is because we only partially implement some of contain
21:51:27 [fantasai]
emilio: but generally, we should serialize the same, the computed and specified values
21:51:43 [fantasai]
emilio: I don't see why they should be different. Most properties behave like that if there's no conversion
21:51:51 [fantasai]
TabAtkins: I would prefer avoiding specified value conversion here
21:52:02 [fantasai]
TabAtkins: so let's leave that off to the side, leave it for computed value serialization
21:52:14 [fantasai]
TabAtkins: so I'm find to say that shorthand values compute to appropriate longhands and that falls out
21:52:38 [fantasai]
astearns: So proposed resolution is that values are ...?
21:52:50 [fantasai]
fantasai: You say the shorthand computes to the longhand, and it'll serialize as the short one
21:53:20 [fantasai]
RESOLVED: contain keywords representing a combination of other keywords are defined to compute to those keywords so that they serialize under shortest-serialization princple
21:53:38 [fantasai]
Topic: combination of shorthand and longhand values
21:53:39 [TabAtkins]
github: https://github.com/w3c/csswg-drafts/issues/5506
21:53:56 [fantasai]
TabAtkins: I wrote in an example in the spec 'contain: strict style'
21:54:00 [fantasai]
TabAtkins: because strict doesn't include style
21:54:04 [fantasai]
TabAtkins: turns out that this is not grammatical
21:54:16 [fantasai]
TabAtkins: you can't mix the shorthands with additional longhands
21:54:23 [fantasai]
TabAtkins: question is... should it be?
21:54:32 [fantasai]
TabAtkins: especially if the shorthand computes to longhand, shouldn't we allow combining them
21:54:56 [fantasai]
TabAtkins: if we do that, then how strict do we want to be about the combinations, do we allow 'strict paint' even though 'paint' is already included in 'strict'
21:54:56 [florian]
q+
21:55:08 [myles]
q+
21:55:22 [fantasai]
TabAtkins: Weakly prefer allowing more combos, but browsers only accept the stricter syntax
21:55:34 [fantasai]
florian: Weak preference
21:55:36 [astearns]
ack florian
21:55:47 [fantasai]
florian: my weak preference goes the other way around because it's stable.
21:56:00 [astearns]
ack myles
21:56:01 [fantasai]
florian: If from scratch, would allow the non-redundant combinations, but minor enough not worth fixing
21:56:07 [fantasai]
myles: Similar to what Florian just said.
21:56:19 [fantasai]
myles: Also, as far as you know, are you the only person who has this desire?
21:56:23 [fantasai]
TabAtkins: No idea
21:56:26 [fantasai]
myles: So probably, no change
21:56:40 [fantasai]
astearns: until browsers get bugs from ppl other than Tab :)
21:56:43 [fantasai]
astearns: proposed no change
21:56:43 [fantasai]
+1
21:56:47 [fantasai]
astearns: any objections?
21:56:50 [fantasai]
RESOLVED: close no change
21:57:28 [fantasai]
Topic: Terminology Question for css-contain
21:57:36 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/5590
21:57:59 [fantasai]
florian: Spun out from bigger discussion, and mats_ pointed out we used the term 'containing box' to talk about the principal box of element to which containment is being applied
21:58:10 [fantasai]
florian: 'containign box' sounds a lot like 'containing block'
21:58:19 [fantasai]
florian: he proposes 'containers box', I don't love that either
21:58:31 [fantasai]
florian: but 'contaiment box' maybe helps?
21:58:41 [fantasai]
florian: help avoid confusion with 'containing block'
21:58:45 [fantasai]
florian: purely editorial
21:59:00 [fantasai]
+1 to changing
21:59:01 [TabAtkins]
q+
21:59:10 [fantasai]
florian: Used half a dozen times in this spec, not really in other specs (yet)
21:59:10 [heycam]
+1 to "containment box"
21:59:16 [fantasai]
TabAtkins: +1 to changing
21:59:22 [astearns]
ack TabAtkins
21:59:24 [fantasai]
TabAtkins: "containing" is used too much across CSS
21:59:36 [fantasai]
TabAtkins: "containment box" sounds great, directly ties into concept, and slightly more distinct
21:59:47 [fantasai]
RESOLVED: Change term "containing box" to "containment box"
21:59:58 [fantasai]
Topic: Sizing 4
22:00:03 [fantasai]
Topic: Break
22:00:18 [tantek]
tantek has joined #css
22:00:36 [fantasai]
Topic: contain:size and 'aspect-ratio'
22:00:40 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/5550
22:00:45 [tantek]
present+
22:01:25 [fantasai]
TYLin: Issue is replaced elements with intrinsic aspect ratio
22:01:35 [fantasai]
TYLin: Specify contain:size and aspect-ratio, what size should it be?
22:01:50 [fantasai]
TYLin: Discussion in the issue, should use expliti 'aspect-ratio' and otherwise none
22:01:54 [florian]
q?
22:02:18 [fantasai]
florian: My impression is that spec was confusing because we didn't say anything at all, but if we clarify as we did in the earlier issue, do we need to say anything else to make this work?
22:02:30 [fantasai]
TabAtkins: It does fall out, but might be worth an example
22:02:43 [fantasai]
fantasai: I think it falls out
22:02:50 [fantasai]
TYLin: added testcase
22:02:57 [fantasai]
astearns: so proposal is to add an example
22:03:03 [fantasai]
astearns: any objections?
22:03:10 [fantasai]
RESOLVED: Add an exampe, but no change to normative prose
22:03:17 [fantasai]
Topic: Break
22:03:24 [fantasai]
<br end=':15'>
22:03:26 [tantek]
s/exampe/example
22:04:49 [fantasai]
RESOLVED: Add dlibby as editor to MQ5
22:05:14 [fantasai]
dlibby_, https://lists.w3.org/Archives/Public/spec-prod/2018OctDec/0011.html
22:12:43 [gregwhitworth]
https://w3cmemes.tumblr.com/image/144115766537
22:13:33 [Rossen_]
q?
22:13:58 [florian]
https://w3cmemes.tumblr.com/post/178519961772
22:16:52 [tantek]
scribenick: tantek
22:17:07 [tantek]
astearns: we added Daniel as an editor to MQ spec
22:17:23 [tantek]
... more editor positions are available on specs as well!
22:17:38 [tantek]
... if you've been opening issues on specs, and have some suggested solutions, we can use the help.
22:17:51 [tantek]
... let astearns know on IRC or email if you'd like to take him up on the offer
22:18:14 [chris]
florian looks frozen tbh
22:18:20 [tantek]
chair: Rossen_
22:18:27 [tantek]
issue: 4585
22:18:43 [fantasai]
Topic: Sizing
22:18:50 [Rossen_]
github:https://github.com/w3c/csswg-drafts/issues/4585
22:19:07 [fantasai]
https://github.com/w3c/csswg-drafts/issues/4585#issuecomment-701595999
22:19:07 [tantek]
Rossen_: who wants to summarize?
22:19:32 [tantek]
fantasai: we created this issue to collect use-cases for the control over use-cases over intrinsic sizes of boxes
22:19:37 [tantek]
... we have 3 maybe 4
22:19:42 [tantek]
... one is webkit like behavior
22:19:54 [tantek]
... another is zeroing out the ... of scrolling containers
22:20:10 [cbiesinger]
s/.../min-content contribution/
22:20:19 [dauwhe]
dauwhe has joined #css
22:20:30 [tantek]
... another one is zeroing out the max content contribution when there is a zero size or max size in that axis
22:20:35 [dholbert]
dholbert has joined #css
22:20:41 [cbiesinger]
s/max content/min content/
22:21:02 [tantek]
... someone wanted to have a box that had the same behavior as a replaced element
22:21:09 [tantek]
... they were able to replicate a lot with our aspect ratio stuff
22:21:20 [tantek]
... but this is a quirk of how replaced elements behave
22:21:33 [Rossen_]
q
22:21:41 [tantek]
fantasai: q to wg, do we want to design a property to switch between these different values?
22:21:52 [tantek]
... q2 to wg, are there are other cases we should add to this
22:22:03 [tantek]
Rossen_: opinions?
22:22:15 [fantasai]
s/behave/behave that's unrelated to aspect ratios/
22:22:16 [tantek]
(awkward silence)
22:22:41 [tantek]
Rossen_: do we care enough about this? or we can also move on if there is not enough interest here
22:22:56 [tantek]
... there was interest here. in terms of behavior what do we want?
22:23:08 [tantek]
... dbaron also dumped a bunch of mozilla bugs that were a good indicator that we need to look into solving this
22:23:25 [tantek]
... i don't see anyone on the queue or engaging
22:23:32 [tantek]
... shall we close the issue with no change?
22:23:40 [tantek]
cbiesinger: i would really like to have this property
22:24:07 [tantek]
... the second part was requested by me because I know some people who want to use this on their websites
22:24:17 [tantek]
... to set the min content to zero to act like replaced elements
22:24:32 [tantek]
... seems like useful behavior to get the regular size normally but when you shrink the window you can shrink the element with it
22:24:37 [tantek]
... that's my case for it
22:25:09 [tantek]
fantasai: proposed resolution: define a property to switch between these behaviors and hope someone comes up with sensible keywords
22:25:16 [tantek]
Rossen_: better than the ones currently in the issue
22:25:22 [tantek]
jensimmons: I also think this is a really good idea
22:25:59 [tantek]
... I can see... it's sort of an advanced feature ... authors need to wrap their heads around sizing period. it requires understanding how layout works first.
22:26:35 [tantek]
... to me the big use-case is you have multiple grid items in a grid track, and the track itself is going to be based on something in the track, and you can say don't base it on the headline, base it on something else
22:26:44 [tantek]
... you set its intrinsic size to 0 or 100px
22:26:49 [tantek]
... that could be very powerful
22:27:01 [tantek]
... the columns will be the size of the content in it, except not this content or this content
22:27:15 [tantek]
Rossen_: thank you. other opinions or objections to adopting such a property. name and value names tbd
22:27:25 [tantek]
... i see some nodding of heads
22:27:28 [tantek]
... no objections
22:28:09 [tantek]
Rossen_: RESOLVED: Adopt a property to solve the requested property and values from issue 4585
22:28:22 [Rossen_]
Topic: Why was min-content, etc. redefined to do nothing in the block axis
22:28:27 [fantasai]
A first terrible attempt: intrinsic-size: auto | min-zero-scrollable || min-zero-percentage
22:28:34 [Rossen_]
github: https://github.com/w3c/csswg-drafts/issues/3973
22:28:55 [tantek]
Rossen_: cbiesinger you opened this one
22:29:06 [tantek]
... and you also added it to agenda+
22:29:10 [tantek]
cbiesinger: I did?
22:29:12 [tantek]
Rossen_: on Jan 22
22:29:19 [tantek]
cbiesinger: oh that was a while ago lol
22:29:38 [fantasai]
s/Rossen_: RESOLVED/RESOLVED/
22:29:54 [tantek]
cbiesinger: why are we discussing today, wasn't it addressed by a recent edit?
22:29:57 [tantek]
TabAtkins: yes it was
22:30:02 [tantek]
... making sure others are ok with the edit
22:30:05 [tantek]
cbiesinger: I can summarize
22:30:25 [tantek]
... in the block axis the ..xx.. and fit-content take the same value as auto
22:30:56 [tantek]
Rossen_: sounds reasonable
22:31:07 [tantek]
cbiesinger: it lets you get the min height auto behavior from flexbox and grid
22:31:12 [tantek]
... and ... ratio in other contexts
22:31:15 [fantasai]
at one poin the spec defined min-content/max-content/fit-content to behave the same as 'auto' in the block axis
22:31:24 [tantek]
Rossen_: any other opinions?
22:31:45 [fantasai]
the edits changed that to say that the min-content and max-content sizes in the block axis are as defined by the layout model, defaulting to max-content behavior
22:31:47 [tantek]
... or objections to accepting the edits
22:31:49 [fantasai]
more or less
22:31:56 [tantek]
RESOLVED: accept edits made
22:32:05 [Rossen_]
Topic: Cyclic percentage concept should not exist
22:32:22 [Rossen_]
github: https://github.com/w3c/csswg-drafts/issues/3010
22:32:45 [tantek]
Rossen_: fantasai you added this one
22:32:56 [tantek]
fantasai: this was less of a change in behavior, and more of a change in how it was explained
22:33:04 [tantek]
... determining whether a % is cyclic is itself a bit confusing
22:33:09 [tantek]
... but not all %s are cyclic
22:33:10 [fantasai]
https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
22:33:18 [tantek]
... we tried to draft a clarification ^
22:33:28 [tantek]
... we wanted to know if that would make the spec acceptable
22:33:33 [tantek]
... we're trying to get this spec to CR soonish
22:34:08 [tantek]
Rossen_: ok
22:34:25 [tantek]
... special resolution is defined after this paragraph?
22:34:33 [tantek]
... this clarification is pretty good actually
22:34:39 [tantek]
... any other opinions or feedback?
22:34:49 [tantek]
(silence)
22:34:58 [tantek]
dbaron: the new text looks good to me
22:35:04 [tantek]
fantasai: yay!
22:35:24 [tantek]
Rossen_: hearing no objections
22:35:40 [tantek]
RESOLVED: accept proposed edits in https://github.com/w3c/csswg-drafts/issues/3010#issuecomment-672335319
22:35:53 [Rossen_]
Topic: Distinguish intrinsic size's two definitions with two terms
22:36:03 [Rossen_]
github: https://github.com/w3c/csswg-drafts/issues/4961
22:36:28 [tantek]
fantasai: we've been using intrinsic size to refer to two different concepts
22:36:34 [tantek]
... one is the size of a replacement element
22:36:56 [tantek]
... the other concept is referring to the min-content and max-content sizes, which always exists for any box, they are determined in some manner
22:37:05 [tantek]
... we need two different terms for this
22:37:21 [tantek]
... the HTML spec uses the term natural width and natural height
22:37:36 [florian]
q+
22:37:42 [tantek]
... we were thinking to replace the use of intrinsic size as it applies to the inherit size of a replaced element with natural size
22:37:52 [tantek]
... and keep intrinsic size to mean the other
22:37:57 [Rossen_]
ack florian
22:38:08 [myles]
q+ to ask if this is a behavior change
22:38:10 [heycam]
+1 for aligning terms across specs
22:38:14 [tantek]
florian: with the new dfn, the intrinsic size of a replacement it would be the natural size and 0 otherwise?
22:38:25 [tantek]
fantasai: no it can lack an intrinsic size
22:38:30 [tantek]
florian: I don't understand
22:38:48 [tantek]
fantasai: you have to distinguish between whether you are taking about a min-content and a max-content size
22:38:50 [cbiesinger]
q+
22:39:12 [tantek]
fantasai: when the natural size of something does not exist, there are rules for determining
22:39:21 [heycam]
q+
22:39:25 [Rossen_]
ack myles
22:39:25 [Zakim]
myles, you wanted to ask if this is a behavior change
22:39:27 [tantek]
myles: is this purely a rename or behavior change?
22:39:32 [tantek]
fantasai: purely terminology in the spec
22:39:37 [Rossen_]
ack cbiesinger
22:40:27 [tantek]
cbiesinger: this is only for replacements but, don't you need a terminology for non-replaced elements with an aspect ratio because the regular min and max content size will be affected by the aspect ratio, but you also need a way to refer to the original min and max content size because you need that for width and height auto
22:40:32 [Rossen_]
q?
22:40:35 [tantek]
fantasai: I see what you're talking about, havent' thought about that yet
22:40:40 [cbiesinger]
s/replacements/replaced elements/g
22:40:42 [Rossen_]
ack heycam
22:40:48 [tantek]
heycam: we should check what the HTML spec says
22:40:59 [tantek]
... and I did, and they return 0
22:41:06 [cbiesinger]
s/width and height auto/min-size auto/
22:41:12 [cbiesinger]
tantek: yep!
22:41:17 [Rossen_]
q
22:41:21 [tantek]
... I just want to make sure we don't have any confusion by using the same terms
22:41:32 [tantek]
fantasai: I think the DOM APIs can return 0 when there is no natural size
22:41:47 [tantek]
TabAtkins: do the DOM APIs refer to it any other way other than the camelcased form?
22:41:57 [tantek]
heycam: no it refers to JS properties
22:42:19 [tantek]
florian: this is confusing / not good
22:42:32 [fantasai]
scribenick: fantasai
22:42:44 [fantasai]
fantasai: Their spec is using 'intrinsic size' because that's what our spec uses.
22:42:57 [fantasai]
fantasai: when we update our specs, we'll make sure HTML updates their terms to match als
22:43:07 [fantasai]
Rossen_: Hearing mostly support for having this clear distinction
22:43:20 [fantasai]
Rossen_: Are we leaning towards also accepting the proposed names here, "natural size"?
22:43:29 [heycam]
s/and the return 0/and they return 0 for images that have no natural size/
22:43:36 [florian]
+1
22:43:38 [fantasai]
fantasai: 2 votes in favor from rachelandrew and SimonSapin
22:43:39 [bkardell_]
+1
22:43:49 [fantasai]
Rossen_: I don't see anyone not liking it. Any objections?
22:43:54 [bkardell_]
actually this confused me quite a bit last year
22:44:15 [bkardell_]
I remember having exactly this converation with tab in toronto trying to figure it out
22:44:23 [fantasai]
RESOLVED: Rename temr "intrinsic size" of image with "natural size"
22:44:26 [fantasai]
s/temr/term/
22:44:58 [fantasai]
Rossen_: Seems like everything on Sizing 3
22:45:08 [fantasai]
Rossen_: Alan has an editorial issue to talk about
22:45:17 [fantasai]
Rossen_: With everything we resolved, do we need to republish
22:45:19 [fantasai]
fantasai: yes, and
22:45:50 [fantasai]
fantasai: That closes all the major issues on this spec, so we'd like to issue a last call for comments and start preparing for CR
22:46:18 [fantasai]
astearns: so resolution to publish after all these edits are in?
22:46:29 [fantasai]
RESOLVED: Republish WD of css-sizing-3
22:46:38 [fantasai]
and start CR process after that
22:46:55 [fantasai]
astearns: emilio just volunteered taking on cssom-view at least on the issues he raised
22:47:02 [fantasai]
RESOLVED: Add emilio as editor of cssom-view
22:47:03 [smfr]
thank you emilio!
22:47:12 [myles]
emilio is the best
22:47:17 [Rossen_]
Topic: Break
22:47:18 [myles]
💯
22:47:22 [fantasai]
astearns: Note that emilio also has editorship of cssom, and probably needs help
22:47:46 [Rossen_]
Topic: Clarify on specifying aspect-ratio and contain:size on replaced elements
22:47:54 [tantek]
scribenick: tantek
22:48:17 [tantek]
Rossen_: that's everything for sizing then
22:48:31 [fantasai]
Topic: CSS Logical Properties
22:48:41 [fantasai]
github: https://github.com/w3c/csswg-drafts/issues/3030
22:48:41 [Rossen_]
github: https://github.com/w3c/csswg-drafts/issues/3030
22:49:27 [tantek]
fremy: main issue is that in CSS spec it defines how to serialize properties, contains a lot of tricks to merge declarations
22:49:41 [tantek]
... e.g. if you set all four border properties, the rules merge it to a single declaration
22:49:53 [tantek]
... when I looked at the logical properties, this is not as easy
22:50:08 [tantek]
... even if you have all four, you cannot always merge them into a single property
22:50:25 [tantek]
... it means you have to detect this case (e.g. inline-start) and do something smart
22:51:12 [tantek]
... logical and physical properties
22:51:21 [tantek]
... proposing a couple of rules to the serialization steps
22:51:37 [tantek]
... to only merge all four if they are of the same type
22:51:46 [tantek]
... while we were looking at this, a few more updates
22:51:57 [tantek]
... e.g. dbaron proposed if you set the margin property on the style attribute
22:52:09 [tantek]
... there is no reason to keep the margin-inline properties
22:52:15 [tantek]
... the logical ones
22:52:26 [fantasai]
(because they have all now been overridden)
22:52:27 [tantek]
... proposal: make sure that the grouping would work
22:52:37 [tantek]
... making sure when you set things you override propertly
22:52:40 [emilio]
q+
22:52:43 [tantek]
s/propertly/properly
22:53:03 [tantek]
emilio: Gecko has the concept of logical property groups
22:53:07 [tantek]
... we added it to the spec
22:53:11 [tantek]
... this concept already exists
22:53:27 [tantek]
... e.g. border-inline-start:10px; border-start:20px;
22:53:37 [tantek]
... Gecko will do the right thing
22:53:48 [tantek]
... the concept is already in the spec. this is an obvious bugfix
22:54:08 [tantek]
fremy: the link you sent sounds like exactly what I'm proposing that seems fine
22:54:33 [Rossen_]
See the refs for https://drafts.csswg.org/css-logical-1/#logical-property-group
22:54:49 [tantek]
s/the link you sent/emilio's link https://drafts.csswg.org/css-logical-1/#logical-property-group
22:55:07 [tantek]
fantasai: we should make sure ... interleaved ... then that can be folded into a shorthand
22:55:19 [emilio]
https://drafts.csswg.org/cssom/#set-a-css-declaration is already using this concept
22:55:25 [emilio]
We should use it from serialization
22:55:28 [tantek]
... the other part of your proposal, if a shorthand is set, then you can drop any previous declarations that set any property in that logical property group
22:55:39 [tantek]
fremy: that sounds correct to me
22:55:58 [tantek]
Rossen_: do we not have this currently specified? the part you just added fantasai ? in terms of the behavior?
22:56:16 [tantek]
fantasai: I think in terms of how everything is supposed to behave like cascade, etc. is defined. this is about CSSOM interaction
22:56:23 [tantek]
Rossen_: so this is going into CSSOM then? mostly?
22:56:30 [tantek]
fantasai: I guess so. emilio and I will work it out
22:56:36 [tantek]
Rossen_: any other opinions?
22:56:49 [tantek]
emilio: I need to look a bit more closely at the replace all the physical longhands
22:56:54 [tantek]
... because there are more complex cases
22:57:01 [tantek]
... e.g. shorthands that only override two properties
22:57:11 [tantek]
... like the serialization stuff when stuff is interleaved, that's good
22:57:21 [tantek]
... the replace of the existing physical properties, that may or may not be confusing
22:57:33 [tantek]
fantasai: I think they are two separate proposals that happen to be in the same issue
22:57:39 [tantek]
Rossen_: can you separate them for resolutions?
22:57:53 [fantasai]
First proposal from fremy: During parsing of a css declaration block, shorthands (like margin and all) expands only to the set of longhand (grouped by mapping logic: so either logical or physical) required to describe their value, and by default resort to use physical properties if both sets are possible. Note that they can only expand if they do not contain var() substitutions.
22:58:21 [fantasai]
Second proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.
22:59:01 [tantek]
Rossen_: please read the first one, which is about the behavior specifying, and how declaration blocks behave between shorthands and longhands and logical properties
22:59:07 [tantek]
fantasai: looks like I'm finding more pieces of it
22:59:15 [tantek]
emilio: the first one I assume every browser already does that
22:59:22 [emilio]
s/emilio/fremy
22:59:23 [tantek]
... it's not clear from the spec, but I assume that should work regardless
22:59:32 [fantasai]
Third piece from fremy: When removing a shorthand property, all the longhand associated with that shorthand should be removed, regardless of their mapping kind.
22:59:42 [TabAtkins]
+1, all sound good
22:59:48 [fantasai]
Fourth piece from dbaron: appending a shorthand property could set all of its constituent shorthands of one mapping logic and also remove all of the constituent shorthands of the other.
22:59:56 [tantek]
Rossen_: any objections to accepting this first proposal
23:00:24 [tantek]
emilio: q, we are talking about shorthands that map to both physical and logical properties? but those do not exist in browser today
23:00:38 [tantek]
fremy: it's possible, back them we had proposal for margin, I don't know if we still have that
23:00:46 [tantek]
fantasai: we never figured out a syntax that was appropriate
23:00:52 [tantek]
fremy: that was mostly to make sure that case worked
23:01:02 [tantek]
... I don't think it's wrong to add this even if we don't have the mechanism
23:01:09 [tantek]
emilio: not saying it's wrong, just possibly confusing
23:01:16 [tantek]
how would you test it?
23:01:32 [tantek]
RESOLVED: proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.
23:01:59 [tantek]
fremy: mostly the loop needs to be modified
23:02:20 [tantek]
Rossen_: wanting make sure everyone is comfortable with accepting this change
23:02:32 [emilio]
yeah, +1 for the serialization change, that's unobjectionable imo
23:02:32 [fremy]
https://www.w3.org/TR/cssom-1/#serialize-a-css-declaration-block
23:02:42 [tantek]
... without delaying people too much, any objections or wait til Thu morning?
23:02:46 [tantek]
fremy: for me both is fine
23:05:37 [Rossen_]
RESOLVED: proposal from fremy:During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.
23:05:43 [Rossen_]
Topic: End
23:05:51 [Rossen_]
Zakim, end meeting
23:05:51 [Zakim]
As of this point the attendees have been Rossen_, Morgan, dlibby, astearns, florian, vmpstr, oriol, faceless, alisonmaher, TYLin, bkardell_, heycam, myles, smfr, miriam, fantasai,
23:05:54 [Zakim]
... rego, cbiesinger, plinss, GameMaker, jensimmons, brandonferrua, fremy, kzms, drousso, gregwhitworth, dholbert, chris, melanierichards, tantek
23:05:54 [Zakim]
RRSAgent, please draft minutes
23:05:54 [RRSAgent]
I have made the request to generate https://www.w3.org/2020/10/20-css-minutes.html Zakim
23:05:56 [Zakim]
I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye
23:06:00 [Zakim]
Zakim has left #css
23:08:41 [tantek_]
tantek_ has joined #css
23:20:01 [RRSAgent]
I have made the request to generate https://www.w3.org/2020/10/20-css-minutes.html fantasai