W3C home > Mailing lists > Public > public-css-testsuite@w3.org > March 2009

RE: attribute-value-selector-004.xht not well formed

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Tue, 10 Mar 2009 12:26:47 -0700
To: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <5D97C7EB4695104AB6345E56FE356B19408A0DDAA2@NA-EXMSG-C125.redmond.corp.microsoft.com>
> If it accepts the attribute it would not drop a "p, [1badattr]" rule
> and
> therefore make the style red as dbaron suggests. This is has nothing to
> do
> with whatever the markup language does and is completely done at the
> parsing level. In any implementation of CSS you can never reach the
> scenario you are describing so it makes no sense to test it in that
> particular way. (And if you really must, you can test it by matching
> the
> attribute value using an IDENT rather than the attribute name as I
> suggested earlier.)

Correction: "in a *correct* implementation of CSS, you can never reach that scenario". These are test cases; they cannot, by definition, assume the implementation to be correct. 

David's proposal does verify that p did not turn red but then assumes the [1badAttr] selector to be the only possible cause. So if my own amateurish early-stage CSS implementation selected [1badAttr] and had a cascade bug causing color to not get overridden in this case - or maybe simply no or very little cascading code yet - I would pass his version of the test with flying colors because XHTML well-formedness demands it. Would that be helpful to me as an implementor ? 

You may call this overly conservative. But I'd rather be conservative and thorough first, well-formed second. This is not a web site. It's a test suite.

Received on Tuesday, 10 March 2009 19:27:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:18 UTC