RE: [CSS21] Test Suite

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Chris Lilley
> Sent: Thursday, July 22, 2004 2:02 PM
> To: Mark Moore
> Cc: www-style@w3.org; 'Ian Hickson'; tantekc@microsoft.com
> Subject: Re: [CSS21] Test Suite
> 
> 
> 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.

I may be missing your point, Chris.  I have no problem if the WG adds the
.xml extension to the TCA guidelines, changes the test extensions to match
the guidelines, or simply ignore the guidelines all together.  I'm simply
pointing out they don't match.


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

Again, I'm probably missing something.  All of the tests are pretty clearly
XHTML 1.1.  (Every single file includes the <!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
signature.)

I'm simply arguing that .xhtml is a better extension than .xht or .xml, and
tried to state my case.



> 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?)

Apparently not.  I'm testing with IE 6.0.2800.1106.


[snip]
> 
> 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
> feature.

Testing the handling of '<' and '&' in the <style> element content tests
XHTML conformance, not CSS conformance.  (I couldn't find anything in CSS
that calls these characters out.)  No need to test that here, right?


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

Yep, exactly, but the XHTML parser is looking for the </style> end tag, '&'
entities, or general SGML tag errors.  It should (and seems to) pass the
content including the SGML comment on to the CSS parser.

This is one of the cases where I can see a need to use the CDATA section
markers to reliably inject CDO and CDS tokens into the CSS token stream for
tests written in XHTML.  On the other hand, it would be just as easy to
write the CDO/CDS test with a HTML 4.1 Strict DOCTYPE, or with an external
style sheet for that matter.


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

I'd be all for that.  (They're not, BTW.)


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

Whaling on IE6 misses my point.  If you write tests narrowly, you
arbitrarily eliminate UA's (beyond IE6).  I'm thinking of handhelds,
set-tops, and the like.  IE6 just makes an easy to use, easy to get,
crust-muffin, and an easy target.


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

Chris, I might be able to get behind you on this, but I'll need a little
more explanation.  Is there some particular reason or justification you
might elaborate?


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

Thanks!


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

Whew!  I was starting to worry.  ;o)


> 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)?

Nothing beyond that.  I just felt that requirement was too limiting, and I
could easily imagine workarounds for the Ahem dependent tests I looked at.

[snip]

Received on Thursday, 22 July 2004 19:11:14 UTC