Re: [csswg-drafts] [css-align] Rules for align/justify-self on static position of absolutely-positioned boxes need more detail

The Working Group just discussed `Rules for align/justify-self on static position of absolutely-positioned boxes need more detail`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Rules for align/justify-self on static position of absolutely-positioned boxes need more detail<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-387153116<br>
&lt;dael> TabAtkins: We've made the changes of what we've interp the earlier resolutions. Quick intro and if there's interest people can look. Not expecting resolution. Just an intro.<br>
&lt;dael> TabAtkins: Size of containing block, sizing rules for static abspos are complex. Standard LTR page and you have a standard elemnt size is constrained on left by static and on right by abspos edge. This is reasonable, it's fine. But there's questions about how to interact with alignment of staticpos. Current is different rediculous things by browser.<br>
&lt;dael> dbaron: What existing features did you use to test?<br>
&lt;dael> TabAtkins: One is swapping direction. We think that's good. Using align:content which switches where static pos and that's where it's different and bad everywhere.<br>
&lt;dael> TabAtkins: Just tested in flex, should be same for grid.<br>
&lt;dael> Rossen_: I'm not surprised it's less then interop.<br>
&lt;dael> TabAtkins: Main thing, we think browsers with blocks when you toggle direction is good. You swap the sides so right is from static and left is from abspos container. This is good. Align switching from start to end should have same swap is what we think.<br>
&lt;dael> TabAtkins: Only not covered is when you center. We think then both edges come from static pos element. So the left from ltr and right from rtl. It gives you reasonable centering. If you want other behavior you can get with left:0 right:0. Also seems less intuitive<br>
&lt;dael> Rossen_: One addition, we've discussed this in the past, esp when doing grid. Having the static position modify your containing block size, or what you use for layout position, so that you redefine space for position left and right...because layout you first measure content to get preferred sizes and then you do arrangement and then you do alignment...you should assume alignment doesn't change layout though some baselining does.<br>
&lt;dael> Rossen_: If we assume alignment doesn't reintroduce layout the problem is simple. Need to figure out how much to additionally allow alignment adjustment.<br>
&lt;dael> Rossen_: One thing we considered is if static pos is a point to where the actual static element would have been you then do your layout however you'd do it. You size and position as if block. Then you use this point and say align the box you have created and then additionally aligned about that point something else in that box. 30% additionally on the left, or align me in the center. SO you can reposition without layout changes.<br>
&lt;dael> Rossen_: That also means there's additional alignment values we'd need, but they can apply in all layout modes.<br>
&lt;dael> Rossen_: Food for thought. THis is where we ended up after investigating.<br>
&lt;dael> TabAtkins: In this case that...you're sticking with alignment can't alter. That gives you FF behavior. I suggest looking at the test case in FF and flip start to end for align and you can see why it's not really sensible.<br>
&lt;dael> TabAtkins: The original box size is okay, but as soon as you re-align it's a nonsense size. But if you direction toggle it's good.<br>
&lt;dael> dbaron: Prob other behaviors for Rossen_ variant. Incl these prop should mess with static pos at all.<br>
&lt;dael> TabAtkins: I don't particularly like. Seems odd that swapping direction is different then swapping alignment. Going from line-content:start ltr to rtl we like that. We want to make it so swapping align seems the same.<br>
&lt;dael> dbaron: But considering this align has weird consiquences like center isn't the center.<br>
&lt;dael> TabAtkins: Yes. But we think the center we proposed is a useful approximation.<br>
&lt;dbaron> s/the center/halfway between left and right/<br>
&lt;dbaron> (correction was to my line)<br>
&lt;dael> Rossen: Question. You mentioned you wanted to introduce this. Not a resolution. Pretty sure we need to work more.<br>
&lt;dael> TabAtkins: Yes. Look in details on the thread and we can discuss in future.<br>
&lt;dael> Rossen_: Okay. Anything else you want on this issue?<br>
&lt;dael> TabAtkins: Nope.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-389589936 using your GitHub account

Received on Wednesday, 16 May 2018 16:53:46 UTC