- From: Peter Moulder <peter.moulder@monash.edu>
- Date: Wed, 03 Nov 2010 18:10:27 +1100
- To: www-style@w3.org
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 & 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