[CSS21] negative containing block width and percentages

Section 10.1 says

  # Note: This may cause the containing block's width to be negative.

My guess is that this is in reference to the case where the nearest
absolute/relative/fixed ancestor is an inline box that's broken due to
either line-breaking or bidi, and looking for ancestors based on unbroken
boxes (i.e. like elements) but considering "first" / "last" box based on
broken box pieces.

I constructed a test case like that (only trying the line-breaking case,
not trying the bidi case), and the results for percentages were...
interesting.  See the appended HTML file or
http://bowman.infotech.monash.edu.au/~pmoulder/html-tests/negative-containing-width.html
.

Given these interesting existing results, I'd be somewhat inclined to
change things such that the containing block width can never be negative.


(Somewhat related is the issue of the unclarity of section 10.1, discussed
starting at http://lists.w3.org/Archives/Public/www-style/2010Oct/0540.html .)

pjrm.


<html>
<head>
<title>Test of behaviour when containing block has negative width</title>
</head>
<body>
<p>In most cases, the 'min-width' property's behaviour means that the containing block
has a non-negative (though possibly zero) width, but the
containing block of a position:absolute element might have negative width if it's
in a position:relative inline element that generates more than one box
(presumably due to either line breaking or bidi reordering caused by the element
bounds not corresponding to direction change points within the text).</p>

<hr />
<p>Base case: no percentages.</p>
<p>Some initial text to push the start of the inline to the right.
<span style="position:relative;">An inline that might end
<span style="position:absolute; border:1px solid blue; background:yellow;">Abspos</span>
on the next line.</span></p>

<hr />
<p>width:50%.</p>
<p>Some initial text to push the start of the inline to the right.
<span style="position:relative;">An inline that might end
<span style="position:absolute; width:50%; border:1px solid blue; background:yellow;">Abspos</span>
on the next line.</span></p>
<p>Result: in Gecko, the width seems to be a proportion of the first box piece
-- even when the "reference position" is in the second piece (i.e. when both
"end" and "on" are in the second piece).  Relatedly, the static position of the
abspos box is calculated as if the inline element hadn't been broken, i.e. it's
level with the first line and is off to the right of the page.  Although
surprising, I believe this behaviour is a defensible implementation given that
the box tree isn't defined in the spec, and given that the existing definition
of containing block says "if the ancestor of the element is a box" so it would
seem reasonable to look for a box ancestor (even though this means that the
containing block width can't be negative as far as I know, though I haven't
looked carefully).  (And of course the position is defensible, because the spec
is clear that UAs are allowed to (mis-)guess the static position.)</p>
<p>In Konqueror/WebKit/Chromium, the used width is consistent with the
"element" interpretation: 50% if unbroken, while if broken in a way that gives
negative containing block width then a used width of zero (presumably due to
'min-width').</p>

<hr />
<p>text-indent:50%.</p>
<p>Some initial text to push the start of the inline to the right.
<span style="position:relative;">An inline that might end
<span style="position:absolute; text-indent:50%; border:1px solid blue; background:yellow;">Abspos</span>
on the next line.</span></p>
<p>Result: in Gecko, the text-indent is zero, even if the inline element isn't
broken and thus has positive width.<br />
Surprise for Konqueror/WebKit/Chromium: 50% of the viewport/body width, whether
the inline is broken or not.  Presumably more generally 50% of the inline's
containing block's width, let's check.</p>

<hr />
<p>text-indent:50% in an inline whose containing block is 50% of the body width.</p>
<p style="width:50%;">Some initial text to push the start of the inline to the right.
<span style="position:relative;">An inline that might end
<span style="position:absolute; text-indent:50%; border:1px solid blue; background:yellow;">Abspos</span>
on the next line.</span></p>
<p>Result: Yes, the text-indent is 50% of the inline's containing block's width
in Konqueror/WebKit/Chromium.</p>

<hr />
<p>width:50%; text-indent:25%.</p>
<p>Some initial text to push the start of the inline to the right.
<span style="position:relative;">An inline that might end
<span style="position:absolute; width:50%; text-indent:25%; border:1px solid blue; background:yellow;">Abspos</span>
on the next line.</span></p>
<p>Result: No surprise from either Gecko or Konqueror/WebKit/Chromium given
their previous results.</p>

<hr />
<p>padding-left:50%.</p>
<p>Some initial text to push the start of the inline to the right.
<span style="position:relative;">An inline that might end
<span style="position:absolute; padding-left:50%; border:1px solid blue; background:yellow;">Abspos</span>
on the next line.</span></p>
<p>Result: in Gecko, the same as for width, i.e. relative to the first box
piece even if the reference point is in the second piece.<br />
In WebKit and Chromium, the same as for text-indent, i.e. relative to the
inline's parent block's content width.  Konqueror had an additional surprise:
the text is placed as if padding-left had the same used value as in WebKit
&amp; Chromium, but the background and border are as if the padding-left were
zero.</p>

<hr />
<p>margin-left:50%.</p>
<p>Some initial text to push the start of the inline to the right.
<span style="position:relative;">An inline that might end
<span style="position:absolute; margin-left:50%; border:1px solid blue; background:yellow;">Abspos</span>
on the next line.</span></p>
<p>Result: No surprise from Gecko (i.e. as for padding-left and width).<br />
Another surprise from Konqueror/WebKit/Chromium: used value of zero if the
inline is broken, but 50% of inline width if unbroken.</p>

</body>
</html>

Received on Wednesday, 3 November 2010 07:10:58 UTC