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

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

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 21 Sep 2011 15:22:05 -0700
Message-ID: <CANMdWTvwnPvkok66Z5XSrzZ7nr0ewo5bDWXYtkcXoQp3ZRYpFA@mail.gmail.com>
To: www-style@w3.org, David Hyatt <hyatt@apple.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
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.)"

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.

Ojan
Received on Wednesday, 21 September 2011 22:22:48 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:04 UTC