RE: [CSS21] Test Suite

On Wed, 21 Jul 2004, Mark Moore wrote:
>
> First, thanks for publishing the link to the early CSS21 acceptance
> tests suite.  I've gone through them, and I have a few comments I hope
> will be useful.

Note that I must emphasise that these tests are _extremely_ early drafts,
and none are close to being complete.


> 1)  The '.xml' extension doesn't match any of the proposed extensions
> documented in Section 3.7 of the CSS2.1 Test Case Authoring Guidelines.
> [1]

The file naming hasn't yet been done. There'll be three versions
eventually; one .xml (arbitrary XML), one .xht (XHTML 1.1) and one .htm
(HTML4.01) with MIME types application/xml, application/xhtml+xml and
text/html respectively. Since IE6 doesn't support XHTML, if it were tested
with these tests, only the XML and HTML4 tests would be used.


> 2)  The tests correctly enclose the content of the <style> element in
> '<![CDATA[' and ']]>' CDATA section markers [2], but few of the current
> browsers handle this syntax (probably due to the incompatible definition
> of <style> element content between HTML 4, and XHTML 1).  The effect is
> that the first rule is ignored (or all rules in the case of Firefox).

This is only the case if you send the files as text/html, which is not
allowed. (The tests in question are not XHTML 1 compliant to Appendix C.)


> 3) PNG images are used in 75 of the tests, while GIF images are used in 4.

I'll probably convert the GIFs to PNGs in due course.


> 4) A number of the tests use the 'Ahem' font (93 to be precise).
> Although I can understand the convenience of the technique, it relies
> heavily on the particular handling of font rendering which is explicitly
> left to the implementer in places (e.g. height of inline, non-replaced
> elements [3]).

None of the UA-defined aspects of rendering are in play when Ahem is used,
since its em-square height is exactly equal to its ascent+descent
distance, so this should not be a problem.


> Worse, it implicitly requires all conformant UA's to implement a font
> mechanism that can accept the Ahem font, port the Ahem font to their
> platform, or rewrite the 93 tests according to the "interoperable'
> definition. [4]

Yes.


> I would suggest carefully limiting the number of tests that rely on the
> Ahem font.  I believe most (if not all) of the Ahem tests can be
> rewritten to accomplish the same effects using inline replaced elements.

The existing tests are ports of the CSS1 tests to the CSS2.1 format and
guidelines. Part of the intent of this port is to remain faithful to the
original tests. Thus if the original tests did not use replaced elements,
I would rather not use them in the new tests either.


> Clearly, precise testing of the font-size property will not benefit from
> inline images, but there should be ways to test this property without
> requiring Ahem.

Any suggestions?


> I would also suggest that a link to the Ahem download page [5] be
> included either in the body, or in the head of any test that does
> require the Ahem font.

It will be included in the test suite introduction, probably. It cannot be
included in the tests themselves as that introduces too many variables
that can affect automated users of the test suite.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 22 July 2004 18:32:41 UTC