- From: Gérard Talbot <www-style@gtalbot.org>
- Date: Sun, 03 May 2015 15:39:17 -0400
- To: Koji Ishii <kojiishi@gmail.com>
- Cc: W3C www-style mailing list <www-style@w3.org>
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