Consider making `null` for reflecting IDL attributes remove the content
Posted from: 2001:4c28:a030:30:3cae:bc42:712:f92c by email@example.com
User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.229 Version/11.64
Opera willfully violates the spec when it comes to setting null to IDL attributes because we found several sites that broke, e.g. by setting <input>.max = null which caused the form to be unsubmittable.
We stringify null to "" for *all* DOMString IDL attributes. However, it occurred to us that the site compat problems were only related to IDL attributes that reflect content attributes. Gecko seems to stringify to "" for that case. WebKit seems to remove the content attribute. Either is probably Web-compatible.
I think removing the content attribute is nicer than setting it to the empty string. Consider the crossorigin attribute. The empty string is a valid keyword, so doing crossOrigin = null, if it stringifies to "", sets the attribute to the Anonymous state. There would be no way of setting it to the No CORS state, short of using removeAttribute('crossorigin') which is more verbose.
A place where it makes more sense to stringify null to "null" is localStorage.foo = null; since reading it back can be JSON.parse()d.
It would be "nice" to make getting the IDL attribute return null if the attribute is absent, but nobody does that so likely isn't compatible.
Is there an IDL attribute I can use to make "null" stringify to empty on setting for a DOMString IDL attribute, or does it have to be prose?
(is there a corresponding bug on WebIDL about changing the behaviour for all attributes?)
(In reply to comment #4)
> Is there an IDL attribute I can use to make "null" stringify to empty on
> setting for a DOMString IDL attribute, or does it have to be prose?
[TreatNullAs=EmptyString]; however, I think that what Simon proposes makes more sense. I filed <https://bugzilla.mozilla.org/show_bug.cgi?id=772526>.
(Another question is what to do with non-DOMString reflecting attributes; I'm not sure if we'd want to make the same change there in the same time frame, because that's somewhat hard with our current bindings.)
(In reply to comment #5)
> (is there a corresponding bug on WebIDL about changing the behaviour for all
We agreed not to do that; I think we can and should stay with that decision.
This bug was cloned to create bug 18290 as part of operation convergence.
Realistically speaking, this is a massive potentially breaking change. See jst's comment in:
I'm fine with doing this, but not before a browser has forged the way.
Marking NEEDSINFO. The info I need is that a browser has done this and it wasn't catastrophic.
(moving to LATER so it doesn't drop off my radar)
Given the lack of interest and the lack of browser vendors doing this, I'm punting this to WONTFIX. If any browser is interested in leading on this, and wants the spec changed accordingly based on their experience, please let me know and/or reopen the bug.