RE: Microsoft's numbers-units-014 and table-height-algorithm-026

On Friday, October 15, 2010 8:44 AM Gérard Talbot wrote:
> http://test.csswg.org/suites/css2.1/20101001/html4/numbers-units-014.htm
> 
> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_4/
> numbers-units-014.htm
> 
> That testcase still has problems; as coded, it can not fail and does not test
> what it tries to be testing.
> 
>             #parent
>             {
>                 font: 50px/1 ahem;
>             }
>             #div1
>             {
>                 font-size: larger;
>             }
>             #test
>             {
>                 background: black;
>                 height: 1em;
>                 width: 1em;
>             }
>             div
>             {
>                 margin-top: 5px;
>             }
>             #reference
>             {
>                 background: black;
>                 height: 25px;
>                 width: 25px;
>             }
> 
> 
>         <div id="parent">
>             <div id="div1">
>                 <div id="test"></div>
>                 <div>X</div>
>             </div>
>         </div>
> 
> 
> #div1 computed font-size could be 50px mult scaling factor of
> (1.2|..|1.5) = 60px or .. or 75px or according to 15.7 Font-size
> http://www.w3.org/TR/CSS21/fonts.html#font-size-props
> any other value since
> "In CSS1, the suggested scaling factor between adjacent indexes was 1.5,
> which user experience proved to be too large. In CSS2, the suggested scaling
> factor for a computer screen between adjacent indexes was 1.2, which still
> created issues for the small sizes. Implementation experience has
> demonstrated that a fixed ratio between adjacent absolute-size keywords is
> problematic, and **this [CSS 2.1] specification does not recommend such a
> fixed ratio**."
> 
> As coded,
>                 <div id="test"></div>
>                 <div>X</div>
> are exactly the same since 'X' creates a square of exactly 1em in height and
> width regardless of involved or specified font-size.
> And since we do not know the scaling factor between medium and large,
> then we can not compare with a reference.
> 
> There is no #reference node in the markup code.
> 
> I think that testcase should just be removed because it does not test what it
> is aiming at or supposed to be testing to begin with. I do not see how that
> testcase can be rehabilitated or "restaured".
> 
> =================
> 
> Řyvind's feedback on table-height-algorithm-026 :
> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Feb/0031.html
> 
> Testcase:
> http://test.csswg.org/suites/css2.1/20101001/html4/table-height-algorithm-
> 026.htm
> 
> http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_17
> /table-height-algorithm-026.htm
> 
> The testcase compares the vertical position of bottom borders, it does not
> compare the vertical alignment of the text as sitting on the baseline and
> without any descender.
> 
> There are many differences between browsers in the way they style by
> default submit or push buttons: font used (font: -webkit-small-control for
> Chrome), padding-top and padding-bottom (1px for Chrome 6 and Opera
> 10.63; 0px for Firefox 3.6.10).
> 
> I propose this replacement:
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/table-height-
> algorithm-026.htm
> and I welcome feedback on it.
> 
> The testcase still would require to update the text assert; as worded, I do not
> understand it.
> 
> That testcase could still be simplified by changing background-color from light
> gray (#DDD) to white color.

Fixed both cases

--
Thanks,
Arron Eicholz

Received on Friday, 3 December 2010 17:33:16 UTC