Re: Setting IDL attributes that map enumerated content attributes

On Thu, Mar 11, 2010 at 10:06 AM, Boris Zbarsky <bzbarsky@mit.edu> 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.

Wouldn't the "throw an error" bit break things that set <input>s to
unknown @types?  Hell, I use a userscript that does that right now
(changing type=password to type=visible-password).

~TJ

Received on Thursday, 11 March 2010 16:12:36 UTC