[Bug 9227] New: Setting IDL attributes that map enumerated content attributes to invalid values should not throw

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9227

           Summary: Setting IDL attributes that map enumerated content
                    attributes to invalid values should not throw
           Product: HTML WG
           Version: unspecified
          Platform: PC
               URL: http://dev.w3.org/html5/spec/infrastructure.html#reflect
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec bugs
        AssignedTo: dave.null@w3.org
        ReportedBy: bzbarsky@mit.edu
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org, public-html@w3.org


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.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 12 March 2010 03:39:44 UTC