- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Apr 2017 05:41:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed Grid, and agreed to the following resolutions: ``` RESOLVED: publish FPWD Grid Level 2 with the inline issue pointing to the discussion of independent subgrid axes ``` <details><summary>The full IRC log of that discussion</summary> ``` <fantasai> Topic: Grid <majidvp> idea for using web-animation API to create effect in AnimationWorklet: https://gist.github.com/majido/7e542e5af9ef090ba0ab7584316f235d#file-aw-ideas-js <fantasai> Rossen reviews what a grid is <fantasai> majidvp, post into #houdini? <fantasai> (also great to have the link into here but they'r discussing over there :) <fantasai> Rossen: Also good to have a way to group things in a grid <fantasai> Rossen: Don't remember subgrid idscussions <fantasai> Rossen: We started discussing subgrid and how it coudl work, but wasn't until later it made it in the spec <fantasai> Rossen: I believe first version had ability of snapping of grid items in only columns and not rows or vice versa <fantasai> Rossen: So allowing subgrid to allow overriding one of the two dimensions of grid <fantasai> fantasai: I think first version was both axes together, and then we split it out later <fantasai> (and then merged it later) <fantasai> Rossen describes weird overflow columns cases <tantek> (history lesson) <tantek> (merged vs split axis versions) <fantasai> jet: Feedback from mats isn't that A is better than B, but that current version is written to get to CR <fantasai> jet: and some normative text was lost there <tantek> scribenick: tantek <tantek> fantasai: we didn't lose any normative text <tantek> ... there were some changes to simplify things, like changing how overflow was handled <tantek> ... changing one case to see what implementations picked up on <tantek> ... we didn't lose any interesting aspects of subgrid <tantek> ... the main thing that was dropped was ... <tantek> ... the thing that was confusing was a subgrid that had more rows & columns than the # of rows or columns it spanned in the parent grid <tantek> ... I don't consider that to be significant feature <tantek> ... in terms of significant use-cases <tantek> ... it was more like we need to deal with this case so we defined something <tantek> ... and people were like this is scary <tantek> ... (flippy window use-case) <tantek> fantasai: we didn't lose anything except independent axis subgridding (that was significant) <tantek> Rossen: if we look at the current version that is in the draft, it snaps to areas of the parent grid <fantasai> [A: split axis; B: current version] <tantek> ... it does not affect any of the area of the columns or rows <tantek> ... it acts as a grouping mechanism <tantek> ... in a sense you can draw a paralell between subgrid and non-BFC blocks in a block layout <tantek> ... they are there to just group things nicely <tantek> ... like document layout defines paragraphs, and divs can put borders around them <tantek> fantasai: it doesn't establish a new grid formatting context <tantek> ... it continues with the old [it's parents] grid formatting context <tantek> Rossen: I took a look at scenarios in the office <tantek> ... at some point this is something that has to be done by every engine <tantek> ... measuring the sizes of things inside <tantek> ... arranging things, align things <tantek> ... (stages) <tantek> Rossen: if we take those stages <tantek> ... how does subgrid affect measuring? <tantek> ... if we assume all rows and columns are auto <tantek> ... they have to snap to content <tantek> ... Extreme case: one subridg, no items, but has border <tantek> ... I'm trying to highlight the fact that subgrid contributes to measuring rows and columns by its MBP <fantasai> https://www.w3.org/TR/2017/CR-css-grid-1-20170209/#subgrids defined in item c <tantek> ... the width height min-width max-width and other sizing related properties are forfeit because it snaps / stretches to the areas of the grid that were defined <tantek> ... however if everything was empty and the parent grid was auto, then it will be the size of the subgrid's borderbox <tantek> fantasai: then what's not perfect <tantek> ... if it's perfect we publish it <tantek> Rossen: first we have to define min & max widths are not applied <tantek> ... currently spec only talks about height and width <tantek> ... the other thing that is not covered is overlow <tantek> s/overlow/overflow <tantek> fantasai: that's specified item h <tantek> ... width and max-width etc. are item f <tantek> ... any specified width and height constraints <tantek> TabAtkins: that includes min and max <tantek> Rossen: and there are no gaps <tantek> Florian: the overflow is defined as you may do it so... <tantek> TabAtkins: but it is defined in terms of layout effects <tantek> ... it is still well defined how it and the parent grid get laid out accordingly <tantek> Rossen: do we honor position relative? <tantek> fantasai: i don't see why not <tantek> Rossen: can that be a container ... <tantek> fantasai: yeah <tantek> Rossen: what about position absolute <tantek> fantasai: then it is no longer a subgrid, it is a grid <tantek> TabAtkins: it is no longer participating in the grid's layout <tantek> fantasai: if it is not iself a grid item then it becomes a grid <tantek> s/iself/itself <tantek> many: it's still not a grid item <tantek> Rossen: so then, when we go to auto flow all the grid items as well as the items of the subgrid <tantek> ... what order are we taking? <tantek> ... my assumption is depth first search <tantek> fantasai: auto placement happens inside subgrid <tantek> ... the subgrid has an explicit position by its start end and grid-position properties <tantek> ... before you even look at its contents you know how many grid areas it takes up <tantek> Rossen: that's not what i was asking <tantek> ... now that we have positioned the subgrid <tantek> ... then we position the items of the grid <tantek> TabAtkins: no the subgrid items <tantek> Rossen: hold on <tantek> ... let's say that I have in the parent grid G, I1, SG has I2 and I3 <tantek> ... so let's say I1 is placed at 2,2 where it overlaps the subgrid <tantek> ... so now I'm doing auto placement of items <tantek> ... I've come in here, processed everything else <tantek> ... then the first item outside the subgrid has to be place <tantek> fantasai: the subgrid is taking up that spot, so you can't place it there with auto <tantek> TabAtkins: the subgrid is also a grid item so it takes up space like any item <tantek> Rossen: why not do depth first? so we can auto place? <tantek> fantasai: a lot of the time you want to place stuff inside the subgrid, then auto place others <tantek> TabAtkins: subgrid sometimes because you want a border around that area <tantek> ... you are yourself an indpeendent chunk of content <tantek> fantasai: you have to treat the subgrid as a nested grid <tantek> Rossen: we could consider placing the subgrid more transparent <tantek> ... and place other items <tantek> (unparseable from Rossen) <tantek> fantasai: it should behave like a nested grid <tantek> ... the only difference is instead of an explicit set of lines, you are aligning to the lines of the parent grid <tantek> ... they want alignment but they want that subgrid item to be an atomic thing <tantek> Rossen: I can live with either of those <tantek> TabAtkins: subgrid is just a nested grid, and ... <tantek> Florian: you placed your block analogy too far <tantek> TabAtkins: another interestin question, your subgrid has auto-placed items, your parent grid places an item on top of the subgrid, what happens? <tantek> Rossen: what I heard is that you can place two grid items on the same area <tantek> TabAtkins: even if the parent grid places an item explicitly, you can still auto place the subgrid on top of it <tantek> Rossen: so, writing modes <tantek> .. if this was a LtR grid and the grid inside here says RtL that should just work <tantek> ... for vertical / orthogonal changes, where the subgrid changes <tantek> ... so let's say the subgrid was not square, like 2x3 <tantek> ... if I change the subgrid so that it is orthogonal to the parent, what happens <tantek> fantasai: we need to add that <tantek> Rossen: in other words i would be surprised that in tables we do that <tantek> ... so that to me is the same <fantasai> ACTION fantasai clarify that subgrids with orthogonal flows have rows and column axes flipped within the subgrid <trackbot> Created ACTION-842 - Clarify that subgrids with orthogonal flows have rows and column axes flipped within the subgrid [on Elika Etemad - due 2017-04-26]. <tantek> Rossen: so if I say an item is at 1,2 then it is here and not here <tantek> TabAtkins: that always works <tantek> ... what is not defined is your horizontal span becomes your row count <tantek> fantasai: we can clarify it <tantek> Rossen: alignment should work fine <tantek> ... what about align-self on the subgrid <tantek> fantasai: that's also in item f <tantek> ... because we ignore all sizing stuff <tantek> ... alignment triggers shrink to fit <tantek> Rossen: in terms of drawing, any implications to stacking context? <tantek> fantasai: same as a nested grid <tantek> Rossen: so none <tantek> Rossen: can we allow repeat on a subgrid <tantek> fantasai: no because you are taking your rows and columns from the parent <tantek> Rossen: do we need to be explicit? <tantek> fantasai: we already say ignore grid template properties, that's item a. <tantek> (discussion clarification) <tantek> Rossen: with all of that, we are happy with how subgrid is specified currently, and I would like to hear from others <tantek> rachelandrew: I think mats concern is locking it to both dimension, and I have a concern with that too <tantek> ... what I'm seeing people expect what subgrid to do, is columns locked to the grid, and not the rows because they'll be adding content there <tantek> TabAtkins: there are use-cases but it makes the algorithm so complicated <tantek> fantasai: I don't think we tried (to write it down) <tantek> rachelandrew: I think that's what mats was asking for <tantek> TabAtkins: I couldn't figure it out <tantek> ... the egalia folks were like LOL no we can't do this <tantek> ... plus my French co-worker <tantek> ... our original grid implementer <tantek> ... julien <tantek> ... he was also like no <tantek> fantasai: we are creating a new FPWD here <tantek> ... if it helps I'm happy to take a try at defining a one-axis grid, just so we can see what that looks like <tantek> ... if that would make Mozilla happier <tantek> ... it might not be as scary once defined <tantek> rachelandrew: what I'm hearing is that people expect that subgrid will work that way <tantek> Rossen: what is the use-case? <tantek> rachelandrew: people are thinking grid like bootstrap 12 column grid <tantek> .... and then things on that top level are using that <tantek> ... like a bunch of products <tantek> ... you know how many columns you want <tantek> ... but you don't know how many rows you'll use because that depends on content <tantek> rachelandrew: there's also like the BBC home page <tantek> Rossen: is it the case where you start with a subgrid <tantek> ... I have one item, it goes no problem <tantek> ... now I have another item, and then the expectation is that the subgrid will grow? <tantek> rachelandrew: yes. people have these layouts that are used for multiple things <tantek> (having trouble minuting this without context of the whiteboard diagram) <fantasai> [fantasai draws a picture] <fantasai> [6-column master grid on the page; header has several rows of stuff with different interesting spanning stuff; main section has a 2-column wide sidebar and a 4-column wide main section] <tantek> tantek: i heard a proposal from fantasai to try to write it down so why are we still arguing? <tantek> rachelandrew: this was the issue that mats was pointing to and that he wants discussed, and I would agree <tantek> ... I think subgrid is important that we get it <tantek> ... if we have it locked to two dimensions it is not what people are expecting subgrid to be <tantek> ... when I talk to regular developers <fantasai> [it's unknown how many rows of auto-placed content is in the main section, but the sidebar has to span it all, so it needs to span 1 in the parent grid and the main section takes the main parent's column divisions, but subdivides into as many rows as needed for auto-placed items] <tantek> Rossen: what if I go subgrid ina subgrid <tantek> ... if I have a subgrid that takes only the columns, and inside of it I have only one subgrid that takes only rows <tantek> subgridception <tantek> fantasai and rossen draw and discuss at the whiteboard <tantek> fantasai: we have parent grid which is black lines, we have a subgrid (blue lines) which cares about columns but not rows, it spans 3 columns, it makes its own rows <tantek> ... like four rows for example <tantek> ... it has some items <tantek> ... and then it has a subgrid itself <tantek> ... which cares about the rows from its parent, but not columns <tantek> ... so it takes the rows from its parent, so it gets two rows, and then it defines its own columns, and it has maybe like a lot of columns <tantek> ... so now we have to do the grid sizing <tantek> ... the placement is a nested structure <tantek> ... so it looks at this one this one this one [points at diagram] <tantek> ... but doesn't care about this (two nested subgrid) <tantek> ... when it asks the subgrid to figure out how big are you when you are spanning your columns <tantek> ... it takes its columns from the parent so it won't resize those <tantek> ... but I have four rows so... <tantek> ... so then I have four rows, one item in this one, two in this one, one item plus a spanning item in here <tantek> ... it does row sizing there <tantek> ... so when it asks it ... <tantek> Florian: when you're doing the green (2 nested deep)... the width dimension is based on its own auto-sizing? <tantek> fantasai: in the current spec it has both <tantek> fantasai: in the subgridded dimension we honor the width, in the non-subgridded dimension we ignore it <tantek> ... you just treat it as a bunch a content <tantek> ... in the subgridded dimension we stretch it out to take all of the available grid area <tantek> Rossen: let's consider that this here would be another subgrid item <tantek> fantasai: so it too aligns <tantek> Rossen: and it has two items <tantek> (rossen draws another subgrid at same level as 2nd level deep green line subgrid) <tantek> Florian: while we are discussing level 2, maybe I just missed a section <tantek> ... how often have you found people using spacer gifs <tantek> rachelandrew: they're using generated content <tantek> ... for backgrounds and borders <tantek> ... everyone wants to put backgrounds and borders on empty areas <tantek> ... also like name every other line so they can place things <tantek> ... auto place against <tantek> ... set some structure in the naming <tantek> fantasai: you basically have different grids <tantek> Florian: should we just acknowledge that this is a problem and we don't have a solution yet? <tantek> Rossen: we could have the current subgrid published as a WD <tantek> ... and then have fantasai add text for how this could work <tantek> Rossen: ideally if we have the current version published so we don't lose it <tantek> ... because we said we would remove it from level 1 and put it in level 2 <tantek> Rossen: anyone objecting to publishing the current subgrid? <tantek> Github issue: 958 <rachelandrew> https://github.com/w3c/csswg-drafts/issues/958 <tantek> Github topic: https://github.com/w3c/csswg-drafts/issues/958 <Rossen> images of the discussion https://lists.w3.org/Archives/Public/www-archive/2017Apr/0004.html <tantek> tantek: my request is to put an inline issue in the FPWD pointing to the issue of independent axes <fantasai> Yay images!! :D <tantek> Florian: I don't think grid fragmentation has been figured out <tantek> fantasai: I think that and flexbox is a huge feature that has not gotten any love <tantek> Florian: given limited resources I'm not sure Vivliostyle can work on it unless people are going to look at it <tantek> fantasai: I think that issue of fragmentation and grid, needs someone to care about printing, file an issue against the spec <rachelandrew> https://github.com/w3c/csswg-drafts/issues/796 is the issue referring to auto placement and named lines <tantek> ... I think that... <tantek> ... we did in flexbox <tantek> ... there is question about how do you distribute space across a fragementation <tantek> ... it is tricky <tantek> ... we shouldn't try unless we are in the process of implementing it <tantek> ... it's not that we don't want it, we don't want it in theory, we want it in practice <tantek> ... for flexbox the theory aspects are spec'd <tantek> ... in terms of distributing space there is a variety of algorithms of more or less complexity <tantek> Florian: and I think that description fits with Vivliostyle <tantek> ... the difference is that both of these specs are big efforts <tantek> ... if we do that will anyone listen? <tantek> Rossen: definitely we'll listen <tantek> ... take a look at the current strawman we have there <tantek> ... it works in a lot of cases fairly well, but not all <tantek> ... if you want to take this and start improving on it <tantek> TabAtkins: while chrome cannot currently fragment worth crap, as we move things internally to our own Houdini APIs, then we will care <tantek> Rossen: I want to go back to the resolution for the FPWD for Grid level 2 <tantek> Rossen: any objections to publishing FPWD of Grid level 2? <tantek> tantek: I gave my requirement of asking for inline issue <tantek> Rossen: then let's call that resolved to publish FPWD with the inline issue <tantek> RESOLVED: publish FPWD Grid Level 2 with the inline issue pointing to the discussion of independent subgrid axes <tantek> ... <tantek> fantasai: people want to style this area of nothing <tantek> Florian: empty div? <tantek> ... we don't have a way to generate oxes <tantek> s/oxes/boxes <tantek> rachelandrew: it's visual styling, it's a CSS thing <tantek> (something events) <tantek> TabAtkins: at some point we'll address this more generally <tantek> Florian: you mean just use empty divs for now? <tantek> TabAtkins: no I'm for pseudolement or an infinite collection of pseudoelements <tantek> Florian: also how you solve the consume that space <tantek> TabAtkins: the original version from Bert's draft had a way to say this is an empty cell <tantek> Florian: in the limited examples I've tried to write, I've found the "consume this cell so nothing goes there" would solve it, but another way would be auto-place, but start here, and not before <tantek> fantasai: so position the first one, and auto-place the rest <tantek> ... the main thing is we need stylable things in the grid <tantek> ... that's a very strong use requirement coming from the authoring community <tantek> rachelandrew: it's like question one coming when people look at grid <tantek> iank_: so the specific request is styling row 1 col 2 red <tantek> rachelandrew: yeah at the moment people are either sticking in an empty div or generated content to style <tantek> iank_: this is like page background effects <tantek> Rossen: we are wrapping up <tantek> ... do we have an issue for this? <tantek> fantasai: I think we do <tantek> iank_: this is where I say you could use the paint api to polyfill this <fantasai> https://github.com/w3c/csswg-drafts/issues/499 ``` </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/958#issuecomment-295104675 using your GitHub account
Received on Wednesday, 19 April 2017 05:41:37 UTC