[css-align] Two issues with "Values other than stretch" sentence

[dbaron]

I have two issues with this sentence:

Values other than stretch cause non-replaced absolutely-positioned boxes to use fit-content sizing for calculating auto inline sizes.

In the "Other details" part of the rules for justify-self on absolutely-positioned boxes.

• It should be clear that normal acting like stretch is not a value other than stretch
• the size in question is not an inline-size when the absolutely-positioned box is orthogonal to its containing block

Both of these issues apply equally to the equivalent sentence:

Values other than stretch cause non-replaced absolutely-positioned boxes to use shrink-to-fit sizing for calculating auto block sizes.

in the rules for align-self on absolutely-positioned boxes.

[fantasai]

Fixed in 7d1efdc ; please let me know if this is now correct.

[dbaron]

I'm mostly OK with it, except now you're referring to fit-content sizing in the block axis, and I disagree that such a concept exists (despite that you've put it into sizing). (In the old wording, the block and inline wording was more different.) When it's the block dimension, it needs to be a layout-based size that's used, not an intrinsic size. (The current definitions of intrinsic sizes in the block dimension pretend to do the right thing, except they're not actually intrinsic sizes.)

So I'm not OK with this resolution. I think it needs a solution that doesn't introduce a dependency on the fiction of block-dimension intrinsic sizes (which aren't actually intrinsic, since they explicitly depend on layout).

[tabatkins]

So just to clarify, is your issue solely one of terminology? That is, the functionality described here is fine, you just don't want it referred to as an "intrinsic" size?

[css-meeting-bot]

The Working Group just discussed intrinsic sizing in the block axis.

The full IRC log of that discussion

<tantek> topic: intrinsic sizing in the block axis
<tantek> dbaron: I think this came up in two issues
<tantek> dbaron: one issue is 1431
<tantek> github: https://github.com//issues/1431
<astearns> github: https://github.com//issues/1431
<tantek> dbaron: layout regarding intrinsic size ...
<tantek> dbaron: I objected ... IDK if I'm the only upset about this
<tantek> TabAtkins: IE alread does layout while compute block layout sizes so they get correct values for column wrapped ...
<tantek> dbaron: even if it is possible, we should only do it when it is absolutely necessary
<tantek> dbaron: if an alignment thing can happen after layout, then we are better off describing it as something that happens after layout
<tantek> dbaron: instead of describing computing the intrinsic size
<tantek> TabAtkins: there are other things that want this sizing
<tantek> TabAtkins: such as sizing a float at all
<tantek> TabAtkins: me and Elika already went to / want to express this
<tantek> TabAtkins: customlayout already expresses ...
<tantek> iank_: no it doesn't
<tantek> dbaron: basically, what do you think about describng block direction alignment as computing the intrinsic size in the block size and doing the alignment vs doing the layout and aligning the result
<tantek> s/block size/block direction
<tantek> Rossen: in our case we align only after a layout
<tantek> Rossen: in general the cases of layout are measuring, arranging, and aligning - for us
<tantek> Rossen: and aligning only happens naturally after arranging
<tantek> Rossen: which is what you are referring to as layout
<tantek> Rossen: and measuring is what you refer to as intrinsic sizing
<tantek> Rossen: ...
<tantek> astearns: do you mind if the spec says you get those block direction measurements for arranging?
<tantek> fantasai: we are talking about the sentence about baseline alignment can influence the ...
<tantek> Rossen: yes
<tantek> fantasai: if you say it doesn't increase the size of the intrinsic box, then the size of the box won't increase
<tantek> fantasai: in order to accomodate the content it will overflow
<dbaron> I thought we were talking about a totally different sentence.
<dbaron> "Values other than stretch or normal cause non-replaced absolutely-positioned boxes to use fit-content sizing for calculating auto sizes in the affected axis."
<tantek> Rossen: in this case, what we would do in the cases where we need to stretch, we do the normal pass of computing intrinsic and doing layout
<tantek> Rossen: and then do the actual alignment, and then based on the alignment stretch, similar to what you do with table cells
<tantek> Rossen: sometimes this means we have to go and do one more pass inside
<tantek> Rossen: sometimes when you do the stretch because of alignment, you have to relayout inside such items as well
<tantek> Rossen: we are already doing it, pretty much everyone is doing it
<tantek> Rossen: I don't think we have a way out of this
<tantek> dbaron: I thought we were talking about a different sentence
<tantek> dbaron: I thought it was the sentence "Values other than stretch or normal cause non-replaced absolutely-positioned boxes to use fit-content sizing for calculating auto sizes in the affected axis."
<tantek> dbaron: it used to describe ..., now it is saying you use fit-content sizing ...
<tantek> fantasai: since ... and ... are the same, that's what you get
<tantek> dbaron: but you're using fit-content size which is not a function of the other dimension
<tantek> dbaron: but if you're doing it for layout, your layout is a function of measurement in the other axis
<tantek> fantasai: that sentence is a bit of shorthand
<tantek> fantasai: ... I don't particularly see the point
<tantek> dbaron: the fit-content size of a block is the result of layout at what width?
<tantek> TabAtkins: do you have an answer to that question for min-content instead?
<tantek> dbaron: no
<tantek> dbaron: intrinsic sizes come before layout
<tantek> dbaron: I think you defined it somewhere but I don't remember where the answer was
<tantek> dbaron: it doesn't particularly make sense to me so I have trouble remembering it
<tantek> fantasai: at what size depends on the rules of alignment in the ... axis
<tantek> fantasai: the rules for layout says you ... in the containing block minus the margin, border, padding... then depending ... 100% of that remaining space, or shrink wrapped
<tantek> fantasai: ... or block size, and then that becomes the size used
<tantek> fantasai: ... and then when you do alignment ...
<tantek> fantasai: (couldn't parse that)
<tantek> astearns: dbaron do you have alternate wording that you would be satisfied with?
<fantasai> Rules for abspos say that you find the inline size using the containing block size, offsets, margins/borders/padding, etc. Take the renainins space, lay out into that.
<tantek> dbaron: I think I liked what was in this section before
<tantek> dbaron: if you are aligning in the block direction, you do layout, and then you align the result
<tantek> astearns: seems reasonable to me
<tantek> astearns: fantasai you were using the phrase the content based size
<tantek> astearns: rather than intrinsic siz
<tantek> fantasai: intrinsic sizes are content based sizes
<tantek> fantasai: the size of an image is an intrinsic size
<TabAtkins> https://github.com/w3c/csswg-drafts/commit/7d1efdc3e96a94a6a426016d8752a2ddcd10af59
<fantasai> To find the content-based (intrinsic) size in the block axis, you need to lay out the content into the inline size to find out how tal it is
<tantek> Rossen: intrinsic sizes are well defined in the inline direction, and in the block direction (too soft to hear)
<tantek> Rossen: talking about intrinsic sizes in the block direction...
<tantek> Rossen: I think what dbaron is suggesting makes sense, which is you layout and then you align
<tantek> Rossen: I don't know what it means to align then layout
<tantek> TabAtkins: my issue here is that the text before we made the change was effectively identical
<tantek> TabAtkins: we didn't change the concept at all, we just made a copy/paste error
<tantek> TabAtkins: before we said ..., now we said ..., but that didn't change the meaning of the sentence at all
<tantek> dbaron: I think there might have been something else before a prior edit
<tantek> astearns: if archeology, then we table this for now, and work on whether there was previous wording that was better or can we improve it now some other way
<tantek> Rossen: can we whiteboard it at the break
<tantek> fantasai: no argument about behaior, just terminology
<tantek> TabAtkins: happy to fix terminology offline
<tantek> astearns: any other alignment issues
<tantek> dbaron: I don't think so, but the thing we discussed is why I was unhappy with 2 or 3 of them
<tantek> astearns: table this for now

[dbaron]

The followup issue requested after the discussion minuted in the previous comment is #2890.