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

review of Microsoft CSS 2.1 font tests

From: John Daggett <jdaggett@mozilla.com>
Date: Wed, 20 Jan 2010 07:20:06 -0800 (PST)
To: public-css-testsuite@w3.org
Message-ID: <1066145437.144669.1264000806746.JavaMail.root@cm-mail03.mozilla.org>
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.  

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

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

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.

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
Received on Wednesday, 20 January 2010 15:20:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 September 2010 17:52:01 GMT