W3C home > Mailing lists > Public > public-css-testsuite@w3.org > May 2004

Suggested additions to CSS3 Selectors test suite

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 29 May 2004 14:43:54 -0500
Message-ID: <40B8E7FA.3040409@mit.edu>
To: public-css-testsuite@w3.org

I was comparing Mozilla's list of known selector bugs to the CSS Selectors test 
suite, and I found a few bugs that were not caught by the suite.  The list 
follows, with links to relevant testcases:

Interaction of :hover and ::first-line/letter:
   http://bugzilla.mozilla.org/attachment.cgi?id=149591&action=view
   http://bugzilla.mozilla.org/attachment.cgi?id=149592&action=view

DOM changes and their interaction with :first/last-child:
   http://bugzilla.mozilla.org/attachment.cgi?id=149594&action=view
   http://bugzilla.mozilla.org/attachment.cgi?id=149595&action=view

Dynamic handling of :empty.  The test suite tests addition of content, but not 
removal.  A more exhaustive testcase can be found at:
   http://bugzilla.mozilla.org/attachment.cgi?id=127688&action=view

::before/::after content on table display types:
   http://www.ludd.luth.se/~leijon/cv/demo/demo.xml

::first-letter on list items, when list-style-position is "inside":
   http://bugzilla.mozilla.org/attachment.cgi?id=132998&action=view

Dynamic handling of the '+' combinator when the DOM mutates:
   http://bugzilla.mozilla.org/attachment.cgi?id=139253&action=view

Behavior of ::selection if no rules are specified for it:
   http://bugzilla.mozilla.org/attachment.cgi?id=141280&action=view

There are also some things that do work in Mozilla but are not tested by the 
suite.  For example, :link and :visited matching XLinks (assuming XLinks are 
supported at all):
   http://web.mit.edu/bzbarsky/www/testcases/css-selectors/xlinkStyling2.xml

Matching of :link when dealing with malformed URIs (this is dependant on the UA 
not treating such links as links, of course...
   See http://bugzilla.mozilla.org/show_bug.cgi?id=229700

As a general comment, I see very few tests that test selectors in the face of 
dynamic changes (eg having :hover::before styles, scripted changes to the DOM, 
etc).  I think that almost every static testcase in the test suite should have a 
dynamic counterpart or several such.  For example, there should be contains() 
tests that mutate the document by inserting, deleting, appending text, thus 
causing contains() to match or not match (that's 6 tests, that could all be part 
of a single test page, of course).  As things stand, one could have a very buggy 
contains() implementation that would work on small HTML documents and pass the 
test suite, but fail spectacularly on a large document if incremental rendering 
is done...  Similar arguments apply to the :nth-* selectors.  Similarly for 
dynamic changes to href leading to changed :link/:visited matching, changes to 
attributes when various combinators are used, and so forth.

I can help write such dynamic versions of tests in July, but not until then...

-Boris
Received on Saturday, 29 May 2004 15:43:57 GMT

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