Re: Setting IDL attributes that map enumerated content attributes

On Mar 11, 2010, at 8:06 AM, Boris Zbarsky wrote:

> The text at http://dev.w3.org/html5/spec/infrastructure.html#reflect  
> says:
>
>  "If a reflecting IDL attribute is a DOMString whose content attribute
>   is an enumerated attribute ...
>   ....
>   on setting, if the new value is an ASCII case-insensitive match for
>   one of the keywords given for that attribute, then the content
>   attribute must be set to the conforming value associated with the
>   state that the attribute would be in if set to the given new value,
>   otherwise, if the new value is the empty string, then the content
>   attribute must be removed, otherwise, the setter must raise a
>   SYNTAX_ERR  exception."
>
> I just tested, and IE seems to be the only browser I have that  
> raises such a SYNTAX_ERR exception.  Gecko, Webkit (both Chrome and  
> Safari incarnations) and Opera all allow the set to happen, though  
> exact behavior after that is not interoperable: Webkit silently  
> ignores the set, while Gecko and Opera update the content attribute  
> to the given value.
>
> I would obviously prefer the Gecko/Opera behavior here, since that's  
> simplest in terms of implementation complexity for me.  But past  
> that, I strongly object to moving from a situation where no  
> exception is thrown to one where an exception is thrown.  That's  
> likely to lead to web compatibility issues, in my experience,  
> especially given the current tendency towards "IE" and "not IE"  
> codepaths and the fact that none of the non-IE browsers throw an  
> exception.

I agree. It is a huge compatibility risk to change any API to throw an  
exception if it did not previously.

Can we get this issue in <http://www.w3.org/Bugs/Public/>?

Regards,
Maciej

Received on Thursday, 11 March 2010 17:40:21 UTC