- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Sep 2022 19:31:47 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <astearns> topic: [css-grid-1] Application of grid-positioning properties to static position of grid children is inconsistent<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/7661<br> <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<br> <fremy> fantasai: normally, the static position of an abspos does not depend on which element is its containing block<br> <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<br> <fremy> fantasai: I would rather us be consistent<br> <fremy> fantasai: we either always pull more info, or never<br> <fremy> fantasai: and I have the impression that doing it always sounds a bit more useful in some cases<br> <fremy> iank_: one thing to keep in mind<br> <fremy> iank_: is that if we consider the properties all the times<br> <fremy> iank_: it would allow out-of-flow elements to be positinoned in the grid<br> <fremy> iank_: I don't have a strong opinion, but it's strange<br> <fremy> TabAtkins: if the grid placement properties talk about different grids, it's indeed confusing<br> <fremy> TabAtkins: applying never is ok for me<br> <fremy> TabAtkins: but applying all the time is strange, because you can end up targeting multiple grids, which is weird<br> <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<br> <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<br> <fremy> fantasai: so this is indeed two different grids in this case<br> <Rossen_> q?<br> <fremy> fantasai: but I don't see why this is a problem, this sounds interesting<br> <fremy> astearns: but it sounds like TabAtkins might object?<br> <fremy> astearns: would you consider objecting to never applying?<br> <fremy> fantasai: no, I would not object<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10728<br> <fremy> fantasai: static position of a grid child does not depend on the grid placement properties<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10729<br> <fremy> dholbert: where does it go then?<br> <fremy> fantasai: the padding box of the grid container<br> <emilio> q+<br> <Rossen_> q+<br> <fremy> fantasai: not one of the areas<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <emilio> q+<br> <Rossen_> q+<br> <fremy> iank_: I think Blink might implement the double position thing<br> <fremy> iank_: I pasted an example above<br> <fremy> fantasai: I think that's cool!<br> <fremy> astearns: but isn't it good in few cases and wrong in many cases?<br> <fremy> fantasai: not clear that it's the case<br> <fremy> iank_: I can clarify<br> <fantasai> I don't think it's ever wrong. Tab just thinks it's scary<br> <fremy> iank_: you have two nested grids<br> <fremy> iank_: the positioned element is inside the inner grid<br> <fremy> iank_: it uses the static position of the inner grid if you don't to anything<br> <fremy> iank_: but if you use an inset properties, you are positioned based on the other grid<br> <fremy> fantasai: the static position is normally "where you would go if you are not absolute element"<br> <fremy> fantasai: so, I think we should probably use the values always<br> <fremy> fantasai: and, really, I think it makes sense<br> <fremy> fantasai: if you set the inset properties, you don't want the static position<br> <fremy> fantasai: so, yes, this will be relative to the containing block<br> <fremy> fantasai: if you do it in just one axis, you are combining the two behaviours<br> <fremy> TabAtkins: the issue I have it that the names<br> <fremy> TabAtkins: what if both grids define the same names, but different purposes?<br> <fremy> TabAtkins: I think the grid properties should only apply to the grid you are in<br> <fremy> TabAtkins: applying the same property to the another grid seems non-sensical<br> <fremy> fantasai: it's because we use a shorthand<br> <fremy> fantasai: but you can use one longhand for one axis<br> <fremy> fantasai: and another longhand for the other axis<br> <fremy> fantasai: and do it on purpose<br> <dholbert> q+<br> <fremy> TabAtkins: no, I would rather object<br> <astearns> ack emilio<br> <fremy> emilio: Is the current behavior interoperable?<br> <fremy> dholbert:in Firefox we seems to use the properties never in that case<br> <fantasai> we have zero interop on this btw<br> <Rossen_> q-<br> <fremy> iank_: and if you use the inner grid for the containing block?<br> <fantasai> all three engines differ<br> <fremy> iank_: it seems Gecko follows the spec<br> <Rossen_> q+<br> <fremy> emilio: ok, I think I'm convinced that the current Blink behavior is pretty weird<br> <fremy> emilio: and Webkit?<br> <fremy> fantasai: totally different<br> <astearns> ack dholbert<br> <fremy> dholbert: I have another concern<br> <Rossen_> q-<br> <fremy> dholbert: in the end example, if you specify one of the inset of the properties, it could not be a grid<br> <fremy> fantasai: I don't understand<br> <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<br> <emilio> q+<br> <fremy> fantasai: if you opt in into it, you can target one grid or the other<br> <fremy> dholbert: but ok, it's only weird because there is only one single property<br> <fremy> dholbert: depending on another property<br> <astearns> ack emilio<br> <fremy> emilio: webkit seems to honor the middle grid like firefox<br> <fremy> emilio: so that seems interoperable<br> <fremy> emilio: so all browsers do it<br> <fremy> emilio: I would rather keep the spec as is<br> <fremy> astearns: ok, so the options are "keep the spec as is" (and Blink fixes) or just remove the fact it applies anywhere<br> <fantasai> fremy: if it's interoperable, why change<br> <fantasai> fantasai: it's not interoperable<br> <astearns> q+ Rossen_<br> <astearns> q+ iank_<br> <fantasai> fremy: I have the impression that case where you're using the parent directly, it's interoprerable<br> <iank_> q+<br> <fantasai> fremy: so probably websites rely on that<br> <fantasai> iank_: static positioning is very rarely used<br> <fremy> iank_: I don't think websites rely on that<br> <astearns> ack Rossen_<br> <fremy> Rossen_: I am all for consistency in general<br> <fantasai> Rossen_: I'm all for consistency, although not using or respecting grid properties seems clinical<br> <fremy> Rossen_: but not applying the properties is a bit cynical here<br> <fremy> Rossen_: why did we decide that the properties apply in the first place?<br> <fremy> Rossen_: there was maybe a good reason<br> <fremy> Rossen_: also, we need to think about subgrids<br> <fremy> Rossen_: if we decide something that doesn't make sense for subgrids, we will have to revert<br> <fremy> Rossen_: static position is odd in general, so I don't think the oddness noticed by that is that strange<br> <fremy> Rossen_: just using inline parents and different writing modes would probably also get you very strange cases<br> <fremy> Rossen_: and I don't see why this particular case is more weird than they are in general<br> <fremy> Rossen_: so, to sum up, if we want to change the spec, can we weight our "weirdness" against the initial decision<br> <fremy> TabAtkins: subgrid should not be conflicting with this<br> <fremy> TabAtkins: the reasoning we hand for supporting the properties was that we should pretend the element was positioned normally<br> <fremy> TabAtkins: but it doesn't serve the same purpose as in block layout because there are variations anyway<br> <astearns> ack iank_<br> <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<br> <fremy> iank_: If you do this change, I don't expect a compat issue<br> <fremy> iank_: but positioning the abspos in the containing block in an area is very useful<br> <Rossen_> s/cynical/clinical/<br> <fremy> iank_: this not as much<br> <astearns> ack fantasai<br> <fremy> fantasai: I think positioning where the item would have been<br> <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<br> <fremy> fantasai: it's what static position<br> <dholbert> (I think)<br> <fremy> TabAtkins: the reason for the current spec is that we did not want the two grids use the same shorthand<br> <fremy> fantasai: ok, possibly<br> <fremy> fantasai: but I still value the initial reasoning<br> <fremy> fantasai: and we should be consistent<br> <fremy> fantasai: and if we allow this, it gives new possibilities to the author<br> <fremy> fantasai: the reverse is removing options for the author<br> <fremy> Rossen_: I agree with what fantasai said on the initial reasoning value<br> <iank_> q+<br> <fremy> fantasai: for this aspect of grid, it's possible to make it work in an author<br> <fremy> fantasai: you can just not set the values<br> <astearns> ack iank_<br> <fremy> TabAtkins: or you can use anchor positioning ;)<br> <fremy> iank_: to return to the subgrid case<br> <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)<br> <fremy> iank_: for subgrids, static positioning should be what?<br> <fremy> fantasai: very similar for subgrids to the nested grid case<br> <fremy> iank_: so, the axes don't apply to the subgrid directly, all is on the layout grid, correct<br> <fremy> iank_: ?<br> <fremy> fantasai: yes<br> <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/<br> <fremy> dholbert: we can sort of do that by using a wrapper<br> <fremy> dholbert: so, if we remove the ability to respect the properties<br> <fremy> dholbert: you can use the wrapper<br> <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/<br> <fremy> Rossen_: sure, you can always use a wrapper<br> <fremy> Rossen_: but the intent of the property was to do that by default<br> <fremy> dholbert: but the wrapper makes the intent clear<br> <fremy> dholbert: and it forces the consistency<br> <fremy> dholbert: so I am not against that "clarifying" wrapper<br> <fremy> Rossen_: and don't like that complexity, but I agree it exists in multiple places<br> <fremy> fantasai: I think we should resolve on whether we want to use the properties at all<br> <fremy> fantasai: then we work in the details<br> <fremy> TabAtkins: no, I disagree with that framing<br> <fremy> TabAtkins: we have two constraints<br> <emilio> +1 to tab<br> <fremy> TabAtkins: and only never applying fits both constraints<br> <fremy> TabAtkins: so, can we handle everything together, and just specify what we want<br> <fremy> astearns: ok, first resolution<br> <fremy> fantasai: proposed resolution: static position does not depend on the abspos containing block<br> <fremy> dholbert: well, some properties do affect this<br> <fremy> iank_: we will discuss this just after, this is the next issue<br> <fremy> fantasai: the parent will affect things<br> <fremy> fantasai: but the containing block not<br> <fremy> dholbert: ok, yes, I think you are right<br> <fremy> astearns: ok, can we agree on that proposed resolution?<br> <fremy> astearns: any objection?<br> <fremy> RESOLVED: static position does not depend on an abspos' containing block<br> <fremy> fantasai: so, now, does the static position of a grid child depends on the grid properties, or do we ignore them<br> <fremy> astearns: and if we choose not to ignore them, then we have the weird case<br> <fremy> iank_: considering this further, I don't care<br> <fremy> iank_: my only issue was the current spec<br> <fremy> fantasai: we can do a strawpoll<br> <fantasai> 1. Ignore grid-positioning properties when finding staticpos of grid children<br> <fantasai> 2. Honor grid-positioning properties when finding staticpos of grid children<br> <TabAtkins> 1<br> <fantasai> 2<br> <dholbert> 1<br> <Rossen_> 2<br> <astearns> 1<br> <rego> 1<br> <fremy> 2 (I have wanted that in the past, I am pretty sure)<br> <emilio> 1<br> <emeyer> 2<br> <iank_> 3<br> <florian> 0<br> <TabAtkins> (Remember that anchor positioning gives a strictly more powerful ability than static pos, if you do want that fucntionality.)<br> <rachelandrew> 1<br> <hober> abstain<br> <fantasai> fremy: I'm fairly sure I wanted that when authoring stuff<br> <fantasai> ... this is what's implemented today, why we would we change that if I wanted it?<br> <fantasai> ... for at least the normal level, I still want to use the properties there<br> <fantasai> ... nobody really cares about the weird nesting<br> <fantasai> fantasai: You can just not use static positioning if your parent is also the abspos<br> <fantasai> iank_: I want to hear from rachelandrew and emeyer<br> <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<br> <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<br> <fantasai> emeyer: and see what authors think<br> <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.<br> <fantasai> emeyer: not strong opinion, but feels right<br> <fantasai> emeyer: would be interested to see use cases that depend on one or other behavior<br> <fantasai> emeyer: that would help a great deal<br> <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<br> <fremy> fantasai: I want to add some other points<br> <fremy> fantasai: If we make it work, you can always disable it<br> <fremy> fantasai: Because you can not set them if you don't want<br> <fremy> fantasai: Also, right now we focus on the case of two nested grids<br> <fremy> fantasai: but in general, the containing block does not have to be a grid<br> <fremy> fantasai: it could be a block or a flex<br> <fremy> fantasai: but you might want to have the control in those cases<br> <fremy> fantasai: yes, if you have two grids, it can be a bit confusing<br> <fremy> fantasai: but let's not forget the general case, where the properties are ignored just because the containing block is not a grid<br> <fremy> fantasai: that would not change<br> <fremy> fantasai: and I think we should focus about, are there use cases where your parent is a grid<br> <Rossen_> +1 to the above reasoning. The two nested grids is an edge case that sways the decision artificially<br> <fremy> emeyer: it's difficult to say on the spot<br> <fremy> emeyer: if we want to ask for opinions, we need examples<br> <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.<br> <fremy> astearns: ok, we will take this back to the issue, and decide based on these examples<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7661#issuecomment-1249731234 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 September 2022 19:31:49 UTC