Open Que-tin opened 1 year ago
Some thoughts:
i
, this should probably have access to the number of columns and rows in the explicit grid.i
shouldn't be incremented for them, and auto placement should have some way of avoiding overlaps.
- Additionally to
i
, this should probably have access to the number of columns and rows in the explicit grid.
Thought about this initially as well, but I'm not really sure if this makes sense or is possible in all cases. If you haven't set any grid-template
wouldnt the number of columns and rows be determined by the grid-auto-placement
value?
If you then use grid()
inside of the grid-auto-placement
wouldn't that result in a reference to result of the function it is used in? If you know what I mean.
But yeah there are probably a couple of more parameters that are technically already there to place items onto the grid that could be exposed and would increase the power and amount of use-cases for the grid()
function.
- Seems problematic when some items have an explicit position: probably
i
shouldn't be incremented for them
Isn't that what I wrote under Hard way? Maybe I'm understanding something wrong not sure:
one could also think about ignoring elements that have opted out of the auto-placement by providing cols and / or rows manually
- , and auto placement should have some way of avoiding overlaps.
Not sure about that one, what exactly do you mean? Can you provide an example?
wouldnt the number of columns and rows be determined by the
grid-auto-placement
value?
Yes, the final number of tracks depends on placement. But the number of explicit tracks doesn't, and can still be useful. Just like grid-column: auto / -1
places in the last explicit column.
Isn't that what I wrote under Hard way?
Yes sorry, I missed that sentence.
Not sure about that one, what exactly do you mean? Can you provide an example?
<div style="display: grid; grid-auto-placement-area: grid(i) / grid(i);">
<div></div>
<div style="grid-area: 1 / 1"></div>
</div>
The 1st item has i = 1
and is placed at 1 / 1
. The 2nd item has a definite position and is also placed at 1 / 1
, so they overlap.
The current spec avoids this kind of things by 1st placing items with definite positions, and then the others filling the gaps, either sparsely or densely.
- Yes, the final number of tracks depends on placement. But the number of explicit tracks doesn't, and can still be useful. Just like grid-column: auto / -1 places in the last explicit column.
Got it, agree.
- The 1st item has i = 1 and is placed at 1 / 1. The 2nd item has a definite position and is also placed at 1 / 1, so they overlap.
I personally would want to have exactly this as wanted behaviour tbh. I mean e.g.
<div style="display: grid; grid-auto-placement-area: 1 / 1;">
<div></div>
<div></div>
</div>
would also auto place all elements on top of each other and this would be the wanted behaviour. I'm generally speaking if you add an auto placement you should know how and where it places the elements onto the grid so you can actually leverage this and place elements on top of each other if you want to manually place them. But I'm open for discussion there.
Something similar could be achieved with a combinaiton of @function and selectors in sibling functions.
Problem
There currently is no way to override the auto placement behaviour inside of grids. Algorithmic placement of elements inside of a grid to achieve patterns (e.g. checkboard) is therefore only possbile by manually styling all child elements. There should be an easier way to create complex grid placements.
While discussing in #8321 I got pointed to #4002 which brings up the idea of default grids columns, rows and areas. This draft is building up on this idea.
Solution
I am thinking about the following properties + naming to solve this:
grid-auto-placement-column-start
grid-auto-placement-column-end
grid-auto-placement-column
grid-auto-placement-row-start
grid-auto-placement-row-end
grid-auto-placement-row
grid-auto-placement-area
as well as the following function:
grid()
grid-auto-placement-x
The
grid-auto-placement-x
properties are defined onto the grid element itself, specifying the auto placement override. Overrides can be plain numbers of type<integer>
e.g.This example would result in an easier form of the so called Grid Stack including
::before
and::after
. All elements would therefore be placed on 1 / 1.Setting
grid-columns
,grid-rows
,grid-areas
etc. on a grid-item automatically opts out of the auto placement as it is. Additionally auto placement overrides settings shall not be inherited.grid()
The grid function is pretty similar to
sibling-index()
discussed in #4559. Depending on the implementation details it could actually behave the same. Right now I got two different ideas how it could work, these are described in the section The two implementations.Base
The idea behind
grid()
is to get the index of the current item that's being placed inside of the grid. The function would have a similar syntax to the Relative Color Syntax by providing a parameteri
that represents the index. I was thinking about the following:This example would place elements diagonally inside of the grid.
The two implementations
Easy way
Same as
sibling-index()
just get the index of the current element that needs to be placed onto the grid.Hard way
Only takes elements into account that are actually placed onto the grid. e.g. if a sibling has
display: contents
all children of it would therefore increase the index rather than the sibling itself.If there is a case for it one could also think about ignoring elements that have opted out of the auto-placement by providing cols and / or rows manually.
With this implementation
sibling-index()
andgrid()
could exist complementary to each other.Advanced
Combining
grid()
with various functions like Stepped Value Functions andcalc()
you could e.g. create a checkboard layout in a single line: