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