W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css3-writing-modes] height:auto with orthogonal flows

From: MURAKAMI Shinyu <murakami@antenna.co.jp>
Date: Sat, 15 Oct 2011 14:30:35 +0900
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style@w3.org
Message-Id: <20111015143034.7AA8.C598BCD7@antenna.co.jp>
fantasai <fantasai.lists@inkedblade.net> wrote on 2011/10/15 10:26:27
> On 09/21/2011 03:22 PM, Ojan Vafai wrote:
> > 1. Whether to use the extent or the measure of the (intial) containing block is unclear. The first paragraph here seems
> > correct to me and the second is wrong. We shouldn't always use the measure in the case of orthogonal flows.
> >
> > http://dev.w3.org/csswg/css3-writing-modes/#orthogonal-flows says "For example, if a vertical block is placed inside a
> > horizontal block, then when calculating the physical height (which is the measure) of the child block the physical height of
> > the parent block is used to calculate the measure of the child's containing block, even though the physical height is the
> > extent, not the measure, of the parent block."
> >
> > This seems to contradict Appendix D, which says "If the available measure is infinite, then a fallback measure is used in
> > place of the available measure in this calculation. (In the case of orthogonal flows, this is the measure of the initial
> > containing block.)"
> 
> Ok, changed to
> 
>   # then when calculating the physical height (which is the
>   # measure) of the child block the physical height of the parent
>   # block is used as the child's containing block measure, even
>   # though the physical height is the extent, not the measure, of
>   # the parent block.

Agree.

> 
> > 2. "7.3.1. Auto-sizing in Orthogonal Flows
> > If the computed measure of an element establishing an orthogonal flow is ‘auto’, then the used measure is calculated as
> > the fit-content (shrink-to-fit) size using the initial containing block's size as the available measure."
> >
> > We should instead use the available size if there is one and only use the initial containing block's size if there isn't one.
> >
> > <div style="height: 100px">
> > <div style="writing-mode: vertical-lr; height: 100%"></div>
> > </div>
> >
> > Using the initial containing block's size as the spec currently says to would result in the inner div overflowing outside of
> > the outer div. It seems clear to me that any developer would expect the inner div to be 100px tall.

In this example,  'height: 100%' is specified in the inner div, it is not the auto-sizing case, and the outer div's 'height: 100px' is used as the percentage reference.

When the inner div's height is auto, in the current auto-sizing spec, the inner div overflows outside of the outer div. I understand that it would be better if the outer div's height is used as the available measure instead of the height of the initial containing block.

> 
> Hmm, my concern then is this case:
> 
> <div style="height: something long;">
>    <p>Some text.</p>
>    <p>More text.</p>
>    <p style="writing-mode: vertical-rl">
>      Long blockquote whose max-content measure is 900px.
>    </p>
>    <p>More text.
>    <p>More text.
> </div>
> 
> But chances are such content would be auto-height anyway. 

Yes, the author should specify the max-height property in this case.

> So let me make
> that change and check with Murakami-san if it makes sense. :)

I think it makes sense.

If the parent block has non-auto height, the height should be used as the available measure, otherwise the size of the initial containing block should be used. For example, in the following case,  the parent block's height is auto, the available measure should be the initial containing block's height (not the grandparent's height):

<div style="height: 100px">
  <div style="height: auto">
    <div style="writing-mode: vertical-rl">...</div>
  </div>
</div>


-- 
MURAKAMI Shinyu
http://twitter.com/MurakamiShinyu
Antenna House Formatter:
http://www.antennahouse.com
Received on Saturday, 15 October 2011 05:31:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT