[css-grid] Regarding the 'subgrid' feature #958

MatsPalmgren · 2017-01-19T02:43:13Z

https://drafts.csswg.org/css-grid/#subgrids

I've re-read the latest spec text and it still looks rather immature to me. I suspect that it needs several rounds of feedback from implementors (while we're actually implementing it!) before it will mature. As you know, there have been many significant improvements in other parts of the Grid/Alignment specs based on our feedback and I suspect that this will be even more true for subgrid given that it's a relatively complex sub-feature of Grid.

@jensimmons, @meyerweb and others have expressed that subgrid is an important feature. I fully agree. This makes me think that we should be extra careful in designing this feature and that the spec for it shouldn't be finalized before everyone can give solid feedback on it, based on experimental implementations (i.e. Nightly/Canary builds).

IIUC, the CSS Grid spec will soon have CR status. Firefox and Chrome will soon release their initial implementations of Grid layout, but both vendors have chosen to exclude subgrid in the first version (there are several good reasons for this, but I won't go in to that here).

In this situation, I believe that it would be bad to finalize the syntax and semantics of the subgrid feature at this point - it's definitely not ready to have CR status IMHO. If the CSSWG intends to move Grid to CR soon, then I think you should exclude the subgrid feature completely and instead move that to the next level of the Grid spec. Otherwise, I think Grid CR status should be gated on solid implementation feedback for subgrid, preferably from two independent implementations.

Thanks for your consideration.

The text was updated successfully, but these errors were encountered:

rachelandrew · 2017-01-19T06:08:49Z

I've been very vocal about my belief that subgrid is a requirement, and have been talking about this with authors and looking at use cases for the last couple of years [1].

The revised specification came about after a conversation with developers from Igalia [2], as an attempt to move the feature forward. Given that this has not resulted in any implementor doing so, I would be inclined to agree with Mats that the feature should be more clearly worked through, rather than this revised attempt pushed into L1.

The revised spec solves a class of issues that authors expect grid to solve for them. For example in this post[3], the author wants to be able to line up the internals of a set of boxes laid out by grid. In this case we know the number of rows required in the subgrid so the fact that subgrids are in both dimensions would not be an issue. There are a number of cases however [4]where people will want more auto-placement of items in a subgrid, and I don't see how this will work with the revised spec.

It's been relatively difficult to get good author use cases for more than the most trivial of things, with grid behind a flag. I'm starting to see that pick up now as people realise this is shipping in browsers. I think in 6 months time we're going to have a lot more to work with in terms of seeing how people really want to use this feature. My fear in punting it to L2, without clear interest from implementors is that it disappears into some distant future.

So at this stage I agree with Mats, this feature still needs a significant amount of discussion, it needs more author use cases (which I will continue to collect as I talk to authors). Grid is already at CR and my understanding in terms of process is that Grid can't exit CR with features that do not have two interoperable implementations, so a decision will need to be made at some point about subgrid. Whatever that decision is I very much hope that it comes along with interest from both the WG and implementors to move this feature along. My feeling is we will start to get a lot of demand for it from authors very soon.

fantasai · 2017-02-01T06:54:57Z

As Rachel notes, Grid is already in CR. If feedback ends up destabilizing the spec for subgrid, we will pull it back into L2 WD. Since we haven't received much in the way of such feedback, I'm inclined to leave it in CR until we do. :)

(From the CSSWG perspective, CR is intended as "we can't do anything more to improve this feature without implementation, and don't expect any changes unless they come from implementation feedback, so please try to implement it". That said, there didn't used to be much distinction between "implement it" and "ship it" in the past, and now there is, so there is that.)

MatsPalmgren · 2017-02-02T00:07:15Z

Well, just to give you one example: the display:subgrid value, which implies a subgrid's tracks must be tied to its parent grid in both axes. This is something that wasn't in the spec originally, but was added for vague reasons of maybe being "simpler".

From my experience in implementing the rest of the Grid spec in Gecko, this seems misguided. Pretty much all algorithms so far are implemented in a way that they apply to each axis independently, i.e. you have some data/state per track, and a set of those for each axis, then you run the same algorithm once for the column axis and then for the row axis. I don't see why subgrid poses any problem in this respect. So I think we should, as a starting point for implementation, use the original subgrid keyword in grid-template-rows/columns, which allows for this:
https://www.w3.org/TR/2015/WD-css-grid-1-20150917/#track-sizing

Removing the ability to specify subgrid in just one axis takes away creative freedom from authors, something I, unlike the CSSWG apparently, take very seriously. We shouldn't do that without strong reasons based on actual implementation experience. There is no evidence to support that display:subgrid is in any way simpler than the previous version of the spec. (I could be wrong of course, but I don't think anyone can tell before trying to implement it.)

Regarding "Grid is already in CR" -- subgrid is marked as at-risk, thus it can be removed from the L1 CR version of the spec (or better, replaced with "TBD in Level 2"). I think it's clear that the subgrid part of CSS Grid is not mature enough to be standardized in its current form and that doing so is actually harmful.

To be clear, personally I'm not even going to start implementing the subgrid feature unless I have assurances that Grid spec changes are welcome, and that for example supporting subgrid in just one axis will be accepted if implementation experience shows that it is in fact not hard to support. And as long as subgrid is in the L1 CR, I'm not confident that would be the case.

rachelandrew · 2017-02-02T08:20:23Z

Mats - as already noted (and as an author who is also a CSS WG Invited Expert) I agree with you, and mentioned some of the history of the change to the spec in my comment.

Whether subgrid stays in the spec for now or is removed is mostly process if no-one is implementing it. However I would love to have some discussion around what subgrid should be. I have a reasonable idea of what authors might want - and I think once grid ships we'll see many more examples which I am already looking out for in order to collate real use cases. I'm not an implementor and so have to base what I know about what is and is not hard to implement upon what implementors say.

tabatkins · 2017-02-02T18:50:55Z

[...] takes away creative freedom from authors, something I, unlike the CSSWG apparently, take very seriously.

This is unnecessary hostility, and helps nobody. Please leave it out of any future communication.

Well, just to give you one example: the display:subgrid value, which implies a subgrid's tracks must be tied to its parent grid in both axes. This is something that wasn't in the spec originally, but was added for vague reasons of maybe being "simpler".

No, it's actually 100% required for the simplification of subgrid that ended up making it palatable to implementors.

The subgrid feature, as written now, effectively promotes the subgrid's children up to being child boxes of the parent grid - they position themselves in the parent grid exactly like the parent grid's own children do. They just receive a bit of "magic margin" if they're against the edge of the subgrid, equal to the subgrid's own m/b/p, to make it look like they're positioned inside the subgrid. The whole feature is just a slightly souped-up version of display: contents, because contents didn't address the "visual grouping" use-case that originally motivated subgrids.

Allowing the subgrid to only inherit the parent grid's tracks in one dimension changes the entire feature, making the subgrid actually a full grid container for its children, with a complicated relationship between its tracks and those of the parent grid. It's possible to define how this works - we kinda did it, tho you had to read very closely to correctly understand how it worked - but it's a lot of extra complication for relatively little benefit. The feature as currently designed is vastly simpler and allows almost as much stuff.

To be clear, personally I'm not even going to start implementing the subgrid feature unless I have assurances that Grid spec changes are welcome, and that for example supporting subgrid in just one axis will be accepted if implementation experience shows that it is in fact not hard to support.

You're free to make implementation decisions as you like, and refusal to implement something does have the possibility of killing the feature entirely. But it seems clear from your comments that you haven't looked at the feature in enough depth to understand the simplicity of the current approach, and the complexity of the previous approach. I'd spend a bit more time thinking on this before making your final decision.

fantasai · 2017-02-02T22:11:30Z

something I, unlike the CSSWG apparently, take very seriously

The CSSWG is composed of implementer representatives as well as various other experts, and it's our job to take feedback and process it: yours as well as everyone else's. The feedback on Subgrid from implementers (specifically, from Igalia) was what prompted the restriction you are objecting to.

To be clear, personally I'm not even going to start implementing the subgrid feature unless I have assurances that Grid spec changes are welcome, and that for example supporting subgrid in just one axis will be accepted if implementation experience shows that it is in fact not hard to support.

If you and Igalia can agree on that point, I am sure we would be happy to re-open the discussion and make any necessary changes. Rachel would also be happy as she's concerned about the restrictions as well. :)

Again, we did the best we could processing feedback on subgrid, and put the resulting draft--which was stable, no issues were reported against it--in CR along with the rest of the spec. If there are reasons to pull it back to WD for further re-work, we will.

MatsPalmgren · 2017-02-03T03:32:07Z

The subgrid feature, as written now, effectively promotes the subgrid's children up to being child boxes of the parent grid - they position themselves in the parent grid exactly like the parent grid's own children do. They just receive a bit of "magic margin" if they're against the edge of the subgrid, equal to the subgrid's own m/b/p, to make it look like they're positioned inside the subgrid. The whole feature is just a slightly souped-up version of display: contents, because contents didn't address the "visual grouping" use-case that originally motivated subgrids.

This is the first time I've heard subgrid described as "a slightly souped-up version of display: contents". It seems like a bad analogy to me. For example, the children of a subgrid should not be placed as if it has display:contents. Here's an example https://people-mozilla.org/~mpalmgren/tests/grid/grid-subgrid-1.html that use display:contents on a grid item. Two things to note here: the "B" jumps out from the "subgrid" and is placed in the first slot before the "A" (due to dense), this would not occur if this was a subgrid (without display:contents). Secondly, the "D" is auto-placed inside the "subgrid" (adjacent to "C"), this would not occur either if this was a subgrid (instead, the "D" would be placed before the "A"). So, subgrid vs display:contents have completely different effects on placement.

The primary feature of display:contents is that it doesn't have a [principal] box. A subgrid on the other hand MUST have a box, because it needs to be able to have a border/padding/margin/background/opacity/transform/relative position/clipping/scrolling/and everything else that CSS associates with a box. It should also be the CB of its abs.pos. descendants when its properties says so (position:relative/transform etc). A display:contents element can have/be none of those things.

(FYI, it just so happens that I'm the person that implemented both grid layout and display:contents in Gecko, so I know intimately how these work internally. I can tell you with 100% certainty that implementing subgrid as "a slightly souped-up version of display: contents" would fail disastrously. I would advice against having that mental model of subgrid because it's very likely to be misleading rather than helping.)

As far as understand the Grid spec, the following are true:
A. a subgrid item MUST have a principal box
B. that box establishes a grid formatting context
C. the subgrid's items cannot be placed outside the subgrid
D. the parent's items cannot be auto-placed inside a subgrid
E. subgrid items contributes to the Track Sizing Algorithm of the parent grid and the track sizes are taken from the parent
F. subgrid items participate in baseline alignment together with the parent's items (and other subgrid's items) in the same track

Given that list, I think a better mental model for subgrid is that it is just like an ordinary grid container, with a few exceptions, like E and F above, plus the bullet points that the Grid spec currently have (I suspect that we'll modify/add to that list once we start implementing it, but it looks like a good starting point).

I do think that we should keep an open mind about adding "in one or both axes" as the original subgrid spec said, because that would be useful to authors and there is no evidence to suggest it's hard to implement at this point, so we should at least try before rejecting it.

MatsPalmgren · 2017-02-03T03:36:13Z

The feedback on Subgrid from implementers (specifically, from Igalia) was what prompted the restriction you are objecting to.

Right, I'm well aware of that. My impression though, is that their conclusions were not based on actually trying to implement it.

I think you need to separate "an implementer gives feedback based on his/her opinion" vs "an implementer wrote code that tried to implement what the spec says and ran into unforeseen problems". The latter category is of course what should count as "evidence based on implementation experience". The former is of course valuable, but the latter must be taken much more seriously.

Again, we did the best we could processing feedback on subgrid...

Yes, and I appreciate that. But that doesn't mean subgrid is ready to be enshrined with CR status. Unlike the rest of the Grid spec, which is now implemented (for the most part) in two major browsers, the spec for subgrid has not been battle-tested like that and it's better for everyone if it remains in draft status, as I argued in the OP.

Subgrid is both an important feature (we should try hard to get it right) and also a rather complex feature (it's unlikely that we'll get it right before starting to actually implement it). I see no benefits at all to freezing the feature in its current form before we have actual implementation feedback.

frivoal · 2017-02-03T06:12:58Z

[...] that doesn't mean subgrid is ready to be enshrined with CR status. Unlike the rest of the Grid spec, which is now implemented (for the most part) in two major browsers, the spec for subgrid has not been battle-tested like that and it's better for everyone if it remains in draft status, as I argued in the OP. Subgrid is both an important feature (we should try hard to get it right) and also a rather complex feature (it's unlikely that we'll get it right before starting to actually implement it). I see no benefits at all to freezing the feature in its current form before we have actual implementation feedback.

CR does not mean frozen and will not change regardless of implementation feedback. As @fantasai said, it means “we can't do anything more to improve this feature without implementation, and don't expect any changes unless they come from implementation feedback, so please try to implement it”. So when you say that it needs implementation feedback to make it better, this does not contradict the fact that this is in CR, it reinforces it. I completely agree that subgrid is nowhere near ready to **exit** CR, unlike the rest of the spec which is getting there, but that's why it is marked at risk. Assuming, which seems likely, that the implementations of the rest of the spec reach sufficient quality to exit CR and move onto REC while subgrid remains unimplemented (or incompletely so), it will probably be pushed to the next level. But until then, what CR does seem the right level, and I don't see what harm it does being at that level.

MatsPalmgren · 2017-02-03T19:55:10Z

CR ... means “we can't do anything more to improve this feature without implementation, and don't expect any changes unless they come from implementation feedback, so please try to implement it”
[...]
CR does seem the right level, and I don't see what harm it does being at that level.

The harm is that the Grid CR is recommending us to implement a feature that is sub-optimal for authors. It would be better if implementers tried to implement the older version of the subgrid spec (where subgrid could be specified independently for each axis) and then report back if there are any actual implementation issues with that. It's quite clear from the quote above though, that CR means the discussion is over and that alternative solutions aren't going to be considered.

[if] subgrid remains unimplemented (or incompletely so), it will probably be pushed to the next level

That would be unfortunate, when I'm telling you I'm willing to investigate if subgrid could work independently in each axis right now. But I'm not going to invest that time unless the CSSWG would welcome such a spec change, which seems very unlikely when the CR precludes that solution.

dbaron · 2017-03-15T17:12:31Z

This was discussed in today's teleconference, concluding with:

RESOLVED: Move subgrid to level 2 of Grid

css-meeting-bot · 2017-04-19T05:41:27Z

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

The full IRC log of that discussion

<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

BlueStormNetwork · 2017-08-30T03:15:53Z

Hi guys,
Regarding subgrid please find below a use case for it where I tried to use it for a simple form layout yet using grid and subgrid main form has a grid that has 3 children one of them has 2 children
as you can see the in "Shareholders" and "Directors and officers" sections I used a subgrid for and had some issues I have:

1- middle subgrid puts the wrong width value on column 2 resulting in its 2 children mentioned above to display like that(see attachment) knowing it should be 47% 6% 47%
2-grid-column-start/grid-column-end if used to express a span are buggy same for grid-row-start/grid-row-end so I used grid-column/grid-row.
3- tried to make separate grid and avoid nesting as grid displays as a block I used inline-grid components were shrink-ed and with wrong size some components overflowed the grid.
4- using names for lines is buggy switched to numbers it works.

tested on Chrome 60.0.3112.113/Firefox 55.0.3 IE 10/11 no support don't have edge :p
Thank you for the good work was waiting for something to replace the nesting pile of div/float for layouts ;)
Regards.

Source here https://codepen.io/nonameleft/pen/dzQKJE

fantasai · 2018-01-24T07:59:35Z

@MatsPalmgren There's been an issue in the Grid Level 2 draft about per-axis subgrids explaining how they should work; I've now gone ahead and drafted up diffs against the Grid Sizing Algorithm to be a bit more specific in 62d65ed

dauwhe added the css-grid-1 label Jan 26, 2017

atanassov added the Agenda+ label Mar 14, 2017

atanassov added Needs Edits and removed Agenda+ labels Mar 16, 2017

atanassov assigned atanassov, tabatkins and fantasai Mar 16, 2017

fantasai removed the Needs Edits label Mar 30, 2017

fantasai closed this as completed Mar 30, 2017

rachelandrew mentioned this issue Jun 8, 2017

Grid Layout w/ Dynamic Content rachelandrew/cssgrid-ama#13

Closed

kleinech mentioned this issue Aug 12, 2017

Sticky header with CSS ultimate-comparisons/ultimate-comparison-framework#87

Closed

fantasai added the Tracked in DoC label Jan 22, 2019

fantasai added this to the css-grid-1 CR 2016-09-29+ milestone Jan 22, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-grid] Regarding the 'subgrid' feature #958

[css-grid] Regarding the 'subgrid' feature #958

[css-grid] Regarding the 'subgrid' feature #958

[css-grid] Regarding the 'subgrid' feature #958

Comments