Csswg-drafts: [css-grid] Introducing overlapping cells in grid-template-areas syntax

[brob]

Proposed update to CSS Grid spec grid-template-areas: https://www.w3.org/TR/css-grid-1/#grid-area-concept

I was recently working on an example showcasing the power of Grid to overlap cells on the grid and I decided grid-template-areas was the proper property to simplify my media queries in the future. I realized there wasn't syntax to handle this in areas and that I'd need to use all Named Lines or a mix of grid-template-areas and named lines to accomplish what I was looking for.

Current working code:

.promo {
    grid-template-columns: [image-start] 1fr [image-end];
    grid-template-rows: [image-start] 10vh auto auto auto 10vh [image-end];
    grid-template-areas: '....'
                         'headline'
                         'text'
                         'button'
                         '....';
}

@media (min-width: 1024px) {
    .promo {
        grid-template-columns: 1fr 1fr;
        grid-template-areas: '........ image'
                             'headline image'
                             'text     image'
                             'button   image'
                             '........ image';
    }
}    

This allowed me the simple media query I wanted, but put my code into two different layout methods for creating my areas.

I'm proposing an update to the syntax of grid-template-areas to allow for multiple named areas to exist in the same template area:

Proposed updated syntax

.promo {
    grid-template-columns: 1fr;
    grid-template-rows: 10vh auto auto auto 10vh;
    grid-template-areas: '...[image]'
                         '[headline][image]'
                         '[text][image]'
                         '[button][image]'
                         '...[image]';

}

This proposed syntax borrows from the syntax of named-lines to hopefully keep it clear what's happening by keeping it consistent with other methods of creating named areas

This is a relatively simple use-case, but I could see other more complex layouts at different viewport sizes working well for this, as well. Full use-case example can be seen here: https://codepen.io/brob/pen/dKWdVB?editors=1100

[Dan503]

Your proposed syntax example isn't very clear 😕. This is how I think the syntax should work:

https://codepen.io/daniel-tonon/pen/dQzOav

New proposed syntax:

.grid {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-template-rows: repeat(3, 1fr);
  grid-template-areas:
    "a   a   ."
    "a [a b] b"
    "a   a   .";
}
.cell-a {
  grid-area: a;
}
.cell-b {
  grid-area: b;
}

This aligns with how multiple line names works so I think it would be very intuitive for authors to pick up on.

[brob]

@Dan503, that's a better reduced case than mine, definitely!

I personally like your syntax better. I think your right that it puts it more inline with the way lines work and that could be an advantage

[SelenIT]

It seems that overlapping named grid areas also would become easily achievable if establishing more than one grid for one element is possible, which was considered before and is sometimes demanded by authors. Though in this particular case this type of solution would be more verbose, wouldn't its suitability for much wider set of creative use cases (especially if accompanied with #2530) (while keeping the syntax of individual grid definitions as simple as they are) be worth considering it as an alternative approach?

[Dan503]

Simply having an alternative method for achieving the same result shouldn't in itself exclude a feature from being introduced. We wouldn't even have grid-template-areas at all if that was the case.

I think this is a simple, easy to understand way to add overlap to a template of grid areas.

This is also something that Autoprefixer could auto-translate into IE syntax for authors. This will speed up adoption of the new feature since authors that have to support IE11 can use the feature without fear. The alternative proposed solutions wouldn't be something that Autoprefixer can translate.

[brob]

The reason I raised the issue was mainly to address what felt like a hole in the functionality of grid-template-areas. The power of overlaps felt very strong until I realized I couldn't accomplish them in one concise property.

I really enjoy the functionality proposed in #2530 but I wonder if this would be a "why not both?" scenario. The proposal in this issue would fill a potentially strong use case in an established pattern (one grid, many areas) and #2530 would handle bigger and more creative use cases (many grids, many areas).

[kenbellows]

Definitely agree with this proposal's intent, overlapping areas is IMHO a significant hole in the grid-template-areas syntax, which I otherwise adore.

I agree that @Dan503's syntax is much clearer, and it's a big bonus that it aligns with existing related syntax.

[Dan503]

For the sake of completeness, this would be the short-hand syntax:

.grid {
  display: grid;
  grid-template:
    "a   a   ." 1fr
    "a [a b] b" 1fr
    "a   a   ." 1fr /
     1fr 1fr 1fr;
}
.cell-a {
  grid-area: a;
}
.cell-b {
  grid-area: b;
}

[ElliottBear]

This is the key missing feature from grid-template-areas - I would love for this to come to light, especially with @Dan503 implementation

[CarelessCourage]

I was looking for a way to do overlapping grid areas and I want to put my vote into this subject also. I think the above mentioned solution would add a lot to the power of the already powerful CSS grid.

[tabatkins]

Hm, this isn't bad. Unsure how worthwhile the syntax is, but this thread provides some decent evidence that people want it, so yay.

I agree that the [a b] syntax for providing multiple names to a cell is readable and transfers intuition from line names, so I like it.

[Dan503]

Be aware that this is what a complex example would look like (I offset some of the grid borders for clarity):

https://codepen.io/daniel-tonon/pen/eYNWaKJ

.grid {
  display: grid;
  grid-template:
    "[a-alpha c-long-name-because-reality]      [a-alpha b-beta-beta c-long-name-because-reality]               b-beta-beta"        1fr
    "[a-alpha c-long-name-because-reality] [a-alpha b-beta-beta c-long-name-because-reality d-deltorino] [b-beta-beta d-deltorino]" 1fr
    "           a-alpha                                      [a-alpha d-deltorino]                              d-deltorino"        1fr /
                  1fr                                                 1fr                                           1fr;
}
.cell-a {
  grid-area: a-alpha;
}
.cell-b {
  grid-area: b-beta-beta;
}
.cell-c {
  grid-area: c-long-name-because-reality;
}
.cell-d {
  grid-area: d-deltorino;
}

[tabatkins]

Well yeah, you can always write complex code if you feel like it. ^_^

[brob]

I think a big part of the original issue was not wanting to completely break out of the syntax of grid-template just to add a simple overlapping item (and as @tabatkins says, you can always be super complex if you want... even still, I think there are benefits there :D).

I think in the end, the syntax would make uses of overlapping grid items much more concise (and hopefully equally or more readable)

[Dan503]

I completely agree with @brob.

The key use case here is that all throughout the site I have been using grid-template-areas to do my grid layouts because grid areas are awesome.

I now need to do a fancy overlap effect.

Ok so I start typing grid-template-areas: ... 🤔... then I realise I don't know how to do the overlap. 😕

So I look up how to do overlap in grid-template-areas... then after a bit of time googling I find out it's not possible 😭

Adding overlap support to areas leads to more consistent CSS code and in most circumstances I think it will also make overlapping CSS Grid cells in CSS code easier to understand and spot.

[tabatkins]

Yes, there is significant value in reducing the incidence of "cliffs", where you suddenly have to switch to a totally different method to do something because you stepped slightly outside of the safe zone. (In this case, that would be manually adding named a-start/a-end lines in both axises to define the overlapping area.)

That doesn't mean it's always worth doing, because there are always other concerns to balance, but I suspect we're good here.