W3C home > Mailing lists > Public > public-css-testsuite@w3.org > December 2010

Re: review of Microsoft CSS 2.1 font tests

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Tue, 7 Dec 2010 11:22:13 -0800
Message-ID: <9072024d09f47fbb08d6c0c003f37761.squirrel@cp3.shieldhost.com>
To: "John Daggett" <jdaggett@mozilla.com>, "Arron Eicholz" <Arron.Eicholz@microsoft.com>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>

Le Mer 20 janvier 2010 7:20, John Daggett a écrit :
> I went through and looked over the font tests submitted by Microsoft for
> use with the CSS 2.1 Test Suite (Chapter 15)
> Current revision of these tests:
> http://test.csswg.org/svn/contributors/microsoft/submitted/Chapter_15/
> Annotated snapshot from last week:
> http://people.mozilla.org/~jdaggett/csstests/microsoft/chapter15/
> The tests make use of a number of modified versions of the Ahem font,
> found in the support directory:
> http://test.csswg.org/svn/contributors/microsoft/submitted/support/
> Individual tests note the need for a given font but I think it would be
> better to note a required set of fonts more clearly, so that testers
> don't need to dig into the tests to figure out what fonts are needed.
> The use of Ahem as a testing font is not always a good choice; several
> of the tests rely on synthetic bolding and obliquing since Ahem is a
> font family with a single, normal font face.  The use of a test font
> family with regular, bold, italic and bold italic faces would be much
> better for this purpose.
> font-003.xht
> Text in test seems invalid.  Relies on synthetic small-caps, there is no
> basis for asserting that a synthetic small-cap x is wider/taller than a
> lowercase x.  The X/x letter is also a lousy test character because it's
> capital and lowercase forms are very similar.  Using the letter E/e
> would be better I think.
> font-applies-to-xxx
> font-family-applies-to-xxx
> font-size-applies-to-xxx
> font-style-applies-to-xxx
> font-variant-applies-to-xxx
> font-weight-applies-to-xxx
> I don't quite understand the point of these tests, it seems to be
> testing font properties to assure they behave the same across different
> block types.  Is there an implied dependency here?  Or some historical
> browser behavior that was a source of bugs?  This is roughly a third of
> the tests!
> font-family-rule-011.xht
> s/deafult/default/
> font-family-rule-017.xht



> According to the passing condition of the test, I don't see how a
> failure could occur.  The assertion also seems incorrect here -
> "Multiple white spaces not inside quoted font-family name can be
> collapsed to single white space OR not collapsed."  The wording in the
> spec is pretty clear that it's collapsed.  If there's an errata that
> applies somewhere, please add a reference.



Section 15.3 says
"If quoting is omitted, any white space characters before and after the
font name are ignored and any sequence of white space characters inside
the font name is converted to a single space."

while the assert says

"Multiple white spaces not inside quoted font-family name can be
collapsed to single white space OR not collapsed."

The "OR not collapsed" part is not true, not correct.

> font-matching-rule-014.xht


> font-family: "Missing Italic Oblique" serif;
> I think you need a comma here, as is this is a rule with invalid syntax



font-family: "Missing Italic Oblique" serif;

should be instead

font-family: "Missing Italic Oblique", serif;

The CSS validator will also catch and report such error:


Value Error : font-family Too many values or values are not recognized :
"Missing Italic Oblique" serif "Missing Italic Oblique" serif

> font-matching-rule-015.xht
> I don't think the assertion is valid here.  The spec says "Typically,
> sizes for scalable fonts are rounded to the nearest whole pixel" but
> this is not really current practice nor does the wording make it a
> requirement.
> font-size-003.xht
> Is there a better way to test this maybe?  A table of these dots?  A lot
> of testers are going to be squinting at their screens for this one.



Does the CSS 2.1 test suite really need to test 'font-size: 1px' ?

> font-size-004.xht, font-size-005.xht
> I think you're really asserting that +/-0px is the same as 0px
> font-size-012.xht



> Not sure the assertion is correct, I don't think font-size is set to
> 'auto' here.  The second font-size declaration is invalid and so is
> omitted.
> font-size-023.xht
> Same as above






<meta name="assert" content="The 'font-size' property sets a minimum
minus one length value in points is invalid and resets its value to
'auto'." />

but what John Daggett says is correct. The declaration with invalid value
is ignored and so, the previous one is honored, applied, not reset. A
so-called 'font-size: auto' does not exist.

> font-size-rule-001.xht
> Assertion wording is dodgy, the second font-size rule is invalid so the
> element inherits the default font-size value, "fall back" implies
> something different.



 <meta name="assert" content="The 'font-size' does not allow for a
negative value. It will fall back to the default value 'medium'." />

Proposed replacement

 <meta name="assert" content="The 'font-size' does not allow for a
negative value; such 'font-size' declaration should be ignored. Then the
 'font-size' property value can be determined by computed font-size of
containers and from cascade mechanisms (user, author, user agent)." />


/* in this testcase, the font-size applied on the span#span2
should inherit (user agent) default 'font-size' value for body element
which is 'medium' by user agent style sheet. */

> font-weight-010.xht
> This test makes assumptions about the default font.  If the font is set
> to a font family with a single, 600-weight the test will fail.
> font-weight-rule-004.xht
> Assumes the default font has just two weights, 400 and 700.
> font-weight-rule-006.xht
> Ditto.
> Regards,
> John Daggett
> Mozilla Japan

regards, Gérard
Contributions to the CSS 2.1 test suite:

CSS 2.1 test suite (RC3; October 27th 2010):

CSS 2.1 test suite contributors:
Received on Tuesday, 7 December 2010 19:22:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:22 UTC