W3C home > Mailing lists > Public > www-style@w3.org > July 2004

Re: [CSS21] Test Suite

From: Chris Lilley <chris@w3.org>
Date: Thu, 22 Jul 2004 23:02:17 +0200
Message-ID: <1573443077.20040722230217@w3.org>
To: "Mark Moore" <mark.moore@notlimited.com>
Cc: www-style@w3.org, "'Ian Hickson'" <ian@hixie.ch>, tantekc@microsoft.com

On Thursday, July 22, 2004, 12:22:48 AM, Mark wrote:

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

Being able to deal with xml is however a common requirement.

MM> Unless there is some other compelling reason, I would suggest changing the
MM> extension for XHTML tests to 'xhtml'.

I agree for the xhtml tests; for the xml tests that are not (supposed to
be ) xhtl (although they are obfuscated xhtml) .xml is appropriate.

MM> Due to various limitations (primarily of IE6), neither the 'xhm', nor the
MM> 'xml' extensions are particularly good.  If the tests are renamed with the
MM> xhtml extension, the tests can be loaded using Firefox, Mozilla, Opera,
MM> *and* IE6.

MM> For the interested, '.xml' files cause IE6 to parse the identified DTD
MM> (xhtml11.dtd).  The DTD for XHTML 1.1 is modular, and IE6 incorrectly barfs
MM> on the missing but IGNORE'd xhtml-prefw-redecl.mod.

Yes (although wasn't that fixed in the latest msxml?)

MM> In addition, IE6 uses the "file extension" to determine which application
MM> should handle the received content even though URI's don't have file
MM> extensions.  For URI's ending in '.xht', IE6 attempts to open the (unknown)
MM> associated application, and the user is presented with a useless "Open
MM> With..." dialog.

Aww, its not useless. The user can pick Firefox instead .... ok ok

MM> 2)  The tests correctly enclose the content of the <style> element in
MM> '<![CDATA[' and ']]>' CDATA section markers [2], but few of the current
MM> browsers

I assume you mean html browsers. SVG browsers do use and understand
this, its a commonly used syntax (actually we had to get a couple of
implementations no not *require* it :)

MM> handle this syntax (probably due to the incompatible definition of
MM> <style> element content between HTML 4, and XHTML 1).  The effect is that
MM> the first rule is ignored (or all rules in the case of Firefox).


MM> I would suggest eliminating the CDATA section markers from the tests since
MM> this exercises a feature of the XHTML parser, and shouldn't affect the
MM> results unless a '<', or '&' are included within the content of the <style>
MM> element.

In that case there should be a separate test that tests this specific

MM>  Although css1test11.xml contains a '<', it works without the CDATA
MM> section markers because the XHTML parser sees this as a comment,

I find that very worrying. <!-- and --> with no intervening - is a

MM> but the CSS parser sees it as a CDO token.

MM> 3) PNG images are used in 75 of the tests, while GIF images are used in 4.
MM> The use of PNG's doesn't add anything to the tests,

I suggest altering the remaining 4 GIFs to PNG unless they are animated.

MM> yet eliminates UA's that
MM> don't render this format (most notably IE6).

There comes a point where, if the implementation is crappy, you have to
say so.

MM> I would recommend converting 28 distinct PNG's to GIF. I would be
MM> happy to provide this conversion if that would help.

No, it would not (file format conversion is trivial, especially in this
case), and I would oppose this change.

MM> If you elect *not* to convert the PNG's, I would suggest converting the
MM> remaining GIF's so you can minimize the requirements of the UA's rendering
MM> engine.

On the other hand that is a much better suggestion.

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

Good point. The SVG test suite uses an 'empty' SVG font for a similar
purpose (it only has a 'missing glyph' and no other glyphs). Although in
that case the font metrics are well defined.

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

Oh, I see, its an actual font? What is the problem (apart from
platforms that ddo not allow font install)?

MM> I would suggest carefully limiting the number of tests that rely on the Ahem
MM> font.  I believe most (if not all) of the Ahem tests can be rewritten to
MM> accomplish the same effects using inline replaced elements.  Clearly,
MM> precise testing of the font-size property will not benefit from inline
MM> images, but there should be ways to test this property without requiring
MM> Ahem.

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

Good suggestion.

MM> [1] http://www.w3.org/Style/CSS/Test/guidelines.html#filenames
MM> [2] http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.8
MM> [3]
MM> http://www.w3.org/TR/2004/CR-CSS21-20040225/visudet.html#inline-non-replaced
MM> [4] http://www.w3.org/TR/2004/CR-CSS21-20040225/cover.html
MM> [5] http://www.hixie.ch/tests/evil/mixed/lineheight4.html

>> -----Original Message-----
>> From: Ian Hickson [mailto:ian@hixie.ch]
>> Sent: Thursday, July 08, 2004 8:03 AM
>> To: Mark Moore
>> Cc: tantekc@microsoft.com
>> Subject: Re: [CSS21] Test Suite
>> On Fri, 2 Jul 2004, Mark Moore wrote:
>> >
>> > According to the CSS2.1 CR, a test suite is required as one of the key
>> > exit criteria, but I haven't been able to find either the suite, or the
>> > current status of features, implementations, or interoperability.
>> The suite is being written. I have a work-in-progress dump at:
>>    http://www.hixie.ch/tests/evil/css/css21/source/raw-tests/
>> ...but it is far from complete.
>> The current status of features, implementations, and interoperability is
>> changing on a daily basis and is not tracked anywhere to my knowledge.
>> --
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group
Received on Thursday, 22 July 2004 17:02:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:31 GMT