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

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

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Thu, 02 Feb 2017 18:50:56 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-277046724-1486061455-sysbot+gh@w3.org>
> [...] 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 

> 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.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at 
using your GitHub account
Received on Thursday, 2 February 2017 18:52:01 UTC

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