[css-align] Rules for align/justify-self on static position of absolutely-positioned boxes need more detail #1432

dbaron · 2017-05-20T22:26:57Z

The alignment spec has rules for applying justify-self to the static position of absolutely-positioned boxes and similar for align-self. This section is quite opaque, and could perhaps use an introduction.

I think what this section is trying to say is that for absolutely positioned elements that use their static position, they're aligned within their static-position rectangle (formerly "hypothetical box") using the align-self and justify-self properties. If that's the idea, it would be nice to have a little bit of prose saying that, and explaining the relationship to the previous section.

But there are also a number of other issues:

unlike the two sections (for blocks and absolutely-positioned elements) preceding each of these sections, they don't specify any rules about overriding the rules for over-constrained situations, and therefore if the intent is as described above, I think it doesn't actually work
I don't understand what " The box’s margin box after laying out the box, treated as fixed-size for the purpose of alignment." means
I don't understand what "(as the fallback for stretch for fixed-size boxes)" means.

The text was updated successfully, but these errors were encountered:

dbaron · 2017-05-20T22:41:34Z

Also, for what it's worth, the static position affects the size, since abspos boxes do fit-content sizing inside an available width that's derived from one side being the static position and the other side coming from the containing block... so it's also not entirely clear to me how this section holds together in terms of order of operations.

fantasai · 2017-06-26T20:00:24Z

Fun tests for future reference...

http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE html>%0A<style> %0A html { border%3A solid gray%3B width%3A 10em%3B margin%3A 3em%3B height%3A 2em%3B display%3A flex%3B justify-content%3A flex-end%3B }%0A body { position%3A absolute%3B border%3A solid orange%3B }%0A<%2Fstyle>%0A%0Aa b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e 
http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE html>%0A<style> %0A html { position%3A relative%3B border%3A solid gray%3B width%3A 10em%3B margin%3A 3em%3B height%3A 2em%3B display%3A flex%3B justify-content%3A flex-end%3B }%0A body { position%3A absolute%3B border%3A solid orange%3B }%0A<%2Fstyle>%0A%0Aa b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e 
http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE html>%0A<style> %0A html { border%3A solid gray%3B width%3A 10em%3B margin%3A 3em%3B height%3A 2em%3B display%3A flex%3B justify-content%3A flex-end%3B }%0A body { position%3A absolute%3B border%3A solid orange%3B }%0A<%2Fstyle>%0A%0Aa b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e

(Need to put these in the test suite...)

tabatkins · 2017-06-26T20:05:03Z

(The general form of the tests; toggle justify-content and position on html to see the different cases:

<!DOCTYPE html>
<style> 
 html { border: solid gray; width: 10em; margin: 3em; height: 2em; display: flex; justify-content: flex-end; position: relative;}
 body { position: absolute; border: solid orange; }
</style>

a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b c d e a b

)

These tests demonstrate complete non-interop in this case between Chrome and Firefox. All of Chrome's behaviors seems to make no logical sense, and one of the situations (justify-content: flex-end; position: relative) doesn't seem to make any sense on Firefox either.

So ¯\_(ツ)_/¯

tabatkins · 2017-06-26T20:06:37Z

I don't understand what "(as the fallback for stretch for fixed-size boxes)" means.

flex-start is the fallback value for stretch if you're fixed-size. We mandate that the element act as if it's fixed-size here. In most cases normal acts like stretch, so we're specially calling out why we say it acts like a different value here. (It does act like stretch, but immediately falls back to another value, and we'd like to avoid requiring an unnecessary definition-chase to figure out what the behavior is here.)

…sections of the self-alignment property descriptions. #1432

…swg-drafts#1432 w3c/csswg-drafts@ecb1969

tabatkins · 2018-04-30T23:34:24Z

If you add more text, and make it increasing numbers so you can actually tell exactly what part of the context you're looking at, Chrome's behavior becomes even more inexplicable:

<!DOCTYPE html>
<style> 
 html { border: solid gray; width: 10em; margin: 3em; height: 2em; display: flex; justify-content: flex-end; }
 body { position: absolute; border: solid orange; }
</style>
<body>
<script>
document.body.textContent = Array.from(Array(400), (e,i)=>i).join(" ");
</script>

Swap html between flex-start (sensible), flex-end (wut), and center (double wut). I have absolutely no idea what box Chrome is sizing the abspos against in either of the latter two cases.

fantasai · 2018-05-07T18:09:58Z

OK, so, the basic principle we've been operating off of in the Alignment spec is switching out the “check direction” condition in CSS2.1§10 for “check the relevant alignment property”, and relying on the fact that the alignment properties key off of direction, providing the same behavior by default but allowing it to be controlled without misusing direction.

If we continue with that line of thinking for this issue, we would do the same thing: the behavior of start alignment is as defined in CSS2.1, and the behavior of end alignment is what it would be if the direction was reversed from what it is. Thus, since by default (i.e. for start alignment) we use the start edge of the static position containing block and the end edge of the containing block for the available width, then for the opposite alignment (end) we would use the end edge of the static position containing block and the start edge of the containing block for the available width.

The remaining question is what to do for center. The significant edge is the one that matches the requested alignment: the start-edge reference for start alignment, the end-edge reference for end alignment. In each of these cases, this is the static position containing block. Thus center, which keys off of both start and end edges, should use the static position containing block edges for both. This also has the benefit of providing a behavior that cannot otherwise be gotten—since referencing the start/end edges of the actual containing block is always possible using left: 0; right: 0.

So, the proposal is:

If justify-content on the static position containing block is start, use the start edge of the
static position containing block and the end edge of the actual containing block (as CSS2.1 requires).
If justify-content on the static position containing block is end, use the start edge of the actual containing block and the end edge of the static position containing block.
If justify-content on the static position containing block is center, use the start edge and end edges of the static position containing block.

where the first two are exactly what CSS2.1 requires, except with a conditional on the justify-content of the static position containing block substituted for the conditional on direction of the static position containing block, and the third is the consequence of extending that logic to centering as best we can.

tabatkins · 2018-05-07T18:16:39Z

Here's a code example showing off how sizing keys off of direction per CSS 2.1, which we'd like to be consistent with for Align. (That is, if you leave dir alone and just toggle justify-content between start and end, you should get the same result. Today you... don't.)

(testcase link)

<!DOCTYPE html>
<html style="border: solid gray; width: 10em; margin: 3em; height: 2em; display: flex; justify-content: flex-start;">
<body style="position: absolute; border: solid orange; user-select: none;">
<script>
document.body.innerHTML = "<bdi>(click me to toggle) " + Array.from(Array(200), (e,i)=>i).join(" ") + "</bdi>";
var dir = "left";
var html = document.querySelector("html");
document.body.onclick = function() {
  dir = dir == "left" ? "right" : "left";
  if(dir == "left") {
    html.style.marginRight = "3em";
    html.setAttribute("dir", "ltr");
  } else if(dir == "right") {
    html.style.marginRight = "auto";
    html.setAttribute("dir", "rtl");
  }
}
</script>

css-meeting-bot · 2018-05-16T16:53:42Z

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

The full IRC log of that discussion

<dael> Topic: Rules for align/justify-self on static position of absolutely-positioned boxes need more detail
<dael> github: https://github.com//issues/1432#issuecomment-387153116
<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.
<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.
<dael> dbaron: What existing features did you use to test?
<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.
<dael> TabAtkins: Just tested in flex, should be same for grid.
<dael> Rossen_: I'm not surprised it's less then interop.
<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.
<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
<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.
<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.
<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.
<dael> Rossen_: That also means there's additional alignment values we'd need, but they can apply in all layout modes.
<dael> Rossen_: Food for thought. THis is where we ended up after investigating.
<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.
<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.
<dael> dbaron: Prob other behaviors for Rossen_ variant. Incl these prop should mess with static pos at all.
<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.
<dael> dbaron: But considering this align has weird consiquences like center isn't the center.
<dael> TabAtkins: Yes. But we think the center we proposed is a useful approximation.
<dbaron> s/the center/halfway between left and right/
<dbaron> (correction was to my line)
<dael> Rossen: Question. You mentioned you wanted to introduce this. Not a resolution. Pretty sure we need to work more.
<dael> TabAtkins: Yes. Look in details on the thread and we can discuss in future.
<dael> Rossen_: Okay. Anything else you want on this issue?
<dael> TabAtkins: Nope.

fantasai · 2018-05-29T17:00:08Z

Wanted to clarify that static position and sizing is already dependent on the direction property of the containing block. The proposal here is to swap out direction for justify-content so that the author can control this behavior without affecting bidi.

The only additional point is that, because justify-content has a center value, we had to define something for center that was “halfway between” the behavior for ltr/start and rtl/end.

css-meeting-bot · 2018-05-30T16:40:51Z

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

The full IRC log of that discussion

<dael> Topic: Rules for align/justify-self on static position of absolutely-positioned boxes need more detail
<TabAtkins> s/forgetting at parse time/forgetting at parse time then eagerly collapsing/
<dael> github: https://github.com//issues/1432
<dael> fantasai: We discussed this last week or the week before.
<dael> TabAtkins: 2 weeks
<dael> fantasai: Issue was defining impact of various align. I think discussion had some confusion about I don't want sizing to depend on alignment.
<dael> fantasai: To clarify we have the sizing of an abspos item depends on direction prop os static pos containing block.
<dael> fantasai: Suggesting to look at justify-content property instead on that containing block so author can control behavior without effecting bidi. no change in element looked at, just what element.
<dael> fantasai: One case not covered is there's a center value in justify-content and we had to define a value for center.
<dael> fantasai: To revisit the behavior if you have a static pos you use as the contaiing block size you use the start edge of the static pos containing block and end of abspos containing block.
<dael> fantasai: That depends on direction
<dael> fantasai: TabAtkins and I decided that since we can get the behavior for both then for centering both should key off the static containing block.
<dael> fantasai: that's asummary
<fantasai> s/block/block for both sides/
<dael> astearns: I see Rossen was involved 2 weeks ago, but he's not on this week.
<dael> frremy: I don't have the right context to talk. We should prob wait for Rossen to be back
<dael> astearns: fantasai and TabAtkins was Rossen adding useful things or moderating?
<dael> fantasai: dbaron and Rossen had definite opinions. He was participating.
<dael> astearns: You okay waiting until he's back
<dael> fantasai: Sure.
<dael> astearns: We'll postpone again.

css-meeting-bot · 2018-06-06T23:20:50Z

The Working Group just discussed Rules for align/justify-self on static position of absolutely-positioned boxes need more detail, and agreed to the following:

RESOLVED: accept proposal in https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468 ?
RESOLVED: accept proposal in https://github.com/w3c/csswg-drafts/issues/1432#issuecomment-392854468

The full IRC log of that discussion

<dael> Topic: Rules for align/justify-self on static position of absolutely-positioned boxes need more detail
<dael> github: https://github.com//issues/1432#issuecomment-392854468
<alex_antennahouse> what is the webex password?
<dael> Rossen: Only thing to ask is...I had to re-read...now is time to discuss and resolve. The ask was to swap out the direction and have it overwritted for justify-content so static pos and sizing used for abspos items effected by justify-content. THat's the jist, correct?
<dael> TabAtkins: Yes
<dael> Rossen: I was making sure we want to resolve that justify-content takes presidence when calculating position. So if I have direction rtl and nothing inside the containing block and I have a justify-content:end then basically I will have 0 size for the available width
<alex_antennahouse> got it ty
<dael> fantasai: I'm having trouble with your example. If you have abspos and a size containing block which is the parent. Containing block we do calc switched on direction property. Initial value of justify-content is start,start. If you did justify-content:end and rtl it would we same as direction ltr
<dael> Rossen: Not quite.
<dael> fantasai: That's the proposal
<dael> Rossen: This wasn't clear from the linked comment
<dael> fantasai: Not sure. Point is right now we have different behavior for ltr and ltl for static pos. Also size of an auto size abspos depends on direction of static pos containing. We prop we depend on justify-content which then itself depends on direction.
<dael> Rossen: Okay, that should work out
<dael> Rossen: When you have orthogonal chcanges in direction between parent and containing block?
<dael> TabAtkins: No behavior change. What happens today it's the same behavior we want with a slight complication since center is new.
<dael> Rossen: Ccenter is the half way between?
<dael> TabAtkins: more or less, yes.
<dael> Rossen: Then I'm more or less okay with it :)
<dael> Rossen: With all the information I've heard and read I'm fine with it.
<dael> astearns: Other opinions on the new center behavior?
<dael> astearns: Objections to accepting https://github.com//issues/1432#issuecomment-392854468 ?
<dael> RESOLVED: accept proposal in https://github.com//issues/1432#issuecomment-392854468 ?
<dael> RESOLVED: accept proposal in https://github.com//issues/1432#issuecomment-392854468

tabatkins · 2018-06-13T22:54:39Z

Testcase showing the staticpos anchor in an inline context:

<!DOCTYPE html>
<span>text <img src="https://www.xanthir.com/pony"> <span class=abspos>abspos</span> text</span>
<style>
img {
 vertical-align: middle;
}
.abspos {
 position: absolute;
 border: thin solid;
}
</style>

… compute static position/sizing of abspos elements. #1432 (comment)

css-meeting-bot · 2018-07-05T01:24:12Z

The Working Group just discussed align/justify-self on static position of abspos boxes, and agreed to the following:

RESOLVED: The static position rectangle is used as the alignment rectangle of the statically positioned abspos
RESOLVED: For blocks the static position rectangle is the 0-height rectangle between the start and end static position offsets as defined in CSS21

The full IRC log of that discussion

<fantasai> Topic: align/justify-self on static position of abspos boxes
<fantasai> github: https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+is%3Aissue+label%3Acss-align-3
<fantasai> github: https://github.com//issues/1432
<emilio> fantasai: we're asked to define precisely how the alignment properties interact with static pos.
<emilio> fantasai: the remaining one is how align/justify-self interact with it
<emilio> fantasai: the basic model for abspos and alignment is that you have your containing block and your offsets
<emilio> fantasai: and that produces a rectangle in which you do your alignment
<emilio> fantasai: the default behavior depends on CSS21 on whether you're replaced or not
<emilio> fantasai: that's a mess but not defined
<emilio> s/not/well
<emilio> fantasai: for flexbox and grid the alignment container is well defined, we propose to make the alignment rectangle the static pos rectangle is the rectangle representing the position of the element if it were not abspos
<emilio> fantasai: so CSS2.1 you've got your CB, a bunch of content and your element which would be abspos and then you calculate these offsets, and depending on the direction you ignore one of them and then do your positioning calculations
<emilio> fantasai: our proposal is making it the 0-height rectangle occupying between the left and right edges of the static pos as defined in CSS2.1
<emilio> fantasai: which means you can control the alignment of the abspos element with respect of its static position
<emilio> fantasai: anyone has any comments?
<emilio> iank_: for orthogonal writing modes your static pos rectangle may change as soon as it's constrained
<emilio> iank_: ^ not sure I got that right, please correct if so
<emilio> iank_: if you've got a mismatch between the abspos CB and static pos CB as soon as you constrain it it's going to change the axis you align it against right?
<emilio> fantasai: no
<emilio> mismatch between writing-mode static pos and abspos CB
<emilio> iank_: so depending on the CB's writing mode that'll affect whether you use align or justify self to get the centering
<emilio> Rossen: bottom line is alignment happens in the CB
<emilio> Rossen: static pos is calculated in your parent and used in your CB, and the wm that applies to it is the one of the CB
<emilio> Rossen: I think there was one gotcha here which was if your static possition is affected by the wm of your parent
<emilio> Rossen: Imagine you have two empty elements and an abspos inside and the topmost is ltr and the inner one is rtl
<emilio> Rossen: one abspos auto-positioned inside the inner one and the CB is the outer one
<emilio> fantasai: [draws]
<emilio> fantasai: so you have an LTR rectangle. Inside that you have an RTL box. Inside that you have the abspos
<emilio> fantasai: [draws the static pos 0-height rectangle]
<emilio> Rossen: so, if I position with `justify-self: start` for the abspos...
<emilio> fantasai: the direction used is the direction of the CB
<emilio> fantasai: if you want to use the abspos writing mode you can use `self-start`, but the axis you align to is the axis of the CB
<emilio> RESOLVED: The static position rectangle is used as the alignment rectangle of the statically positioned abspos
<emilio> RESOLVED: For blocks the static position rectangle is the 0-height rectangle between the start and end static position offsets as defined in CSS21
<emilio> Rossen: [actually resolves]
<emilio> Rossen: is that everything?
<emilio> fantasai: yes

…lable space. #1432

…lution. #1432 <https://lists.w3.org/Archives/Public/www-style/2018Jul/0028.html>

…os, simply matching the alignment container to the static position rectangle. #1432 <https://lists.w3.org/Archives/Public/www-style/2018Jul/0028.html>

…s’s self-alignment (like everything else) not CB's content-alignment. Define this every clearly. #1432

fantasai · 2018-08-24T19:07:01Z

OK, so, I think we're done with this issue (thanks dbaron, for filing :)

However, we did make a mistake earlier: when we said we should be keying off of the justify-content property of the abspos’s static-position CB, we should actually be keying off of the justify-self property of the abspos itself. This is consistent with the principle of how we're replacing “do X or Y based on CB’s direction” with “do X or Y based on box’s own self-alignment” across the spec in general. Commits for that changeover in a595144
Agenda+ to adjust the resolution proposed in #1432 (comment) accordingly (and generally ask for review).

css-meeting-bot · 2018-08-29T16:37:54Z

The CSS Working Group just discussed Rules for align/justify-self on static position of absolutely-positioned boxes need more detail, and agreed to the following:

RESOLVED: Static position alignment keys off of justify-self on the abspos, not justify-content on the static position CB

The full IRC log of that discussion

<dael> Topic: Rules for align/justify-self on static position of absolutely-positioned boxes need more detail
<dael> github: https://github.com//issues/1432#issuecomment-415854208
<dael> fantasai: This is a discussion we're hoping to close with 1429
<dael> fantasai: We made a mistake when figuring out effect of alignment prop on staticpos. In css2.1 there are rules in static pos as to which edge you care about. Keys off direction of static pos containing block of abspos element.
<dael> fantasai: Since the point o f alignment is to replace this model what we do for in flow elements we use justify-self to determine which side to align to rather then direction prop of containing block
<dael> fantasai: Initial value being start does do that
<dael> fantasai: For abspos elements we presented rules for how to behave and to key off justify content. Should have been justify-self on abspos element
<dael> fantasai: Want to resolve to make that clear
<dael> fantasai: Prop: Static position alignment keys off of justify-self on the abspos
<dael> astearns: Concerns? Questions?
<dael> astearns: Anyone need time or shall we resolve?
<fantasai> s/on the abspos/on the abspos, not justify-content on the static position CB/
<dael> astearns: Objections to Static position alignment keys off of justify-self on the abspos, not justify-content on the static position CB
<dael> RESOLVED: Static position alignment keys off of justify-self on the abspos, not justify-content on the static position CB
<dael> astearns: There have been quite a few edits. Good for people to review

fantasai · 2018-12-07T01:34:06Z

No response in nearly three months, and also no response to multiple queries of "did you want to review this issue" via IRC and email, so closing out as timed out.

tabatkins · 2019-07-18T23:15:42Z

Reopening, as @bfgeek is messing with this code in LayoutNG and thinks we resolved wrong for center alignment.

In particular, he believes that the correct answer is to find the smaller of the start- and end-aligned sizes, then double that, aligning it to the abspos containing block edge that was chosen. This lets it fill out the abspos containing block as much as it can while still remaining centered on one of the "significant edges" of the staticpos containing block.

This is apparently what Edge does. Everyone else does some other "entertainingly wrong" (Ian's words) behavior.

bfgeek · 2019-12-17T20:47:07Z

FYI - I added two tests with this behaviour here: https://wpt.fyi/results/css/css-position?label=master&label=experimental&aligned&q=position-absolute-center which EdgeHTML did pass (doesn't as written as used inline-size, block-size properties).

tabatkins · 2020-01-09T21:39:59Z

Closing in favor of moving the center-align niggle to a new issue.

…ks. #1432

dholbert · 2020-12-15T20:30:59Z

RE the justify-content / align-content changes (in #1432 (comment) and the subsequent resolution) -- @fantasai or @tabatkins , could you check my understanding of where this ended up?

If I'm understanding correctly, I think:
(1) abspos children of a relpos flex container should not have their static position influenced by the flex container's justify-content property.
(2) abspos children of a relpos flex container should respect their own justify-self property when determining their static position.

The earlier spec text here had said something like "determine the abspos child's static position as if the child were the flex container's sole flex item", which gave the opposite expectations for (1)/(2) above (and that's what I'd implemented a few years back, though I think I need to update that now).

dholbert · 2020-12-16T20:17:26Z

Also, am I correct that...
(3) for an abspos child in a relpos flex container, align-self:center is now supposed to center in the flex container's block axis, even if the flex container has flex-direction:column which swaps its align/justify axes for its regular in-flow children
?

That seems to be what the first part of https://drafts.csswg.org/css-align-3/#align-abspos says, at least (though it's a change from how this used to work, and also is a significant departure from the original "pretend it's the sole flex item" behavior). I'm OK with the change (it seems OK in the interest of broader consistency) but I just want to be sure I'm understanding it correctly before getting to implementing it.

fantasai · 2021-01-07T22:21:58Z

@dholbert

Wrt (1), yes that is correct.
Wrt (2), not quite correct. justify-self and align-self don't change the static position itself, they change how the abspos is aligned within its inset-modified containing block. See https://drafts.csswg.org/css-position-3/#abspos-insets
Wrt (3), yes I believe you are correct. The goal was to give abspos a more consistent and straightforward model, in which the inset-modified containing block is calculated possibly affected by the peculiarities of its static position containing block’s layout model; and then the abspos is laid out inside this rectangle the same way in all cases. That the align-self axis of a flex child can change depending on whether it is a flex item or an abspos does seem to fall out of that. :)

If you think there might be some problem with making such changes, let us know!

fantasai · 2021-01-07T22:44:04Z

@dholbert Filed #5843 as follow-up, as I think some of the points you brought up warrant further discussion.

dbaron added the css-align-3 Current Work label May 20, 2017

dbaron mentioned this issue May 20, 2017

[css-align] should justify/align-self on abspos elements apply when offsets are 'auto'? #1429

Closed

fantasai added a commit that referenced this issue Jun 26, 2017

[css-align] Clarify the differences between the abspos and staticpos …

f11b6e9

…sections of the self-alignment property descriptions. #1432

fantasai added a commit that referenced this issue Jul 5, 2017

[css-align] as the fallback for -> the fallback of for clarity #1432

ecb1969

fantasai added the Needs Thought label Jul 5, 2017

triple-underscore added a commit to triple-underscore/triple-underscore.github.io that referenced this issue Jul 6, 2017

[css-align] as the fallback for -> the fallback of for clarity w3c/cs…

513b7c2

…swg-drafts#1432 w3c/csswg-drafts@ecb1969

fantasai added the Needs Testcase (WPT) label Apr 4, 2018

fantasai added Agenda+ and removed Needs Thought labels May 7, 2018

css-meeting-bot removed the Agenda+ label Jun 6, 2018

fantasai added Closed Accepted by CSSWG Resolution Needs Edits labels Jun 7, 2018

tabatkins added a commit that referenced this issue Jun 13, 2018

[css-align-3] First draft of specifying effect of *-content on how to…

f6cb21b

… compute static position/sizing of abspos elements. #1432 (comment)

fantasai added a commit that referenced this issue Aug 15, 2018

[css-align-3] Fix up wording about effect of alignment on abspos avai…

bb48884

…lable space. #1432

fantasai added a commit that referenced this issue Aug 15, 2018

[css-align-3] Formally define 'static position rectangle' per WG reso…

fe80eff

…lution. #1432 <https://lists.w3.org/Archives/Public/www-style/2018Jul/0028.html>

fantasai added a commit that referenced this issue Aug 15, 2018

[css-align-3] Correct some details about auto inset values. #1432

a25aba8

fantasai added a commit that referenced this issue Aug 24, 2018

[css-align-3] Static position calculations should be keying off abspo…

a595144

…s’s self-alignment (like everything else) not CB's content-alignment. Define this every clearly. #1432

fantasai added Agenda+ and removed Needs Edits labels Aug 24, 2018

css-meeting-bot removed the Agenda+ label Aug 29, 2018

fantasai added the Commenter Response Pending label Aug 30, 2018

fantasai added Commenter Timed Out (Assumed Satisfied) and removed Commenter Response Pending labels Dec 7, 2018

fantasai closed this as completed Dec 7, 2018

tabatkins reopened this Jul 18, 2019

tabatkins removed the Commenter Timed Out (Assumed Satisfied) label Jul 18, 2019

tabatkins mentioned this issue Jan 9, 2020

[css-align] Center alignment can be improved #4659

Closed

tabatkins closed this as completed Jan 9, 2020

tabatkins added the Commenter Timed Out (Assumed Satisfied) label Jan 9, 2020

tabatkins added a commit that referenced this issue Jan 9, 2020

[css-align-3] Make text clearer for sizing of abspos double-auto bloc…

824198d

…ks. #1432

dholbert mentioned this issue Dec 15, 2020

Where to move vendor-imports/mozilla/mozilla-central-reftests/align3? web-platform-tests/wpt#26884

Closed

fantasai reopened this Jan 7, 2021

fantasai added the Commenter Response Pending label Jan 7, 2021

fantasai mentioned this issue Jan 7, 2021

[css-flexbox-1][css-position-3] static position of abspos flex children #5843

Open

fantasai closed this as completed Jan 7, 2021

fantasai removed the Commenter Response Pending label Jan 7, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-align] Rules for align/justify-self on static position of absolutely-positioned boxes need more detail #1432

[css-align] Rules for align/justify-self on static position of absolutely-positioned boxes need more detail #1432

[css-align] Rules for align/justify-self on static position of absolutely-positioned boxes need more detail #1432

[css-align] Rules for align/justify-self on static position of absolutely-positioned boxes need more detail #1432

Comments