00:03:15 fremy has joined #css 00:03:40 ScribeNick: fantasai 00:03:42 duga has joined #css 00:03:47 Topic: Shared Element Transitions 00:04:05 [JakeA projects slides] 00:04:14 JakeA: Asking to move forward as FPWD 00:04:21 Rossen_ has joined #css 00:04:23 ... did a breakout session yesterday for about 1 hour 00:04:38 JakeA: when you create a page transition between 2 states 00:04:41 nigel has joined #css 00:04:45 ... default transitionis a very quick cross-fade 00:04:50 ... underlying DOM change is just a switch 00:04:51 ... very simple 00:04:58 ... can expand this later to be switch between documents as well 00:05:08 astearns: This has been presented to us before 00:05:11 ... decided to work on it 00:05:22 ... agenda is about FPWD, can we do quickly? 00:05:41 JakeA: We would like to go to FPWD! 00:05:53 ... had feedback on the spec already 00:05:58 ... currently very algorithmic 00:06:10 ... my job is to take a lot of what we have in the explainer, and put into the spec with diagrams and videos 00:06:15 ... I think the spec is in decent shape 00:06:22 .. been strict with ourselves about bits that are missing 00:06:28 ... things like "how do you add a pseudo-tree" 00:06:32 ... DOM spec has terms for this 00:06:46 ... So some to-dos there, but it describes the feature and interaction with event loop 00:06:53 ... enough for FPWD? or anything else to do? 00:06:55 vmpstr has joined #css 00:07:04 fantasai: if there are major issues, mark them in the draft 00:07:11 ... e.g. thoughts on multi-page transitions 00:07:21 ... these are our current thoughts, planning to work on it 00:07:32 JakeA: in the spec? 00:07:39 fantasai: "ISSUE: Description of the issue" 00:07:57 ... good to have them in the spec as they're reading 00:08:07 Rossen_: feedback from the room? 00:08:24 Rossen_: I also hope that you will have more explanation in the spec going forward 00:08:29 JakeA: happy with what's in explainer? 00:08:31 Rossen_: yes 00:08:38 JakeA: so just taking parts of that and weaving into the spec 00:08:39 Rossen_: yes 00:08:46 Rossen_: current state of spec is fairly algorithmic 00:08:53 JakeA: wanted to be ultra-specific about when promises resolve, etc. 00:09:03 ... so current split is that deep implementer details are in the spec, others in explainer 00:09:12 ... feedback I've heard is put explainer into the spec 00:09:23 Rossen_: As authors read spec, need to understand 00:09:36 fantasai: also for implementers, best to understand what they're trying to do 00:09:45 florian: Once explainers have been added, also do horizontal review 00:09:56 ... from internationalization, accessibiliyt, security, privacy 00:10:02 ... you don't want to do that at the end when you're done 00:10:05 ... but engage them early 00:10:12 ... so once the merger with explainer is done, spec is more readable, 00:10:18 ... good time to inform them to ask review 00:10:27 ... For most groups, they have a standard questionnaire to fill out 00:10:33 ... and then they'll look it over 00:10:39 JakeA: continual and early feedback is what we want 00:10:48 Rossen_: Any objections to FPWD? 00:11:01 RESOLVED: FPWD Shared Element Transitions 00:11:05 ACTION: fantasai help publish 00:11:16 Here's a reference to how to ask for Horizontal Review: https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review 00:11:34 Subtopic: Pseudo-element Selectors for shared element transitions 00:11:40 github: https://github.com/w3c/csswg-drafts/issues/7743 00:11:48 JakeA: what you see here is the default cross-fade 00:11:52 ... DOM change underneath is just one change 00:12:01 ... illusion of both bits of content on the screen at the same time is done through this pseudo-element 00:12:05 ... tree 00:12:09 ... These represent the two visual states 00:12:23 ... there's a wrapper around them, which applies isolation 00:12:33 ... and container there is what changes size and position 00:12:40 ... (not seen for root, but for sub-elements will see it) 00:12:52 JakeA: Developers can use these pseudo-elements to customize their stuff 00:13:04 ... e.g. change from cross-fade to sliding images from left to right 00:13:14 ... also have this page-transition-tag property 00:13:21 s/... also/JakeA: also 00:13:37 ... allows to capture page in separate parts, animate separately 00:13:54 ... so page slides and heading text cross-fades 00:14:02 JakeA: This creates a bigger pseudo-tree 00:14:10 ... each piece gets its own ::page-transition-container 00:14:21 ... and underneath it a wrapper around the two incoming/outgoing images 00:14:30 JakeA: Although it's a pseudo-tree, currently attached to root element 00:14:39 ... feels like cheating, because it doesn't really represent the structure of the pseudo-tree 00:14:52 ... but alternative would be [writes out a chain of pseudo-elements] 00:15:12 ... It's uncomfortable even with shortened names 00:15:27 JakeA: Tab came up with idea of using a pseudo-descendant combinator 00:15:51 JakeA: one question to group is, would it be appropriate to do something with function-liek syntax can be used on each piece of it 00:16:00 ... html :>> outgoing-image(header-text) 00:16:10 JakeA: I like this because it makes use of nesting 00:16:15 ... makes syntax simpler and nicer 00:16:32 JakeA: one alternative suggested to structure is what if we used shadow DOM instead 00:16:37 ... here we've got a shadow-root 00:16:51 ... and it's got basically same structure, using parts attribute for access into the tree 00:17:14 emilio: Bigger pro is, you avoid all this nested pseudo-elements for a particular feature 00:17:24 ... also a lot of new features are using shadow parts 00:17:39 ... I don't think of a use case that, well, shadow DOM is already restricted on root eleent 00:17:42 ... so can use it for UA features 00:17:52 ... if you replae with script the HTML element with something else, some of it wouldn't work 00:18:04 ... but all in all, it seems a bit better to re-use what the platform already has 00:18:18 ... I don't think there's anything that you can't do with pseudo-elements that you can't do with parts 00:18:34 JakeA: syntax of using parts, haven't seen for shipped feature yet 00:18:36 ... but we're happy with it? 00:18:42 emilio: THat's where all the new OpenUI stuff is going 00:18:45 ... I think it's reasonable 00:18:57 ... I'd rather do that than having 4 nested pseudo-elements 00:19:18 JakeA: I'd seen that in their proposal, unsure about feelings in this group 00:19:30 emilio: Tab designed parts so that authors and UA could have common mechanism to expose this kind of thing 00:19:41 q+ 00:19:41 TabAtkins: wasn't designed with intent of UA using it, but it was left open as a possibility 00:19:44 q+ 00:19:47 q+ 00:19:55 JakeA: One of the things missing right now is ability drive animations with JS 00:20:02 ... or call things like getBoundingClientRect() on these things 00:20:18 ... and so our plan was, there was a stub bit of spec in the CSS Pseudo-element Spec to say maybe we'll expose these to JS at some point 00:20:28 ... but if we had a shadow root, we could just give devs access to the elements 00:20:30 ... and not do all that 00:20:48 emilio: That seems a bit trickier, in the sense that some of these elements, if I understand correctly, need some magic attached to them 00:20:52 ... rendering a texture that [missed] 00:20:57 ... not supposed to be moved around 00:21:04 ... so seems a bit tricky, fact that you can shuffle them around etc. 00:21:06 s/[missed]/the compositor has taken a snapshot of/ 00:21:24 JakeA: definitely don't want devs to take the elements out of the shadow root and have them continue to work 00:21:31 ... but can explain that if extracted the element, no longer... 00:21:38 emilio: nice thing about shadow parts, is also used elsewhere 00:21:49 q+ 00:21:59 ack heycam 00:22:03 heycam: One thought about shadow root, gievn HTML element can't have one currently 00:22:19 ... could mechanism be that some new element is created which has this shadow tree structure, and placed in top layer 00:22:25 ... not attached to the root element 00:22:29 ... don't know where it would live in the document 00:22:35 JakeA: I floated a similar idea earlier 00:22:39 ... but your idea is simpler 00:22:49 ack khush 00:22:54 khush: I had a thought, curious to get a bit more understanding about heycam was proposing 00:23:05 ... were you proposing a new tag that lives somewhere in the DOM that only exists to host a shadow root? 00:23:18 heycam: thinking that when the element transition is triggered, that would cause a new element to be inserted into the document 00:23:21 ... which has this structure behind it 00:23:32 ... its only purpose is to render the transition image, and it lives in the DOM 00:23:53 khush: idk what computations would run into... would be a shared-element-transition tag? 00:24:07 ... generally does UA create elements that have a temporary lifetime, and is node inserted by browser 00:24:26 ... was trying that we create pseudo-element, but ran into multiple issues because don't expect real DOM elements to have pseudo-elements as their ancestors 00:24:40 heycam: it just feels like it's not really part of the root HTML element either 00:24:47 JakeA: it's a "topper layer" 00:24:57 khush: One reason it has lin kto document is so that it has a way to do style resolution and layout 00:25:02 ... it needs a document to be associated with 00:25:03 q+ 00:25:10 ... otherwise it's using output of actual document to generate content 00:25:25 khush: Wanted to add, might be a weak arguemnt because need to be more clear 00:25:32 ... but one use case is multiple independent transitions on the page 00:25:40 ... currently it's global, works for the whole document, captures the entire page 00:25:47 ... but some cases where a developer can have 2 widgets on their page 00:25:58 ... 2 different DOM subtrees, would be nice to transitions on those subtrees independently 00:26:04 ... if shadow tree, can scope to each subtree 00:26:16 ... attach to root of that subtree 00:26:26 ... so using shadow DOM on the root for this 00:26:32 ... would not be able to do that on subtrees 00:26:37 ack chrishtr 00:26:37 ... because only HTML can have this work 00:26:41 s/HTML/HTML element/ 00:26:51 ... but using pseudo-elements, can expand in that direction 00:26:59 chrishtr: Question is what can authors use to style these elements 00:27:05 ... one is using pseudo-element syntax 00:27:10 ... or use shadow DOM syntax 00:27:17 ... not necessary to ??? 00:27:33 chrishtr: so that's the choice: is there a pseudo-element or not, and if not it's implementation detail 00:27:38 ... maybe something exposed to devs in the future 00:27:38 smfr has joined #css 00:27:46 ... need to think about what choice we make, how it impacts that 00:27:50 ... but it's really choice of syntax A or B 00:28:03 ... and 2 dimensions to weigh are, which has better ergonomics for devs 00:28:11 ... and which is easier to implement for implementers 00:28:23 emilio: My concern was not so much about difficult, but pseudo-elements, there are a lot of them 00:28:27 ... new names specific to this feature 00:28:31 ... to me feels we should avoid it 00:28:52 chrishtr: by analogy, components in OpenUI have a parts syntax on them, but doesn't mean can access the elements. Closed shadow DOM 00:28:56 ... web-components-like syntax 00:28:59 q+ 00:29:06 ... afaict, some devs are used to pseudo-elements 00:29:14 ... find the one they need and put it in their stylesheet 00:29:25 ... others that know about components might think ::parts one makes more sense 00:29:31 ... Further down can explain with conceptual shadow DOM 00:29:36 ... but to me it's really about that tradeoff 00:29:40 ... even if we expose shadow DOM 00:29:42 q+ 00:29:46 ... there are UA features that are [missed] 00:29:51 ... I think you mentioned as an example 00:29:53 ack emilio 00:29:59 emilio: To that regard, my point for using parts is 00:30:04 ... if you need to learn one of these things 00:30:16 ... shadow parts is something you'll learn once, and it'll be useful every time you use it 00:30:22 ... whether as an author or something else 00:30:34 chrishtr: The concept of parts yes, but still have to memorize the names of the parts 00:30:49 chrishtr: I personally don't have a strong opinion 00:30:58 ... I feel like the tradeoff should be more about which is easiest for developers 00:31:09 khush: Part which has not been clear to me, whether syntax implies shadow DOM or not 00:31:24 ... if we go with part syntax, is it still pseudo-elements? 00:31:31 ... wasn't clear if this syntax forces us to use a particular approach 00:31:43 ack miriam 00:31:44 miriam: As an author, I've interacted with pseudo-elements more 00:31:52 ... but when I read the syntax here, the part syntax reads much simpler to me 00:32:02 ... it is a pseudo-element, and doesn't require special combinator syntax 00:32:08 ... looks cleaner to me, makes sense, I like it 00:32:09 +1 to miriam 00:32:09 q+ 00:32:18 ... I am also one of the ppl who will feel strongly about having multiple sub 00:32:27 ... don't want to take an approach that makes that impossible 00:32:29 s/sub/subtree 00:32:36 q+ 00:32:42 chrishtr: important your point that we don't need additoinal syntax for pseudo-element trees 00:32:48 JakeA: if we use the part syntax, you will not get nesting 00:32:51 miriam: will I need it? 00:33:09 fantasai: You had that proposal about nesting 00:33:16 JakeA: could maybe put more classes in the part 00:33:22 ... but you lose the strucutre this gets you 00:33:36 ack heycam 00:33:40 would the part syntax also prevent attaching this structure to an element that has a shadow dom (since part would select the shadow dom?) 00:33:49 heycam: proposal is for transitions in the document, but idea is to go later to entire document transitions? 00:33:58 JakeA: other way around, right now it's one transition that covers the whole document 00:34:03 ... but it's same document transition 00:34:08 smfr has joined #css 00:34:10 ... but intention is to go to cross-document transitions in the near future 00:34:19 heycam: for cross-document, seems like the shadow DOM mechanism wouldn't be appropraite 00:34:25 ... because they would go away when you switch documents 00:34:30 ... so can't describe the state across the transition 00:34:37 JakeA: it would be the same tree that we would use with pseudo-elements 00:34:46 ... screenshots from previous page would be in the shadow DOM of the new document 00:34:57 chrishtr: would certainly require special code 00:35:01 JakeA: would only be same-origin, btw 00:35:10 heycam: all the pseudo-elements, need to live in both old and new document 00:35:13 JakeA: only new one 00:35:22 fremy: you take a photo of old document, and then swithc to new one 00:35:25 ... only one document active 00:35:34 heycam: so in old document, no pseudos get created 00:35:35 fremy: right 00:35:45 chrishtr: but during animation, new document is inert 00:35:53 ack JakeA 00:36:11 JakeA: One thing I'm worried about is, we want devs to have references to things they can call getBoundingClientREct, to control inline styles 00:36:20 ... to increase the proposal for a reference to a pseudo-element and put these on them 00:36:25 ... add .animate, .style 00:36:39 ... I'm slightly worried we get trouble if using parts, because getting pseudo-eelemnt reference for something that is an element 00:36:45 heycam: animations? 00:36:49 JakeA: .style.whatever 00:37:01 ... if we create pseudo-element object, will it make sense if the underlying thing is an actual element? 00:37:08 heycam: internally, this kind of thing will be .... 00:37:15 ... more a matter of making sure API exposes the right things 00:37:29 ack TabAtkins 00:37:33 TabAtkins: A little bit ago, Miriam said she preferred look of the parts API, more simple naming 00:37:44 ... I'll note that if that's what we care about, we can do that with pseudo-elements, too 00:37:56 ... if that's a significant plus, we can make the tarnsition API work like that with pseudo-element sor with parts 00:38:02 ... we don't ahve to bring one or the other based on that specific issue 00:38:12 JakeA: current API in canary is simlilar, everything hangs off root eleent 00:38:22 ... change something like this to ::part() with same text inside 00:38:29 ... here we've put page-transition to separate from other features 00:38:32 ... would need to do same with aprt syntax 00:38:47 ... to crate a namespace for our feature 00:38:53 s/crate/create/ 00:38:54 ahhhh 00:39:03 emilio: regarding .style etc. 00:39:03 ack emilio 00:39:16 ... right now I don't think we expose either parts or pseudo-elements as things you can change style of 00:39:29 ... but if we did, I thin you'd get more chances for that with parts than pseudo-elements 00:39:33 ... because pseudos don't have attributes 00:39:37 ... not all speudos can have attributes 00:40:08 fantasai: trying to think through how much of this is feeling awkward because it's really long, or how much because of the structure of it 00:40:19 ... if there's way to use pseudo element syntax that's more compact, maybe then it would feel more comfortable 00:40:22 q+ 00:40:50 fantasai: also wrt khush's point about subtrees, I think leaving that possibility open is important 00:40:56 khush: I think the conclusion I'm hearing is to go with part for now, which leaves it open for each engine to decide, whether it's backed with pseudos or shadow DOM, and when we hit implementation, we decide at that point 00:41:18 q+ 00:41:25 JakeA: I tihnk we need to write up both proposals possible 00:41:33 A question: Will it be possible for cross-document transitions to also animate shared elements? (Similar to Magic Move in Keynote, where an element can scale and move and change opacity as part of the slide transition.) If not, should we design syntax such that it could be possible in the future? 00:41:38 ... used shorter syntax for parts examples, but in reality would need to be longer 00:41:55 emeyer, yes 00:41:56 ack emilio 00:42:06 emeyer: I think maybe ??? is a non-issue with parts 00:42:11 s/emeyer/emilio/ 00:42:17 ... because doesn't interact with rest of page 00:42:34 emilio: if we go with parts, most realistic way to implement is using shadow DOM 00:42:48 ack vmpstr 00:43:03 vmpstr: if we go with the part syntax, wouldn't that still run into issue of backed by pseudo-element but scoped to an element that has a shadow DOM attached by developer 00:43:04 s/???/animations in ua sheets 00:43:08 ... wouldn't part syntax then be ambiguous? 00:43:17 JakeA: are you talking about a scoped transition? 00:43:21 vmpstr: yes 00:43:25 JakeA: yeah that's a big issue 00:43:32 q+ 00:43:33 vmpstr: unclear whether to look in shadow DOM or pseudo-tree 00:43:39 emilio: it's true 00:43:50 ack emilio 00:43:54 ... but to be honest, this scoped transition thing raises more questions than answers 00:44:00 ... be good to have a concrete proposal of how that would look like 00:44:07 ... before deciding to use or not use one approach 00:44:22 ... at the point where root of transition can mutate 00:44:35 ... right now proposla is only for docuemnt transition. You know document is not going away 00:44:38 ... various things not changing 00:44:53 ... if you scope the transition to the element, need to define what happens when authors hide or move the element 00:44:56 ... or whatnot 00:45:03 ... raises a lot more complications than I'm comfortable with 00:45:26 Rossen_: I want to see if we can close the discussion 00:45:44 Rossen_: quite a bit of feedback here, what should we do next? 00:46:08 JakeA: I think our action items are to draw up pros and cons of each approach, and maybe also mid-approach where implemented with shadow DOM but use pseudo-elements to access it 00:46:16 ... and sketch out scoped transitoins to figure out how it works 00:46:25 TabAtkins: coming up with half-reasonable short names with each would also be helpful 00:47:07 ACTION: JakeA and khush to draw up pros and cons for shadow DOM vs pseudo-elements vs mixed approaches 00:47:14 so I am dreading s/transition-container/trainer/ 00:47:17 ACTION: JakeA and khush to sketch out scoped transitions to see how they work 00:47:28 ACTIOn: JakeA and khush to find shorter names for things 00:47:35 Topic: Scroll Animations 00:47:35 trainer, that's short and fun. +1 00:47:55 ScribeNick: TabAtkins 00:48:19 fantasai: over the past year, we've redesigned froms cratch how scroll aniamtions work 00:48:28 fantasai: edits are all in the spec, current ED outlines all the stuff we've dsicussed 00:48:49 fantasai: there are parts that ideally belong in CSS Anim 2 and Web Anim 2; these are in an appendix of scroll animations right now 00:49:02 fantasai: I propose publishing this scroll animations spec as an FPWD, with this appendix as a temporary measure 00:49:24 fantasai: With the goal that we'll get Anim and Web Anim cleaned up and published witht he appendix content later 00:49:26 q? 00:49:32 fantasai: For now, think it represents the CSSWG consensus well. 00:49:32 ack fantasai 00:49:36 fantasai: So, publish? 00:49:37 +1 00:49:40 +1 00:49:41 +1 00:49:46 +1 00:49:48 +1 00:49:54 +1 00:49:58 [no objections] 00:50:00 I know a few things about it 00:50:16 RESOLVED: Publish a FPWD of CSS Scroll Animations 1 00:51:53 Topic: 'gap' on tables 00:52:03 github: https://github.com/w3c/csswg-drafts/issues/4848 00:52:28 fremy: First goal is to figur eout if we can actually apply new featues to tables, especially applying common layout features other display modes have now 00:52:33 fremy: gap is easiest 00:52:46 fremy: border-sapcing is very similar, but it's super unfortunate, because it inherits 00:52:57 fremy: Setting border-spacing on a table also changes the spacing of nested tables. 00:53:08 fremy: Seems like there's no good reason, just historical. 00:53:19 fremy: 'gap' doesn't have this problem, and is supported for Grid and Flexbox. 00:53:32 fremy: So, can we specify 'gap' for Table? 00:53:40 fremy: Is there implementor interest? 00:53:54 fremy: For authors, it's easy; there's likely not compat issues since 'gap' is fairly recent. 00:54:02 q+ 00:54:03 q+ 00:54:06 fremy: So is this something people are confident we might want to do? 00:54:12 ack emilio 00:54:21 q- 00:54:25 emilio: Seems reasonable, tho it needs definition of interaction with border-spacing 00:54:29 fantasai: There's a proposal for that 00:54:38 emilio: Does 'gap' support anything border-spacing doesn't? 00:54:45 fremy: One, but it's very manageable 00:54:49 fremy: gap allows % 00:55:15 fremy: Imo, we can quickly decide that % on tables in gap only works for definite-sized axis, otherwise is 0. Similar to %s in many other table contexts. 00:55:26 Rossen_: metapoint is that these details have been worked out in the proposal 00:55:35 honestly, even if we resolve it to zero unconditionally, that would probably be fine and still useful 00:55:48 florian: Is this driven by theory or use-case? 00:56:05 florian: If you'e using tables for data, in my experience, data tables don't use border-spacing all that much. 00:56:19 fremy: I didn't open the issue, Sebastian did but isn't here to defend the point. 00:56:20 q+ 00:56:37 fremy: imo, border-spacing is terrible design, and gap works everywhere and is cheap to do, so get a cheap consistency 00:56:49 nigel has joined #css 00:56:57 fremy: But this is more theoretical for me, yeah. 00:57:08 q+ 00:57:15 ack iank_ 00:57:25 iank_: As long as this is a drop-in replacement for border-spacing, this is okay. 00:57:55 iank_: 'gap' today only works on a single flexbox or grid; border-spacing is more complex because it punches thru and affects things in the rows, the sections, the table itself. Lots of plumbing. 00:58:07 iank_: As long as it's specified to basically directly override border-spacing 00:58:24 fremy: Yes. Initial value of 'gap' is normal; we define that it defers to border-spacing. 00:58:38 iank_: Right, so next is defining that %s don't resolve to something strange and don't re-resolve. 00:58:58 ack miriam 00:59:10 miriam: To respond to Florian, I don't see peole using border-sapcing a lot, I see people using padding a lot 00:59:23 miriam: My expectation is because border-spacing is a weird name that I forget about regularly. 00:59:28 miriam: 'gap' I wouldn't forget about. 00:59:35 q+ 00:59:36 miriam: I'd use it anywhere I'd use padding 00:59:39 It makes sense to me that ‘gap’ would apply to tables, but mostly for completeness’ sake and author convenience. And agree with miram about the use of inline padding. 00:59:45 ack fantasai 00:59:58 fantasai: Another thing is that it's between the borders of the cells. Any time I use a data table, I'm using collapsed borders, so there is no space. 01:00:12 fantasai: So there I'd have to use padding bc both border-spacing *and* gap wouldn't do anything. 01:00:14 ack iank_ 01:00:26 iank_: Right, last point was we can't make 'gap' magically work in collapsed borders. 01:00:36 dbaron: I was also going to mention collapsed borders. 01:00:43 dbaron: Also think it's worth being extra caqreful about %s. 01:00:48 ack dbaron 01:01:17 nigel has joined #css 01:01:20 ack fantasai 01:01:22 dbaron: Don't remember what 'gap' supports in %s, but with border-spacing we're in a position where the Tables model makes it very difficult to support %s in a good way, but any lesser way would be inconsistent with using 'gap' elsewhere. 01:01:40 fantasai: My suggestion would be to make %s resolve only when table-layout is fixed; for table-layout:auto they resolve to 0 unconditionally 01:01:54 iank_: I agree on the auto case, i'll have to think on fixed. It's not as special if you think it is 01:02:04 fremy: Idea is if the table width is definite... 01:02:10 iank_: That's not what was discussed 01:02:21 fremy: Right, that's my idea tho 01:02:30 iank_: I agree that's easier than basing it on table-layout fixed 01:02:44 fantasai: I'm fine iwth it rsolving to 0 *all* the time 01:02:46 iank_: Me too 01:03:02 Rossen_: We're over time. Seems there's some interest, but we're lacking motivation. 01:03:17 Rossen_: Leave it to the WG to decide. Call for consensus? 01:03:29 nigel has joined #css 01:03:30 fantasai: I'd be happy to spec it, think it makes sense, but it's a low prio. 01:03:36 +1 to fantasai 01:03:39 +1 to fantasai 01:03:43 Rossen_: So is this something we want to adopt? Objections? 01:03:51 +1 to fantasai 01:04:04 RESOLVED: Define 'gap' working on Table layout, precise details tbd 01:04:11 fremy: Can we put this in Tables 3? 01:04:13 fantasai: Yeah it's small 01:04:23