Re: [csswg-drafts] [css-grid] Decorative grid-cell pseudo-elements (#499)

@fantasai
>     * `::grid-area()` pseudo-element takes the same values as the `grid-area` property, minus auto-placement values

What are the reasons auto-placement is disallowed?

>     * `::grid-area()` arguments can also use nth-child syntax in place of `<integer>`.

`n` is ambiguous since it's also a valid line name.

>     * `::grid-area()` with arguments that reference the same area have the same identity

That's good, but web developers have expressed a need for multiple pseudos (#6169 etc).  The additional effort to implement that is negligible, so I'm sad that use case isn't addressed. E.g. something like `::grid-area(ident-1, 1 / 2n / 3 / span 2) {...}`  `::grid-area(ident-2, 1 / 2n / 3 / span 2) {...}` would create two separate pseudos in the same area(s).

>     * `::grid-area()` without arguments matches every grid-area pseudo-element

Presumably with lower specificity?
Does `::grid-area() { content:""; }` by itself create a pseudo? If so, what's its area?

>     * a grid-area pseudo takes up space for the purposes of the auto-placement algorithm the same as any other item

That seems like a big mistake to me. I think most use cases would be better served if decorative pseudos **don't** mess with the grid layout at all.  I think this should be optional, and the default should be that `::grid-area` pseudos don't take up space in the grid (i.e. regular grid items are "placed on top" of the decorative items).

I think it would be useful to have a property for this, something like `grid-fill: auto | none | fill`, that can be used on non-pseudo grid items too (this has already been requested by web developers).  Then you can make some child elements "decorative" with `grid-fill: none` and not be constrained to what can be produced with `content`. (`auto` would resolve to `none` for grid-area pseudos, and to `fill` for regular grid items).

>     * box order defined as a child before everything in the grid (including ::before/::marker/etc.)

That seems like an odd order to me. Is there a reason you want that order? 
`::marker, ::before, ::grid-area pseudos, children, ::after` seems more natural to me. They should at least come after the grid container's ::marker (note that grid containers don't support ::marker yet though).

***

I don't understand how this proposal can be implemented though.  Specifically, the nth-child syntax when combined with "a grid-area pseudo takes up space" seems like it could easily create an infinite number of pseudos.  A pseudo that takes up space may create new tracks in the grid, i.e. new grid areas, creating a circular dependency. It would be great if you could explain what stops that from happening. (I need detailed and ordered steps of when to create the pseudo in relation to, and how it interacts with, establishing the [implicit grid](https://drafts.csswg.org/css-grid/#implicit-grids) and the [grid item placement steps](https://drafts.csswg.org/css-grid/#auto-placement-algo).)

(A pseudo that doesn't take up space doesn't have that problem since it's constrained to only match the grid tracks created by other items that does.)

-- 
GitHub Notification of comment by MatsPalmgren
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/499#issuecomment-955791366 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 31 October 2021 21:05:49 UTC