- 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
> [...] 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. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/958#issuecomment-277046724 using your GitHub account
Received on Thursday, 2 February 2017 18:52:01 UTC