[css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent

While drafting #7612 (comment) I noticed that we are introducing a weird inconsistency in the Grid specification:

The static position [CSS2] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the content edges of the grid container. However, if the grid container parent is also the generator of the absolutely positioned element’s containing block, instead use the grid area determined in § 10.1 With a Grid Container as Containing Block.

In general, an inset:auto abspos has a static position which does not change no matter where in its ancestor chain position: relative is introduced. But here we are making the application of grid positioning properties to determining the static position conditional on whether it is also the abspos containing block. See testcase

I don't know if it's Web-compatible, but I think we should not be making it conditional. It should be unconditional: either applying always to grid children’s staticpos calculations, or never applying to them. (I prefer always; it gives the author more power.)

I'm not sure it makes sense to obey grid placement properties for the static position, if then they will be ignored for the inset-modified containing block. But no strong opinion.

One thing to keep in mind is that this will mean that a OOF-grid item can be "placed" in two different grids.

I feel very strongly that the properties should not apply to the staticpos if the parent grid container is not the abspos containing block. As Ian says, this means the positioned element would be using a single set of grid-positioning properties in two entirely different grids, which is incoherent.

I wouldn't object to never using the grid positioning properties for staticpos, but I'm also fine with the current state of affairs. I'm not sure why the conditionality is problematic.

The CSS Working Group just discussed [css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent, and agreed to the following:

RESOLVED: static position does not depend on an abspos' containing block

The full IRC log of that discussion

<astearns> topic: [css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent
<astearns> github: https://github.com//issues/7661
<fremy> fantasai: The static position of a child of a grid container ignores the grid positioning properties, unless we also the grid parent is the containing block, in which case we use the grid positioning properties
<fremy> fantasai: normally, the static position of an abspos does not depend on which element is its containing block
<fremy> fantasai: so I think it's weird and inconsistent that here we make a check for the parent being a containing block to pull more information
<fremy> fantasai: I would rather us be consistent
<fremy> fantasai: we either always pull more info, or never
<fremy> fantasai: and I have the impression that doing it always sounds a bit more useful in some cases
<fremy> iank_: one thing to keep in mind
<fremy> iank_: is that if we consider the properties all the times
<fremy> iank_: it would allow out-of-flow elements to be positinoned in the grid
<fremy> iank_: I don't have a strong opinion, but it's strange
<fremy> TabAtkins: if the grid placement properties talk about different grids, it's indeed confusing
<fremy> TabAtkins: applying never is ok for me
<fremy> TabAtkins: but applying all the time is strange, because you can end up targeting multiple grids, which is weird
<fremy> fantasai: if your containing block is a grid, and you are not statically positioned, we do use the grid positioning properties to modify the contaning block to which you are positioned
<fremy> fantasai: the case TabAtkins mentioned is when you parent is a grid, its grand parent is a grid, and you apply the positioning in one axis, that will be applied, but in the axes that are auto, then you would position relative to the parent
<fremy> fantasai: so this is indeed two different grids in this case
<Rossen_> q?
<fremy> fantasai: but I don't see why this is a problem, this sounds interesting
<fremy> astearns: but it sounds like TabAtkins might object?
<fremy> astearns: would you consider objecting to never applying?
<fremy> fantasai: no, I would not object
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10728
<fremy> fantasai: static position of a grid child does not depend on the grid placement properties
<iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10729
<fremy> dholbert: where does it go then?
<fremy> fantasai: the padding box of the grid container
<emilio> q+
<Rossen_> q+
<fremy> fantasai: not one of the areas
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<emilio> q+
<Rossen_> q+
<fremy> iank_: I think Blink might implement the double position thing
<fremy> iank_: I pasted an example above
<fremy> fantasai: I think that's cool!
<fremy> astearns: but isn't it good in few cases and wrong in many cases?
<fremy> fantasai: not clear that it's the case
<fremy> iank_: I can clarify
<fantasai> I don't think it's ever wrong. Tab just thinks it's scary
<fremy> iank_: you have two nested grids
<fremy> iank_: the positioned element is inside the inner grid
<fremy> iank_: it uses the static position of the inner grid if you don't to anything
<fremy> iank_: but if you use an inset properties, you are positioned based on the other grid
<fremy> fantasai: the static position is normally "where you would go if you are not absolute element"
<fremy> fantasai: so, I think we should probably use the values always
<fremy> fantasai: and, really, I think it makes sense
<fremy> fantasai: if you set the inset properties, you don't want the static position
<fremy> fantasai: so, yes, this will be relative to the containing block
<fremy> fantasai: if you do it in just one axis, you are combining the two behaviours
<fremy> TabAtkins: the issue I have it that the names
<fremy> TabAtkins: what if both grids define the same names, but different purposes?
<fremy> TabAtkins: I think the grid properties should only apply to the grid you are in
<fremy> TabAtkins: applying the same property to the another grid seems non-sensical
<fremy> fantasai: it's because we use a shorthand
<fremy> fantasai: but you can use one longhand for one axis
<fremy> fantasai: and another longhand for the other axis
<fremy> fantasai: and do it on purpose
<dholbert> q+
<fremy> TabAtkins: no, I would rather object
<astearns> ack emilio
<fremy> emilio: Is the current behavior interoperable?
<fremy> dholbert:in Firefox we seems to use the properties never in that case
<fantasai> we have zero interop on this btw
<Rossen_> q-
<fremy> iank_: and if you use the inner grid for the containing block?
<fantasai> all three engines differ
<fremy> iank_: it seems Gecko follows the spec
<Rossen_> q+
<fremy> emilio: ok, I think I'm convinced that the current Blink behavior is pretty weird
<fremy> emilio: and Webkit?
<fremy> fantasai: totally different
<astearns> ack dholbert
<fremy> dholbert: I have another concern
<Rossen_> q-
<fremy> dholbert: in the end example, if you specify one of the inset of the properties, it could not be a grid
<fremy> fantasai: I don't understand
<fremy> fantasai: you an change the value per axis, so if you want to position against your ancestor grid, you would not set the auto value
<emilio> q+
<fremy> fantasai: if you opt in into it, you can target one grid or the other
<fremy> dholbert: but ok, it's only weird because there is only one single property
<fremy> dholbert: depending on another property
<astearns> ack emilio
<fremy> emilio: webkit seems to honor the middle grid like firefox
<fremy> emilio: so that seems interoperable
<fremy> emilio: so all browsers do it
<fremy> emilio: I would rather keep the spec as is
<fremy> astearns: ok, so the options are "keep the spec as is" (and Blink fixes) or just remove the fact it applies anywhere
<fantasai> fremy: if it's interoperable, why change
<fantasai> fantasai: it's not interoperable
<astearns> q+ Rossen_
<astearns> q+ iank_
<fantasai> fremy: I have the impression that case where you're using the parent directly, it's interoprerable
<iank_> q+
<fantasai> fremy: so probably websites rely on that
<fantasai> iank_: static positioning is very rarely used
<fremy> iank_: I don't think websites rely on that
<astearns> ack Rossen_
<fremy> Rossen_: I am all for consistency in general
<fantasai> Rossen_: I'm all for consistency, although not using or respecting grid properties seems clinical
<fremy> Rossen_: but not applying the properties is a bit cynical here
<fremy> Rossen_: why did we decide that the properties apply in the first place?
<fremy> Rossen_: there was maybe a good reason
<fremy> Rossen_: also, we need to think about subgrids
<fremy> Rossen_: if we decide something that doesn't make sense for subgrids, we will have to revert
<fremy> Rossen_: static position is odd in general, so I don't think the oddness noticed by that is that strange
<fremy> Rossen_: just using inline parents and different writing modes would probably also get you very strange cases
<fremy> Rossen_: and I don't see why this particular case is more weird than they are in general
<fremy> Rossen_: so, to sum up, if we want to change the spec, can we weight our "weirdness" against the initial decision
<fremy> TabAtkins: subgrid should not be conflicting with this
<fremy> TabAtkins: the reasoning we hand for supporting the properties was that we should pretend the element was positioned normally
<fremy> TabAtkins: but it doesn't serve the same purpose as in block layout because there are variations anyway
<astearns> ack iank_
<fremy> TabAtkins: so I don't think the reasoning is not strongly valid, and I would be happy to drop that, and make things as simple as possible
<fremy> iank_: If you do this change, I don't expect a compat issue
<fremy> iank_: but positioning the abspos in the containing block in an area is very useful
<Rossen_> s/cynical/clinical/
<fremy> iank_: this not as much
<astearns> ack fantasai
<fremy> fantasai: I think positioning where the item would have been
<dholbert> here's an example of us placing the item "close to where it would have been" when it's not the direct parent: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10731
<fremy> fantasai: it's what static position
<dholbert> (I think)
<fremy> TabAtkins: the reason for the current spec is that we did not want the two grids use the same shorthand
<fremy> fantasai: ok, possibly
<fremy> fantasai: but I still value the initial reasoning
<fremy> fantasai: and we should be consistent
<fremy> fantasai: and if we allow this, it gives new possibilities to the author
<fremy> fantasai: the reverse is removing options for the author
<fremy> Rossen_: I agree with what fantasai said on the initial reasoning value
<iank_> q+
<fremy> fantasai: for this aspect of grid, it's possible to make it work in an author
<fremy> fantasai: you can just not set the values
<astearns> ack iank_
<fremy> TabAtkins: or you can use anchor positioning ;)
<fremy> iank_: to return to the subgrid case
<dholbert> (sorry, I meant to paste https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/10734 above; I added a code-comment to explain slightly better)
<fremy> iank_: for subgrids, static positioning should be what?
<fremy> fantasai: very similar for subgrids to the nested grid case
<fremy> iank_: so, the axes don't apply to the subgrid directly, all is on the layout grid, correct
<fremy> iank_: ?
<fremy> fantasai: yes
<fantasai> s/we should be consistent/in the rest of CSS, the static position logic is never conditional on which element is the abspos containing block, and we should keep that invariant/
<fremy> dholbert: we can sort of do that by using a wrapper
<fremy> dholbert: so, if we remove the ability to respect the properties
<fremy> dholbert: you can use the wrapper
<fantasai> s/you can just not set the values/if you don't want the grid positioning properties have effect on staticpos, don't set them/
<fremy> Rossen_: sure, you can always use a wrapper
<fremy> Rossen_: but the intent of the property was to do that by default
<fremy> dholbert: but the wrapper makes the intent clear
<fremy> dholbert: and it forces the consistency
<fremy> dholbert: so I am not against that "clarifying" wrapper
<fremy> Rossen_: and don't like that complexity, but I agree it exists in multiple places
<fremy> fantasai: I think we should resolve on whether we want to use the properties at all
<fremy> fantasai: then we work in the details
<fremy> TabAtkins: no, I disagree with that framing
<fremy> TabAtkins: we have two constraints
<emilio> +1 to tab
<fremy> TabAtkins: and only never applying fits both constraints
<fremy> TabAtkins: so, can we handle everything together, and just specify what we want
<fremy> astearns: ok, first resolution
<fremy> fantasai: proposed resolution: static position does not depend on the abspos containing block
<fremy> dholbert: well, some properties do affect this
<fremy> iank_: we will discuss this just after, this is the next issue
<fremy> fantasai: the parent will affect things
<fremy> fantasai: but the containing block not
<fremy> dholbert: ok, yes, I think you are right
<fremy> astearns: ok, can we agree on that proposed resolution?
<fremy> astearns: any objection?
<fremy> RESOLVED: static position does not depend on an abspos' containing block
<fremy> fantasai: so, now, does the static position of a grid child depends on the grid properties, or do we ignore them
<fremy> astearns: and if we choose not to ignore them, then we have the weird case
<fremy> iank_: considering this further, I don't care
<fremy> iank_: my only issue was the current spec
<fremy> fantasai: we can do a strawpoll
<fantasai> 1. Ignore grid-positioning properties when finding staticpos of grid children
<fantasai> 2. Honor grid-positioning properties when finding staticpos of grid children
<TabAtkins> 1
<fantasai> 2
<dholbert> 1
<Rossen_> 2
<astearns> 1
<rego> 1
<fremy> 2 (I have wanted that in the past, I am pretty sure)
<emilio> 1
<emeyer> 2
<iank_> 3
<florian> 0
<TabAtkins> (Remember that anchor positioning gives a strictly more powerful ability than static pos, if you do want that fucntionality.)
<rachelandrew> 1
<hober> abstain
<fantasai> fremy: I'm fairly sure I wanted that when authoring stuff
<fantasai> ... this is what's implemented today, why we would we change that if I wanted it?
<fantasai> ... for at least the normal level, I still want to use the properties there
<fantasai> ... nobody really cares about the weird nesting
<fantasai> fantasai: You can just not use static positioning if your parent is also the abspos
<fantasai> iank_: I want to hear from rachelandrew and emeyer
<fantasai> rachelandrew: Would be good to request use cases. I can't think off the top of my head, but doesn't mean there aren't any
<fantasai> emeyer: to me, I'm with rachelandrew on this. It wasn't a strong opinion, and I think it would be beneficial to come up with use cases
<fantasai> emeyer: and see what authors think
<fantasai> emeyer: I voted opposite in part because it feels slightly more intuitive that if you're lookng at grid children, you should look at grid positioning properties. You're in grid context.
<fantasai> emeyer: not strong opinion, but feels right
<fantasai> emeyer: would be interested to see use cases that depend on one or other behavior
<fantasai> emeyer: that would help a great deal
<fantasai> astearns: My opinion is that having unexpected behavior and then deciding what one might use it for is probably not the best way of collecting use cases
<fremy> fantasai: I want to add some other points
<fremy> fantasai: If we make it work, you can always disable it
<fremy> fantasai: Because you can not set them if you don't want
<fremy> fantasai: Also, right now we focus on the case of two nested grids
<fremy> fantasai: but in general, the containing block does not have to be a grid
<fremy> fantasai: it could be a block or a flex
<fremy> fantasai: but you might want to have the control in those cases
<fremy> fantasai: yes, if you have two grids, it can be a bit confusing
<fremy> fantasai: but let's not forget the general case, where the properties are ignored just because the containing block is not a grid
<fremy> fantasai: that would not change
<fremy> fantasai: and I think we should focus about, are there use cases where your parent is a grid
<Rossen_> +1 to the above reasoning. The two nested grids is an edge case that sways the decision artificially
<fremy> emeyer: it's difficult to say on the spot
<fremy> emeyer: if we want to ask for opinions, we need examples
<TabAtkins> Also important: whether these use-cases are better served by anchor positioning, because they generalize to "positioned containing block is elswhere, but I want to align in some way to different element". Static position usage is *almost always* a funky hack attempting to achieve anchor positioning.
<fremy> astearns: ok, we will take this back to the issue, and decide based on these examples

As I stated in the meeting (and was sidelined for), I will object to an outcome where static position and normal position both pay attention to the grid positioning properties, possibly from different grids.

So, given the resolution we did get, the only edits that will avoid objection are to say that the grid positioning properties don't affect static position at all.

As mentioned in the minutes, the intent is to work through examples and use cases in this issue now. I think edits to the spec should wait on this.

Adgenda+ to bring this on folks radar again. The longer we leave this the more likely we'll be compat constrained.

@tabatkins

So grid is in a super strange place at the moment. I was initially agnostic about which was this should go - but now I suspect we want to go with @tabatkins position.

Lets say you have:

<!DOCTYPE html>
<style>
.grid {
  display: inline-grid;
  border: solid 5px;
  padding: 10px;
}
.oof {
  position: absolute;
  width: 15px;
  height: 15px;
  background: lime;
}
</style>

<div class="grid" style="position: static;">
  <div class="oof"></div>
</div>

<div class="grid" style="position: relative;">
  <div class="oof"></div>
</div>

<div class="grid" style="position: relative;">
  <div class="oof" style="grid-row: 1; grid-column: 1;"></div>
</div>

With grid (1) we'll use the resolution in #3020 (comment) and use the content-box, as the containing-block isn't the grid.

https://drafts.csswg.org/css-grid-1/#static-position

"The static position [CSS2] of an absolutely-positioned child of a grid container is determined as if it were the sole grid item in a grid area whose edges coincide with the content edges of the grid container."

With grid (2) as the grid is the containing-block we'll use the padding-box for the static-position (this strikes me as incorrect). As we invoke:

However, if the grid container parent is also the generator of the absolutely positioned element’s containing block, instead use the grid area determined in § 9.1 With a Grid Container as Containing Block.

And grid (3) we invoke the above logic, but use are actually placed in a useful area.

For grid (2) re-using the contianing-block logic is super strange?

[css-grid] Use content-box always for static position.

[css-grid-1][css-grid-2] Remove staticpos dependency on grid position…

[css-grid] Use content-box always for static position.

Chromium found the newly specced behavior to be Web-incompatible, see https://issues.chromium.org/issues/40272496. Reopening.

Navigation Menu

Repository navigation

[css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent #7661

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent #7661

Description

Activity

Loirooriol commented on Aug 30, 2022

bfgeek commented on Aug 30, 2022

tabatkins commented on Sep 7, 2022

css-meeting-bot commented on Sep 16, 2022

tabatkins commented on Sep 16, 2022

astearns commented on Sep 16, 2022

bfgeek commented on May 9, 2023

bfgeek commented on May 10, 2023

19 remaining items

fantasai commented on Apr 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions