W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2017

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

From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
Date: Fri, 03 Feb 2017 03:32:08 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-277156069-1486092727-sysbot+gh@w3.org>
> 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 
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 
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 

GitHub Notification of comment by MatsPalmgren
Please view or discuss this issue at 
using your GitHub account
Received on Friday, 3 February 2017 03:32:44 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:08 UTC