- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Feb 2017 03:32:08 +0000
- To: public-css-archive@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 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. -- GitHub Notification of comment by MatsPalmgren Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/958#issuecomment-277156069 using your GitHub account
Received on Friday, 3 February 2017 03:32:44 UTC