Re: [csswg-drafts] [css-grid] Regarding the 'subgrid' feature

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