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).


Base case: no percentages.

Some initial text to push the start of the inline to the right. An inline that might end Abspos on the next line.


width:50%.

Some initial text to push the start of the inline to the right. An inline that might end Abspos on the next line.

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.)

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').


text-indent:50%.

Some initial text to push the start of the inline to the right. An inline that might end Abspos on the next line.

Result: in Gecko, the text-indent is zero, even if the inline element isn't broken and thus has positive width.
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.


text-indent:50% in an inline whose containing block is 50% of the body width.

Some initial text to push the start of the inline to the right. An inline that might end Abspos on the next line.

Result: Yes, the text-indent is 50% of the inline's containing block's width in Konqueror/WebKit/Chromium.


width:50%; text-indent:25%.

Some initial text to push the start of the inline to the right. An inline that might end Abspos on the next line.

Result: No surprise from either Gecko or Konqueror/WebKit/Chromium given their previous results.


padding-left:50%.

Some initial text to push the start of the inline to the right. An inline that might end Abspos on the next line.

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.
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.


margin-left:50%.

Some initial text to push the start of the inline to the right. An inline that might end Abspos on the next line.

Result: No surprise from Gecko (i.e. as for padding-left and width).
Another surprise from Konqueror/WebKit/Chromium: used value of zero if the inline is broken, but 50% of inline width if unbroken.