W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [css-align] Two issues with "Values other than stretch" sentence

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 05 Jul 2018 04:11:31 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-402601530-1530763890-sysbot+gh@w3.org>
The Working Group just discussed `intrinsic sizing in the block axis`.

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1431#issuecomment-402601530 using your GitHub account
Received on Thursday, 5 July 2018 04:11:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 July 2018 04:11:37 UTC