Re: Conformance requirements on browsers

2013-09-12 10:14, Simon Pieters wrote:
> So in general if the spec doesn't have requirements to do something, 
> nothing must be done. It doesn't have negative requirements in general 
> because there are an infinite things one could do.

So you do mean that the spec requires certain things and forbids 
anything else? Sounds rather drastic. Or did you mean “nothing needs to 
be done” instead of “nothing must be done”?

>> Does this mean that browsers are required to parse <bgsound> as an 
>> empty element
> Yes.
>> and treat it as an HTMLUnknownElement object (which means just that 
>> in scripting you can detect it as HTMLUnknownElement but otherwise 
>> it’s HTMLElemen, right?)
> Yes.
>> but can then do whatever they want with it?
> No.
>> Or shall they otherwise ignore it?
> Yes.

How can this be inferred from the text? If this is the intent, shouldn’t 
clause 2.2.1 include a conformance requirement that forbids user agents 
from supporting elements or attributes not defined in the spec? 
Currently, 2.2.3 says: “Vendor-specific proprietary user agent 
extensions to this specification are strongly discouraged.” No matter 
how strongly it is put, it is not presented as a conformance criterion. 
So it is difficult to imagine why the spec would forbid browsers from 
supporting old elements and attributes that are mentioned but not 
defined in the spec.


Yes, blink has a description, in terms of styling. I quoted the list of 
elements that have been defined as using HTMLUnknownElement, and I 
didn’t mean they are all just mentioned, not described. I rather tried 
to point out that it is a rather mixed collection.

Regarding blink, the rule

blink { text-decoration: blink; }

is rather pointless, because browsers have dropped support to 
text-decoration: blink, too, when they dropped support to <blink>.


Received on Thursday, 12 September 2013 08:49:29 UTC