W3C home > Mailing lists > Public > public-css-testsuite@w3.org > October 2010

RE: content-072.htm is invalid

From: Arron Eicholz <Arron.Eicholz@microsoft.com>
Date: Mon, 25 Oct 2010 20:08:30 +0000
To: Ian Hickson <ian@hixie.ch>
CC: "L. David Baron" <dbaron@dbaron.org>, "Gérard Talbot" <css21testsuite@gtalbot.org>, "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <07349ECFC3608F48BC3B10459913E70B0C581D28@TK5EX14MBXC140.redmond.corp.microsoft.com>
On Monday, October 25, 2010 10:45 AM Ian Hickson wrote:
> On Mon, 25 Oct 2010, Arron Eicholz wrote:
> >
> > HTML5 has a bug here then because this is a big compatibility issue
> > with CSS and the attr() function.
> 
> Given that most (all?) browsers have never done this DTD-based expansion
> before, and that few (no?) browsers support attr(), I don't see a
> compatibility issue here. Is there a testcase I can use to see the
> interoperability issue here?
> 

Cases content-037 to content-155 of the CSS test suite cover the support of the attr() function. All major browser versions support the attr() function.
http://test.csswg.org/suites/css2.1/20101001/html4/


All browsers I have tested seem to do attribute expansion for attribute selectors or they at least handle the expanded defined value. There is only 1 case I have found (content-072) where there is inconsistency. Note that all the cases below explicitly define a value of the same name as the attribute. These tests are not assuming that the user agent create/generate a value based on the attribute name. Even in HTML5 boolean attributes are allowed to be specified with a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace. This means that content-072 should be valid even for HTML5.

CSS cases:
http://test.csswg.org/suites/css2.1/20101001/html4/content-066.htm

http://test.csswg.org/suites/css2.1/20101001/html4/content-072.htm

http://test.csswg.org/suites/css2.1/20101001/html4/content-100.htm

http://test.csswg.org/suites/css2.1/20101001/html4/content-103.htm


Note: that there are additional attributes that fall into this type of category that are not tested in the CSS test suite because the attributes exist on replaced elements.

> 
> > We absolutely should be testing everything that is in HTML 4.01 it’s a
> > normative reference in the CSS spec. This is how we determine if a
> > user agent is supporting things correctly for CSS.
> 
> If you want the test suite to be useful in the real world, there's no point
> hanging on to the fiction that HTML4 represents what browsers implement.
> A test suite based on HTML4's requirements rather than the contemporary
> HTML specification's would just be out of touch with what implementations
> do.
 
Unfortunately we only really have the HTML 4.01 spec to rely on. It's the only current HTML Recommendation available for CSS. If HTML5 were at the Recommendation stage the discussion would be different but it isn't, and we are a long way from that. I am not really trying to argue, in fact I personally agree with you about the state of HTML 4.01. CSS just needs to point to a certain level of specification as a normative reference and that happens to be the current HTML 4.01 spec. Until that changes I see no reason to remove a test from the test suite that is a valid HTML markup testing CSS features.

--
Thanks,
Arron Eicholz



Received on Monday, 25 October 2010 20:09:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 25 October 2010 20:09:18 GMT