- From: Koji Ishii <kojiishi@gmail.com>
- Date: Mon, 4 May 2015 14:20:36 +0900
- To: Gérard Talbot <www-style@gtalbot.org>
- Cc: W3C www-style mailing list <www-style@w3.org>
On May 4, 2015, at 04:39, Gérard Talbot <www-style@gtalbot.org> wrote: > > Le 2015-05-03 09:37, Koji Ishii a écrit : >> I read Orthogonal Flows[1] several times but as far as I understand, it >> does not define how to calculate parent's logical width (i.e., children's >> logical height.) It describes relationship of children's logical width and >> parent's logical height though. >> I'm assuming, after children was layout and children's logical height was >> determined, it becomes both min-content and max-content of logical width >> for the parent. Is this correct? > > Koji, > > Huh... I am trying to understand your question and I am unsure. In your sentence, what is "it" ? I believe your "it" is the children's logical width … Sorry that I wasn’t clear, allow me to retry. So the case I’m wondering is when I need shrink-to-fit width behavior, and therefore need min-content and max-content, and its child is orthogonal. This occurs when calculating the width for inline-block or table-cell, and its child is orthogonal. The only reasonable behavior I can think of is to layout the child, then take its content height, but I have trouble to find it in the spec. Does this make it clear? > Ideally, I think creating a test exposing the problem and assisting your question could be helpful here. Right, here are test cases: http://test.csswg.org/shepherd/search/name/orthogonal-parent-width-min-content/ > I have a bug in Blink related with this, > > Which issue number? Is it > > Issue 459583: 'height: auto' property does not work in vertical-layout > https://code.google.com/p/chromium/issues/detail?id=459583 No, this is about http://crbug.com/410320 >> appreciate to know if my >> understanding above does not seem correct. >> [1] http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-flows > > I would appreciate reading, examining an example of auto-sizing in orthogonal flow in the spec. > > " > Issue 3: What is this section trying to say? I can’t remember. :( > " > §7.3.1 Available Sizes in Orthogonal Flows > http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-auto > > I understand much better the auto-positioning phase though. > >> /koji > > §7.3.1 Available Sizes in Orthogonal Flows > http://dev.w3.org/csswg/css-writing-modes-3/#orthogonal-auto > > goes like this: > > " > It is common in CSS for a containing block to have a definite inline size, but not a definite block size. This typically happens in CSS2.1 when a containing block has an auto height, for example: its width is given by the calculations in 10.3.3, but its block size depends on its contents. > " > > I actually believe that I understand the above 2 sentences. But I think the adjective "definite" and "indefinite" maybe should be reviewed or reconsidered. I would replace "indefinite" by "undefined". Often, in CSS2.1, when referring to a block's height dimension which depends on its content, the spec would say it's *undefined* at parse time and not indefinite. > > " > In such cases the available inline size is defined as the inline size of the containing block; but the available block size, which would otherwise be the block size of the containing block, is infinite. > " > > The available block size is not *infinite* (the sentence above does not make sense to me) but is rather *undefined* at parse time. The block size (height) should grow to accomodate content. > > 'height: auto' in horizontal-tb context and according to CSS2.1 section 10.6 [1] and 10.6.3 [2] is often meant or described as "take (or occupy) only as much as you need and no more". A sort of an "shrink-to-fit-height". > > 'width: auto' in horizontal-tb context and according to CSS2.1 section 10.3 [3] and 10.3.3 [4] is often meant or described as "take (or occupy) as much as you can". A sort of a "use-all-available-width-from-containing-block”. Yeah, I read them all and I think I understand, but not sure which part this case applies. Can you help? /koji
Received on Monday, 4 May 2015 05:21:07 UTC