RE: content-072.htm is invalid

On  Monday, October 25, 2010 1:28 PM Ian Hickson wrote:
 > 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.
 
It's not invalid per the HTML5 spec either. HTML5 allows the defer attribute to be defined as 'defer="defer"'. If it is defined that way, and it is in the case, then CSS not HTML defines how the attribute should be returned. And in the attr() case in CSS 2.1 if there is a defined value it attr() should return it and will then return the attribute value 'defer'. If the case just defined only the attribute name with no value, then yes, I would agree that this case is ambiguous and would require potential removal without changes to the case.

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

Like I stated the HTML 5 spec is not a Recommendation. The link points to is a Draft.

> 
> > 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.
 
We don't blindly follow we evaluate and create policies based on discussion an compromise. Those policies should be followed or we have all sorts of problems. At this time I see no need to change the policies for the normative references in the specifications from the W3C.  If you feel any of the normative references need to change please raise this issue and the CSS working group can handle this appropriately in a dedicated thread.

> Bureaucracy is opt-in. What matters is interoperability. The process you
> are following is harming interoperability.
 
You may be correct but this would only mean you feel that the process is broken. If you feel it is broken bring it up to the working group and try and work with everyone that a change is necessary.

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

Again at this time that pointer has to be to a Recommendation or Proposed Recommendation.

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

Actually the test matches even what is defined in the HTML5 spec. I don't see how there is an issue with this case. The HTML 5 spec states that you can define the 'defer' attribute as 'defer="defer"' (which is what is in the case). The CSS spec is what states that the value from the attribute should be returned. HTML5 does not define what the attr() function should return for these attribute nor should it. HTML5 just defines that there are 3 potential ways to define the 'defer' attribute. If the 'defer' attribute is defined with an explicit valid value that explicit valid value should be returned by the attr() function. If the value is not explicitly defined then I agree that empty string should be returned.

--
Thanks,
Arron Eicholz

Received on Monday, 25 October 2010 21:07:39 UTC