Re: content-072.htm is invalid

On Mon, 25 Oct 2010, Boris Zbarsky wrote:
>
> Gecko, Presto, and Webkit all support attr() in generated content.  I 
> would assume IE9 does too.

Ah, indeed, I didn't consider the attr() for 'content'.

I just tested IE8 and trunk Gecko, WebKit, and Opera with this demo:

   <!DOCTYPE html>
   <style>
    script { display: block; }
    script:before { content: 'a' attr(defer); }
   </style>
   x<script defer></script>

...and they all displayed "x a" not "x adefer", so I don't see the 
compatibility problem here.


On Mon, 25 Oct 2010, Arron Eicholz wrote:
> 
> 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.
> 
> http://test.csswg.org/suites/css2.1/20101001/html4/content-072.htm

This test is invalid as the attribute's value is the empty string. Every 
browser I was able to test (Gecko, WebKit, Opera, and IE8) agree.


> Unfortunately we only really have the HTML 4.01 spec to rely on. It's 
> the only current HTML Recommendation available for CSS.

This is false. This HTML specification now is more mature than HTML 4.x 
has ever been and can be reliably used as a reference:

   http://whatwg.org/html


> I am not really trying to argue, in fact I personally agree with you 
> about the state of HTML 4.01.

If we all agree then why are we even bothering to have this discussion? We 
don't have to blindly follow process rules that make no sense.

Bureaucracy is opt-in. What matters is interoperability. The process you 
are following is harming interoperability.


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

No, it could just as easily point to the contemporary HTML specification.


> Until that changes I see no reason to remove a test from the test suite 
> that is a valid HTML markup testing CSS features.

There is a simple reason: the test is out of touch with reality and will 
harm interoperability.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 25 October 2010 20:28:52 UTC