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

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 ...

Ideally, I think creating a test exposing the problem and assisting your 
question could be helpful here.

> 
> 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

> 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".


[1]:
CSS2.1, §10.6 Calculating heights and margins
http://www.w3.org/TR/CSS21/visudet.html#Computing_heights_and_margins

[2]
CSS2.1, §10.6.3 Block-level non-replaced elements in normal flow when 
'overflow' computes to 'visible'
http://www.w3.org/TR/CSS21/visudet.html#normal-block

[3]
CSS2.1, §10.3 Calculating widths and margins
http://www.w3.org/TR/CSS21/visudet.html#Computing_widths_and_margins

[4]
CSS2.1, §10.3.3 Block-level non-replaced elements in normal flow when 
'overflow' computes to 'visible'
http://www.w3.org/TR/CSS21/visudet.html#blockwidth

Gérard

Received on Sunday, 3 May 2015 19:39:48 UTC