User Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_8; en-us) AppleWebKit/533.21.1 (KHTML, like Gecko) Version/5.0.5 Safari/533.21.1 Steps to reproduce: ... <td> <span title="8.55625"></span> <div id="olgx-pbid-1402188443" class="BarChartText ui-progressbar ui-widget ui-widget-content ui-corner-all" style="position: relative; color: Black; width: 80pt" role="progressbar" aria-valuemin="0" aria-valuemax="100" aria-valuenow="85.6"> <span style="position: absolute; text-align: center; width: 100%;">8.56</span> <div class="ui-progressbar-value ui-widget-header ui-corner-left" style="width: 86%; background: none repeat scroll 0pt 0pt YellowGreen;"></div> </div> </td> ... Actual results: This renders a 'progress bar'. However; the number '8.56' within the <span> should be in the center of the bar; but inspecting the DOM; the box containing the <span> with number starts within the center of the containing <DIV> Expected results: the <span> should extend to cover 100% of the containing <div> so the contents of the <span> are displayed at the center of the containing <div>. Note that other render engines work as expected here.

As far as I can tell, our behavior is correct. The testcase doesn't set left or right, so the 'left' value is determined by where the span would be if the position were static. And the text-align:center on the parent block make that be the middle of the block. Both WebKit and Presto seem to ignore the original display value for purposes of horizontal positioning here... as long as that line box is empty. As soon as it becomes non-empty, they take the text-align on the parent into account (see testcase I'm about to attach)1. That inconsistency looks like a bug to me. In any case, just setting "left: 0" in your CSS should make this work correctly for you without depending on the underdefined behavior of auto offsets.

Thanks. Left: 0 fixes the issue in this case. I would expect however that when position: absolute; it's placed on the left; not in relation to the parent object.

You would expect wrong, then. See http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width item 2 in the second list).

Thank you. Not a defect then

Well, I still want dbaron to make a call on whether matching WebKit/Presto here makes sense or not...