- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 20 Jan 2010 07:20:06 -0800 (PST)
- To: public-css-testsuite@w3.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 UTC