Re: [css-writing-modes] Orthogonal parent's logical width

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