[css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent #7661
Comments
|
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
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. |
|
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
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:
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? |
|
The CSS Working Group just discussed The full IRC log of that discussion<TabAtkins> iank_: Want to get this on radars<TabAtkins> iank_: We need to resolve it for subgrid <TabAtkins> iank_: Today in the spec we will change the static position depending on if the grid is also the abspos CB <TabAtkins> iank_: So if the grid is an abspos CB, its abspos child will "palce itself in the grid" and use that area for its cb <TabAtkins> iank_: If the grid isn't an abspos CB the abspos will use the content box <TabAtkins> iank_: Blink had a bug where we started placing OOF items twice <TabAtkins> iank_: Regardless of whether grid was a CB, we'd figure the staticpos from the grid area, and then it would get positioned again if it was a CB <TabAtkins> iank_: Three options <TabAtkins> iank_: One is align impls along the spec as-is. That would undo the previous reoslution, that the staticpos doesn't depend on the abspos CB. <TabAtkins> iank_: Two is to get rid of the staticpos placement, and always use the content box. <TabAtkins> iank_: Three is to place the abspos twice. Once in the grid for the staticpos, once in the actual CB. <TabAtkins> iank_: This gets complciated for subgrid, it'll get placed in the subgrid for one and the grid for the other. <TabAtkins> iank_: This'll also undo the previous resolution <TabAtkins> fantasai: I'm not sure what you mean by "place an item twice" <TabAtkins> iank_: Imagine a grid container that is the abspos parent but not its CB <miriam> ack fantasai <Zakim> fantasai, you wanted to ask what is meant by placing twice <TabAtkins> iank_: You'd place the abspos in that grid to pick up its staticpos, and then in its CB it'll get actually placed. <TabAtkins> fantasai: What i'm confuse d about - in a given axis, you're either placing it wrt static pos or wrt the abspos CB. What do you mean by doing both? <TabAtkins> iank_: So if you have an abspos it'll pick up its staticpos rect from the parent, say top and bottom aren't set so it uses that rect. Then if left and right are set, it's positioned wrt the actual CB. <fantasai> TabAtkins: I'm confused, isn't that how abspos works inevery case? <TabAtkins> iank_: Say you have 'column: 2' on the abspos. It'll get placed in the subgrid for static pos and in the outer grid for CB. <TabAtkins> TabAtkins: Ahhhhh, you meant it invokes GRID PLACEMENT twice, in different grids. <TabAtkins> iank_: Yes, sorry, that's what I meant by placement. <TabAtkins> miriam: So plan is to continue discussion in the issue and bring it up in two weeks for reslution. <TabAtkins> iank_: Yes. My preferred is to not do grid-placement for the static pos, always use the content box. <TabAtkins> iank_: If people have strong opinions otherwise, make yourself known. <TabAtkins> fantasai: Could you clarify the writing modes detail? <TabAtkins> iank_: Yeah it's not a big issue, i'll clarify in the issue. |
|
To clarify the three options: Option (1) - Keep the spec as is. Note this will require undoing the previous resolution as the current algorithm depends on what the abspos containing block is. If the abspos container, is also the containing block, pick up the static-position by invoking grid-placement. Option (2) - Use the content-box always. We wouldn't invoke the grid-placement algorithm to pick up the static-position. This option aligns with flex - nothing magical happens. Option (3) - Always invoke grid-placement to acquire the static-position. This would require undoing the resolution in #3020 (as invoking grid-placement for abspos uses the padding-box by default). |
|
My personal preference is Option (2) at the moment. |
|
Also my preference. I have a strong preference against potentially invoking the grid-placement algo on two distinct grid containers. It wouldn't create the incoherent situation of using the same grid-placement property on two different grids that I objected to before, but it would still be confusing if grid-row was resolved against one grid and grid-column against another, if one inset axis was specified and the other was auto. |
This seems probably like the best outcome to me, too. Just to clarify, though are you saying that all three grids in your testcase should look the same, and should do so regardless of the That seems probably reasonable to me. The (maybe acceptable) drawbacks that I see are: (B) For a start-aligned abspos grid item with the grid as its abspos containing block: (C) (There's also obviously some compat risk with changing behavior here, since the current behavior is interoperable. Maybe this is edge-casey enough that the impact will be minimal though.) |
Thanks correct. I suspect this will be web-compatible as folks generally don't rely on static-position that often, and likely less so with grid. We are happy to make the change to test it out. |
|
Thanks! I'm on board with option (2), then. |
|
Fwiw, I disagree with Tab on this one. I don't think it's a problem for each axis to be positioned relative to a different grid. I also agree with @dholbert's concern that disabling the grid positioning properties for static positioning results in more of a change in position than may be expected or desired, and it's inconsistent with what the static position is supposed to represent. My position is that:
I don't think this is confusing, and it is strictly more powerful than ignoring the grid positioning properties in staticpos, which I'm sure authors will find interesting uses for. |
This isn't how static position works for abspos children in a grid. It'll invoke https://drafts.csswg.org/css-grid-1/#abspos-items which for "auto" grid-positions will use the padding-box (not content-box). Ian |
|
Also, I think that in general everything people want to achieve with static positioning is achieved better, easier, and more reliably with anchor positioning. We obviously need to keep a lot of static position behavior around for compat reasons, but where we're not constrained by compat we should be doing the easiest possible thing, rather than trying to put a lot of effort into figuring out some restricted sort of "most likely to be useful" behavior (with no guarantees it's actually useful). |
|
@bfgeek I think that's a mistake and Grid should have been consistent with Flexbox (and every other layout system) in this regard. That is, it makes sense for abspos positioning to use the padding edge (and is correct in that respect), but not for static positioning. |
|
The CSS Working Group just discussed The full IRC log of that discussion<emeyer> TabAtkins: We discussed a few weeks ago and took it back to the issue<emeyer> …Question is, how to we calculate the static position of absolutely positioned children of grid containers? <emeyer> …Option 1: keep spec as-is, where we apply grid properties to find a containing block <emeyer> …(more details that the scribe lost in terminology) <emeyer> Option 2: Simplify in this case and use the containing box of the parent <fantasai> s/containing/content/ <fantasai> s/containing block/staticpos containing block only if the parent is the abspos containing block/ <Rossen_> q? <fserb> q- <fantasai> scribe+ <TabAtkins> EN-us-csswg <fantasai> Option 3: apply grid properties to find staticpos containing block always (when the parent is a grid) <Rossen_> ack fantasai <emeyer> fantasai: I opened this originally because the spec as is, is not a behavior we have anywhere else <emeyer> …If you have a static position, that’s your position regardless <Rossen_> q? <emeyer> …Between the other two behaviors, we can use the content box edge like in flexbox, or use grid positioning to contain the static position containing block <TabAtkins> q+ <emeyer> …I think the second options is more powerful and closer to the intent of static positioning <emeyer> …I think we should honor the grid positioning properties <emeyer> …Ian did raise that the spec uses padding box as a parent, which is weird and unusual <emeyer> …Regardless of what we do, we shoul use the content box and not the padding box <emeyer> iank_: The way the spec is phrased, it gets invoked when auto is in play <emeyer> TabAtkins: My main objection here is grid positioning proeprties are semantically a unit, giving a position in 2D <emeyer> …If we go with options 1 or 3, you can be invoking grid-row to figure a position, but grid-column in a different grid <Rossen_> ack TabAtkins <emeyer> …It no longer becomes a simple 2D, it’s not semantically coherent <emeyer> …I don’t think there’s a reasonable way to resolve this <emeyer> …I think static positioning should ignore grid properties and be simpler <emeyer> …Anchor positioning is the better solution here anyway; I don’t think there’s a strong use case for static positioning of grid pieces in a works where anchor positioning exists <emeyer> …I think we should simplfy the model and call it a day <emeyer> fantasai: I don’t think we can resolve today; what I’d like to get is author feedback here <emeyer> iank_: This is somewhat blocking our subgrid implementation, so we’d like to resolve this soon <emeyer> …Don’t want this to drag out for months <emeyer> Rossen_: We’ll start with this next week <TabAtkins> Note that I will not be here next week, I'll be over the Pacific ocean during the call. <emeyer> …Hopefully we can get a resolution next week <Rossen_> Topic end |
|
I synced with @bfgeek just now. My understanding is that, as compared with option 3, option 2 is:
(And no one is advocating for option 1) Therefore I think we should go with option 2. |
|
Summary Current behavior (per spec) is that the static position of a grid child depends on whether its parent is the abspos containing block or not. See simplified testcase from above. No other layout model changes the static position based on the qualities of the abspos containing block, so we have agreement that this shouldn't be conditional. The two behaviors it switches between are
(Specifically, it uses the second behavior iff the parent is also the abspos containing block. See testcase.) Options To make the static position consistent regardless of the abspos containing block, we need to choose one behavior to apply always. The two options advocated for in this issue are:
Note the behaviors here are per-axis, and only apply if the |
|
The CSS Working Group just discussed
The full IRC log of that discussion<fantasai> summary -> https://github.com//issues/7661#issuecomment-1587880994<emilio> iank_: restating previous conversations. Two options: always use content-box, or always use grid-positioning properties <emilio> ... two weeks ago people were asking for use cases <emilio> ... I don't think anybody came back with use cases for always using grid-positioning <emilio> ... me and tab have a preference for content-box, fantasai has a preference for using the properties <emilio> fantasai: we have agreement on if the grid properties are auto then we use the content-box <emilio> iank_: that might be more complicated because of how those work <emilio> ... because those insert additional lines for the purposes of abspos <emilio> ... so would like to keep that separate <emilio> Rossen_: so we want to go with option (2), which is always use content-box (option (1) is off the table) <emilio> q+ <emilio> iank_: I'd like to propose going for (2), I don't think there are use cases for (3) <Rossen_> q+ <Rossen_> ack emilio <TabAtkins> emilio: Echo slight support for going for the content box <fantasai> scribe+ TabAtkins <chrishtr> +1 to option 2 (content box) <TabAtkins> emilio: Seems there's no use-cases for grid, seems determining the static position form grid porpertiers can be a rabbit hole of interop not worth getting into <TabAtkins> emilio: If always using the content box works, then good <emilio> Rossen_: quick q. also supportive of option (2) tho. If you want an annotation on the box that sits on top of everything else like a semi-transparent number <TabAtkins> Rossen_: qq, if you wanted an annotation on the box that sits on top of everything else, like a semi-transparent number <emilio> ... let's say you want to number your grid cells <emilio> ... is my assumption correct that if you want to achieve the same effect you'd have to say which line you're positioning to in the grid and then use that as your left and top? <emilio> iank_: right you need to make the grid the containing block yeah, and set top: 0 left: 0 <emilio> Rossen_: what about auto placement? Where would that end up? <emilio> iank_: you can't (today) setting auto placement on an abspos, you'd need to wrap it in a grid item <emilio> Rossen_: can we make that the default behavior? <emilio> iank_: we don't invoke auto placement for out of flows <emilio> ... you need to be explicit to pick up the grid area <emilio> Rossen_: ok in that case I'm good with option 2 as well <emilio> RESOLVED: Go with the content-box (option 2) <emilio> iank_: final note: we'll do this change behind a kill-switch in case people rely on the weird behavior, can come back to the group if the change goes wrong |
w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. web-platform-tests/wpt#40710 (comment) w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: I951319f44f190a050fdbd77f5ccae97ad96da626 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4740396 Reviewed-by: Alison Maher <almaher@microsoft.com> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1178125}
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
This patch flips grid layout to always use the content-box for determining the static position. This is behind the LayoutNewGridStaticPosition flag in case we need to disable this logic for unexpected reasons. w3c/csswg-drafts#7661 (comment) Bug: 1454831 Change-Id: Ida72fe3e209d5260c4db95e15c40ae88da9f45f9
While drafting #7612 (comment) I noticed that we are introducing a weird inconsistency in the Grid specification:
In general, an
inset:autoabspos has a static position which does not change no matter where in its ancestor chainposition: relativeis 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 testcaseI 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.)
The text was updated successfully, but these errors were encountered: