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

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