W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css-grid] Reduced Subgrid Proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 27 Apr 2016 10:00:59 -0700
Message-ID: <CAAWBYDCcUY48qoavvYcW-yo-Y_G+QbgSCz2TLojJgYVNBkBLZw@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style list <www-style@w3.org>
On Wed, Apr 27, 2016 at 9:36 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> On 04/26/2016 04:55 AM, Brad Kemper wrote:
>>> On Apr 20, 2016, at 11:16 AM, Tab Atkins Jr. <jackalmage@gmail.com>
>>> wrote:
>>> The main unhandled case is wanting a nested grid that cares
>>> about the parent grid's lines in one axis only; this case appears to
>>> be relatively rare/niche
>> What are you basing that "rare/niche" on? Gut feeling? Anecdotal
>> observation? Some statistics? Just wondering.
> I have no idea. I'm not so sure it's that niche, either.

Intuition mostly.  It's higher in complexity than the previous cases,
so that's a strike against it being common; it's just less likely for
higher-complexity cases to *occur*, as you have more requirements that
need to all line up at once.  I can imagine the other cases coming up
commonly, tho.

Also, I just don't think this subgrid approach is the right solution
for it.  It's... too clumsy, for a case with these requirements.  *If*
we satisfy the use-case, it'll be just barely, and there will be
closely-related use-cases that I think are equally valid that aren't
addressed at all.  I don't like trying to fight into this sort of
space unless it's trivial; adding a lot of implementation complexity
for something that's likely rare and that isn't even solved "properly"
is a losing proposition.

(The right solution for things in this vein, I believe, is something
like what Fran├žois argued for in one email, where you somehow tie
grids together and make them share track sizes.  This gives you a lot
of flexibility to explore this space of use-cases, but it's also
complex and hard, so I'm not willing to explore it unless/until it
proves necessary.)

> But it was something Igalia found frightening, but didn't
> seem as critical as the other three features listed in
> "Rationale", so we dropped it from the proposal.
> If its considered critical then we can update the proposal
> to incorporate it. I think it wouldn't be that hard: just
> don't ignore 'grid-template-*' in the subgrid, and only
> propagate the parent grid lines if their value is 'none'.
> It would be treated as a subgrid in one dimension and as
> a regular spanning child element (as 'display: grid') in
> the other.

It's not that trivial.  It fundamentally changes how the parent grid
and subgrid interact in a complex way that will be really annoying to
integrate into the layout algorithm; in the non-subgrid axis you'll
have a set of tracks that are being sized under two separate sets of
constraints at the same time.  I'm 100% opposed to non-trivial changes
and bugfixes to the layout algorithm at this point; we can revisit it
in a while after implementations have stabilized, but right now is
*not* the right time to rip things up in there.

Received on Wednesday, 27 April 2016 17:01:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC