position-relative-008 , bottom-091 and bottom-092

> Author: Microsoft
>
> http://test.csswg.org/suites/css2.1/20100815/html4/position-relative-008.htm
>
> The assert is misleading or inappropriate.
>
> The spec states
>
> "
> Since boxes are not split or stretched as a result of 'left' or 'right',
> the computed values are always: left = -right.
>
> If both 'left' and 'right' are 'auto' (their initial values), the
> computed values are '0' (i.e., the boxes stay in their original
> position).
>
> If 'left' is 'auto', its computed value is minus the value of 'right'
> (i.e., the boxes move to the left by the value of 'right').
>
> If 'right' is specified as 'auto', its computed value is minus the value
> of 'left'.
> "
> http://www.w3.org/TR/CSS21/visuren.html#relative-positioning
>
> I propose to replace
>
>  <link rel="help" title="9.4.3 Relative positioning"
> href="http://www.w3.org/TR/CSS21/visuren.html#positioning-scheme">
>     <meta name="flags" content="">
>     <meta name="assert" content="Relatively positioned element with
> 'right' set to 'auto' and 'left' set to a value appears at expected
> offset.">
>
> with
>
>  <link rel="help"
> href="http://www.w3.org/TR/CSS21/visuren.html#position-props">
>     <meta name="flags" content="">
>     <meta name="assert" content="A relatively positioned box with 'left'
> set to a value moves the box to the left by the value of 'right'.">
>
> ----------------------

The proposed replacement for the text assert, as worded, is not sufficient.

New proposed replacement:

  <link rel="help"
 href="http://www.w3.org/TR/CSS21/visuren.html#position-props">
     <meta name="flags" content="">
     <meta name="assert" content="If 'right' offset of a relatively
positioned box is specified as 'auto', then its computed value is
minus the value of 'left' offset. A relatively positioned box with
'left' set to a value moves the box to the left by the value of
'right'.">

---------------------

> Author: Microsoft
>
> http://test.csswg.org/suites/css2.1/20100815/html4/bottom-091.htm
> http://test.csswg.org/suites/css2.1/20100815/html4/bottom-092.htm
>
> Fractional pixel problem! This time with Chrome 6.0.472.53
>
>   border-top: 1ex solid black; /* == 12px and not to 13px which would be
> the rounding up of 12.8px */
>   margin-top: 6.5ex; /* == 83px, rounded down from 83.2px */
>   bottom: 7.5ex; /* == 96px */
>
> Proposed replacements:
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/bottom-091.htm
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/bottom-092.htm

I still propose those replacements for now. Safari 5.0.1, wrt previous
versions of Safari, changed the way it handles the ahem font and/or ex
unit: the 1ex == 0.8em equation seems to be no longer applied for ahem
font. If browsers can implement 1ex == 0.5em for ahem font, then it is
going to become furthermore difficult to avoid fractional pixel
situations.

I may have to revisit such testcases; maybe 6.5ex should be replaced
with 10ex to avoid fractions regardless of the ex versus em conversion
factor applied.

regards, Gérard
-- 
Contributions to the CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

CSS 2.1 test suite (beta 3; August 15th 2010):
http://test.csswg.org/suites/css2.1/20100815/html4/toc.html

CSS 2.1 test suite contributors:
http://test.csswg.org/source/contributors/

Received on Monday, 6 September 2010 22:54:58 UTC