CSS 2.1 tests: again

[Gabriele Romanato]

Just finished to upload the new tests:

http://www.css-zibaldone.com/test/more/

download:

basic/atomic
http://www.css-zibaldone.com/test/more/css21.zip

complex/advanced
http://www.css-zibaldone.com/test/more/real.zip

faq: http://www.css-zibaldone.com/test/more/about.txt

HTH

Gabriele

--
http://www.css-zibaldone.com/
http://mimicry.css-zibaldone.com/

[fantasai]

Gabriele Romanato wrote:
> Just finished to upload the new tests:
>
> basic/atomic
> http://www.css-zibaldone.com/test/more/css21.zip

In general, for assertion statements you should either
   - use the term "UA" instead of "browser" since some CSS processors aren't
     really browsers (e.g. PrinceXML's X/HTML+CSS -> PDF tool isn't really
     a browser)
or
   - use the passive voice, e.g. "Invalid declarations must be ignored"

For future reference filenames should follow the format in
   http://csswg.inkedblade.net/test/css2.1/format#filename-format
e.g. at-rules-000.xht rather than atrules0.html
But this is pretty easy for me to fix when I'm checking things in,
so it's not a problem for these tests. :)

atrules0.html

   Great test, just a few metadata comments: The test is testing that UAs
   ignore invalid @rules, but more specifically it's testing that an
   @import statement that occurs after a valid ruleset is ignored.
   So I'd change the assertion to
     "@import statements that occur after a valid ruleset must be ignored"
   (and change the title to something like "@import after ruleset")


Since the atrules0.css and atrules1.css are used in multiple tests, let's
name them "import-fail.css" and "import-pass.css". We'll keep them in the
support/ directory, and future tests can use them too.


atrules1.html

   Good test, just a few comments:
     a) Please use @media all, since these tests need to work on all UAs. :)
     b) Also, please indent code inside braces


blocks1.html

   Umm.. I can't find the spec text that would define how this is parsed.
   I'm going to post to www-style, I'll have to get back to you on this test!

blocks2.html

   This test would be better written with the style rule
     p  {color: green; {color: red }; border: solid green; }
   and a requirement that the text be green *and* have a solid green border.
   The UA isn't supposed to ignore the entire block if there's invalid syntax
   in it, it's only supposed to ignore the invalid piece of it. So in this case
   it should throw out "{color: red };" but keep the other two declarations.

blocks3.html

   Again, I'd write the CSS as
     p {* color: red; border: solid green; }
   and require the green border and no red. This way we're testing that the
   declaration is thrown out but not the whole rule.

~fantasai

[Gabriele Romanato]

thanks for your first comments.

1. UA vs browser
    That's due to my incorrect assumption. I know the prince formatter, since I've translated Hakon's thesis.

2. must vs should
    I've used should since IE parses incorrectly most of these testcases.
    see nested media rules and nested brackets.
    I don't think that's due to a lack in the specs.
   that's probably due to an incorrect error flagging.
   I say 'probably' since we do not know the css scanner and the css parser of IE
  NS_ERROR vs IE_ERROR?

thanks again. :-)
--
http://www.css-zibaldone.com/
http://mimicry.css-zibaldone.com/

[fantasai]

Gabriele Romanato wrote:
> Just finished to upload the new tests:
>
> basic/atomic
> http://www.css-zibaldone.com/test/more/css21.zip

I've been looking at some of David Baron's tests, and he's
using 'background' instead of 'color'. That makes the red/green
easier to see, so I'd suggest doing that in the future. But your
existing tests are fine as-is, so you don't need to change them
unless you want to.

There are a few tests here that could have more specific titles
and assertions, but since they're otherwise ok I'm just going to
make the changes and add them rather than asking you to resubmit.
I've noted which tests are added and what changed:

char0.html

   I'd suggest mixing up the escape syntax here: adding
   zeros to test the different escape lengths and throwing
   in whitespace to make sure it gets swallowed.

char1.html

   Added as
     filename: escapes-009.xht
     title   : Incorrect Keyword Letter Escape
     assert  : Backslash cannot escape a hex digit.

char2.html

   Added as
     filename: escapes-010.xht
     title   : Unicode-escaped Braces
     assert  : Unicode escapes cannot substitute for '{' or '}' in CSS syntax.

char3.html

   David Baron has already written almost exactly the same test
     http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/t040103-ident-08-c.xht
   so I think we will skip this one.

char4.html, char5.html, char6.html, char7.html, char8.html,

   These are actually invalid XHTML because XHTML doesn't allow '-', '@', or '_'
   at the beginning of IDs. David Baron and Ray Kiddy put together some tests
   that work around this issue, here:
     http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/t040103-ident-02-c.xht
     http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/t040103-ident-03-c.xht

   So we will skip these, too.

char9.html

   This is an excellent test, and I can accept it as-is, but I'd like
   to suggest adding some more {color: red;} rules using escapes for
   other white space characters such as tab and space. Also, you can
   try adding similar rules with the escapes placed inside the braces.
   That will create a more comprehensive test.

   I'd also change the assertion to
     "Unicode escapes cannot substitute for whitespace in CSS syntax."

char10.html, char11.html

   Since these are both almost the same, I'm going to just take char11.html.
   Add a "help" link to
     http://www.w3.org/TR/CSS21/selector.html#matching-attrs
   and this is good to go.

char12.html

   This is also a very nice test. I suggest however adding a second
   red rule with the \20 after the keyword.

If you haven't already, I'm going to need you to fill out the form here:
   http://www.w3.org/2002/09/wbs/1/testgrants2-200409/
to give W3C permission to use your tests.

Thanks a lot for taking the time to do this, it's a great help~ I'll
get through all your tests eventually. :)

~fantasai

[Gabriele Romanato]

thanks. I signed up and filled the form. bye && greetings :-)

[fantasai]

Gabriele Romanato wrote:
> Just finished to upload the new tests:
>
> http://www.css-zibaldone.com/test/more/

comments0.html
comments1.html
comments3.html
comments4.html

   These four are short enough and related enough that I'd combine
   them into one test, similar to
     http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/t040109-c17-comments-00-b.xht

comments5.html

   This looks pretty good. I've checked it in as sgml-comments-000.xht.

   I also suggest creating

     - a more advanced version that tests different valid combinations of '<!--',
       '-->' and other bits of CSS.
     - an invalid version that makes sure '<!--' and '-->' in invalid places
       causes those rules to be ignored
     - an invalid version that makes sure combinations of '<', '!', '-', '>' that
       don't form '<!--' and '-->' also cause their associated rules to be ignored.

declaration1.html
declaration2.html

   For both of these, you should combine the valid declaration and the invalid
   declaration into one style rule. Preferably there should be a valid declaration
   both before and after the invalid declaration. We need to make sure that only the
   invalid declaration is ignored, not the whole style rule.

key.html

   This is already covered by dbaron's test
     http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/t040102-keywords-00-b.xht
   so I think we'll skip it.

declaration0.html
parsingerror0.html

   I'd combine these two into one test, starting with
     p {
       color: green;
       text-color: red;
       font-color: red;
   and then adding more rules that append or prepend letters and/or punctuation to
   'color', e.g.
       -color: red;
       @color: red;
       color-: red;
       color(): red;
   etc. Since "font-color" and "text-color" are rather arbitrary strings that probably
   wouldn't be in the parser, it's unlikely that a UA will fail on those. It's more likely
   that the parser doesn't know where to begin, where to stop, and/or ignores unexpected
   punctuation instead of throwing out the whole declaration.

parsingerror1.html

   This is not so much a declaration parsing test as a color value parsing test. I'd
   link to
      http://www.w3.org/TR/CSS21/syndata.html#color-units
   as the primary section. Also, we don't know if a broken UA would treat #ff00 as red
   or yellow or some other color, so I'd just assert that the line is green and not
   mention red.

parsingerror2.html

   Again, you want to combine these into one style rule and make sure only the invalid
   declarations are thrown out, not the whole style rule. I'd also split each error
   into its own declaration, e.g. split "color:: red !" into "color:: red;" and
   "color: red !".this

parsingerror3.html

   I'd suggest splitting out the @font-face rule and turning this into a nested @media
   rule test for
     http://www.w3.org/TR/CSS21/media.html#at-media-rule
   You'll need to add some valid rules inside the top-level @media rule to make sure
   they aren't ignored, that only the rules inside the nested @media rule are ignored.

parsingerror4.html

   This test is incorrect. You need to swap "green" and "red".

parsingerror5.html

   Great test, however I'd change it slightly to add something like
     background: red;
     border: solid green;
   (and change the description appropriately) to make sure the parser recovers after
   the unfinished string.

rulesets0.html

   This is also a great test, but I'd mark it as primarily a test for Selector grouping
     http://www.w3.org/TR/CSS21/selector.html#grouping

rulesets1.html

   Similarly, I'd mark this as primarily a test for Descendant selectors
     http://www.w3.org/TR/CSS21/selector.html#descendant-selectors
   Also, I'd add a few rules doing such a combination with ID selectors or the universal
   selector
     div*
     div#foo
   Because the punctuation ends parsing of the div's token, these are more likely to
   trigger errors than combining alphanumeric tag selectors.

~fantasai

[fantasai]

Gabriele Romanato wrote:
> Just finished to upload the new tests:
>
> http://www.css-zibaldone.com/test/more/

adjacent0
adjacent1
adjacent2
attribute0
attribute1
attribute2
attribute3
attribute4
attribute5
attribute6
attribute7

These all look correct to me. I'd change the tests to either
use backgrounds or bold text to make the colors clearer, and
use blue, orange, and magenta which stand out and don't have
the special meaning of green.. but the tests are pretty good
as-is.

~fantasai

[fantasai]

Gabriele Romanato wrote:
> Just finished to upload the new tests:
>
> http://www.css-zibaldone.com/test/more/

before-after0

I'd use two identical paragraphs in this one, the first and the
second having exactly the same content except one of them the first
and last parts of the sentence are in <span> elements and the other
they are generated with :before and :after.

childselector0
childselector0
childselector0
class0
class1
class2

These all look good as well, again my only comment is to make the
colors clearer by using bold text or backgrounds and using blue,
orange, and fuchsia instead of green, black, and blue.

~fantasai

[fantasai]

Gabriele Romanato wrote:
> Just finished to upload the new tests:
>
> http://www.css-zibaldone.com/test/more/

descendantselector0.html
descendantselector1.html

The problem with these tests is that, because 'color'
inherits, the test will still pass if the UA applies
the color to the ancestor instead of the descendant.
You'll have to find some other property to use for
testing.

dinamicpseudoclasses0.html

You need to say specifically what colors it will get,
because the UA may have a default color change that
is not the same as what we're looking for.

dinamicpseudoclasses1.html
dinamicpseudoclasses2.html

Again the instructions need to be more specific about
the expected change.

dinamicpseudoclasses3.html

Form controls are outside the scope of the spec, so
this test can't be included. You could write the same
test with regular links, however, since those can be
styled and also :focus'ed

first-child0.html
first-child1.html

This needs to require that the filler text be gray
(or some other more obvious color). And also again,
you should make the colors clearer by using bold
text or backgrounds and using blue, orange, and
fuchsia instead of green, black, and blue. They are
good tests, however.

first-letter0.html

I'd rewrite this test to make the test separate from
the instructions, and instead of describing the :first-letter
styles, have two identical paragraphs

   .test, .control {color: green; font-weight: bold; font-size: 1.8em;}

   <p class='test'>Paragraph</p>
   <p><span class='control'>P</span>aragraph.</p>

This type of test is much quicker to scan.

first-line0.html

Like the first-child tests, you need to make the
filler text part of the text. Pick a more obvious
color and require that it be that color and not
be green. (Also, you should make this paragraph
bold so that the colors stand out.)

grouping0.html

Good test. I'd make the fonts bold so that the color
stands out; other than that I see no problems.

grouping1.html

Same as above. Also, remove "not red", as it's not
necessary and is unnecessarily different from the
previous test.

id0.html
id1.html

Very good tests. As with the class tests, I'd make
the colors clearer by using bold text or backgrounds
and using blue, orange, and fuchsia instead of green,
black, and blue.

lang0.html

I'm going to skip over this test, since Eira has submitted
a set of :lang tests that are more comprehensive.

link-visited0.html
link-visited1.html

These do a good job of testing the :visited pseudo-class
but they don't actually test the :link pseudo-class. Also
the link should say "Follow" instead of "Click" so that
the instructions are accurate for non-mouse navigation.

typeselector0.html
universalselector0.html

These are both good tests, but I'd make the text bold so
that the color stand out, and use blue, orange, and fuchsia
instead of green, black, and blue in the type test.

~fantasai

[fantasai]

Gabriele Romanato wrote:
> Just finished to upload the new tests:
>
> http://www.css-zibaldone.com/test/more/

cascade0.html

This test is covered by
   http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/t060401-c32-cascading-00-b.xht
already, so unless we're going for splitting up that test,
I don't think we should add it. It's a good test, though.

cascade1.html

This one isn't already covered. I'd make the text bold
and use the existing support/a-green.css style sheet, but
it's also acceptable as-is.

important0.html

This one's covered by
   http://www.w3.org/Style/CSS/Test/CSS2.1/current/xhtml1/t060402-c31-important-00-b.xht

important1.html

This one isn't, though. :) I'd make the text bold, but
otherwise it looks good.

inheritance0.html
inheritance1.html

These don't test inheritance. I'm not sure what they're testing,
maybe background-color defaulting to transparent.

specificity0.html
specificity0.html
specificity0.html

These are all good tests. The :first-line ones need
   white-space: nowrap
applied to the table, and the text should all be bold.

I'd also trim the <title>s so they're more compact (they really
don't need all the section headers) and make the assertion specific
to what exactly is being tested. But otherwise they're good.

~fantasai

[fantasai]

fantasai wrote:
>
> specificity0.html
> specificity0.html
> specificity0.html

That should've been

specificity0.html
specificity1.html
specificity2.html
specificity3.html
specificity4.html
specificity5.html
specificity6.html

I hit the Send key combo by mistake.

~fantasai