17283 2012-06-01 11:34:51 +0000 Consider making `null` for reflecting IDL attributes remove the content attribute 2013-03-09 01:14:51 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes P3 normal Unsorted 1 contributor ian eoconnor ian mike Ms2ger robin zcorpan contributor oldest_to_newest 68498 0 contributor 2012-06-01 11:34:51 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html Multipage: http://www.whatwg.org/C#reflecting-content-attributes-in-idl-attributes Complete: http://www.whatwg.org/c#reflecting-content-attributes-in-idl-attributes Comment: Consider making `null` for reflecting IDL attributes remove the content attribute Posted from: 2001:4c28:a030:30:3cae:bc42:712:f92c by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.229 Version/11.64 68501 1 zcorpan 2012-06-01 11:47:17 +0000 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. 68502 2 zcorpan 2012-06-01 11:49:33 +0000 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. 68503 3 zcorpan 2012-06-01 11:57:42 +0000 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. 69790 4 ian 2012-07-10 16:18:13 +0000 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? 69791 5 ian 2012-07-10 16:26:42 +0000 (is there a corresponding bug on WebIDL about changing the behaviour for all attributes?) 69793 6 Ms2ger 2012-07-10 16:56:56 +0000 (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 > attributes?) We agreed not to do that; I think we can and should stay with that decision. 71046 7 contributor 2012-07-18 17:58:45 +0000 This bug was cloned to create bug 18290 as part of operation convergence. 72719 8 ian 2012-08-24 19:08:33 +0000 Realistically speaking, this is a massive potentially breaking change. See jst's comment in: https://bugzilla.mozilla.org/show_bug.cgi?id=772526#c2 I'm fine with doing this, but not before a browser has forged the way. 72865 9 ian 2012-08-27 22:30:06 +0000 Marking NEEDSINFO. The info I need is that a browser has done this and it wasn't catastrophic. 72866 10 ian 2012-08-27 22:30:42 +0000 (moving to LATER so it doesn't drop off my radar) 84158 11 ian 2013-03-09 01:14:51 +0000 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.