W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[css3-writing-modes] auto-sizing orthogonal flows shouldn't restrict to the fill-fallback size

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 9 Nov 2012 16:20:12 -0800
Message-ID: <CANMdWTvZ6ZN_81gPVe8KZpqGmuVMbs96qH1qKHFcJT5aYj4vjQ@mail.gmail.com>
To: "www-style@w3.org" <www-style@w3.org>

"min(max-content, max(min-content, min(fill-available, fill-fallback))),
    the min-content measure of the element
    the max-content measure of the element
    the fill-available fit into the element's containing block's size in
the element's inline axis
    the fill-available fit into the initial containing block's size in the
element's inline axis"

I don't think restricting to always be the smallest of
fill-available/fill-fallback makes sense. In fact, I don't see why it's not
always just the fill-available size of the containing block. The point of
this approach is to make it so that line-wrapping does something
reasonable. IMO, line-wrapping should do something analogous to what it
does in horizontal writing mode if you have a definite width that is larger
than the viewport (e.g. if you set the width larger than the viewport, we
don't restrict line-wrapping to the viewport width).

<div style="height: 1000px">
    <div style="writing-mode:vertical-lr">a bunch of text that

In that case, even if the viewport is 500px, I think height of the vertical
writing-mode div should be 1000px. The author is explicitly asking for
this. I don't see why we'd restrict it. If we're auto-sizing all the way up
the tree, the fill-available height will be sized to the viewport size. So
it still meets that use-case.

FWIW, I have a webkit patch up to implement the fill-available approach. I
wrote this up before the spec changed to the above.

P.S. The "fill-available fit" links are to
http://www.w3.org/TR/css3-sizing/#fill-available-fit, which don't match
anything in the TR version of the sizing spec. Can we not link to the dev
Received on Saturday, 10 November 2012 00:21:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:05 UTC