Bug 17283 - Consider making `null` for reflecting IDL attributes remove the content attribute
Summary: Consider making `null` for reflecting IDL attributes remove the content attri...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-01 11:34 UTC by contributor
Modified: 2013-03-09 01:14 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-06-01 11:34:51 UTC
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
Comment 1 Simon Pieters 2012-06-01 11:47:17 UTC
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.
Comment 2 Simon Pieters 2012-06-01 11:49:33 UTC
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.
Comment 3 Simon Pieters 2012-06-01 11:57:42 UTC
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.
Comment 4 Ian 'Hixie' Hickson 2012-07-10 16:18:13 UTC
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?
Comment 5 Ian 'Hixie' Hickson 2012-07-10 16:26:42 UTC
(is there a corresponding bug on WebIDL about changing the behaviour for all attributes?)
Comment 6 Ms2ger 2012-07-10 16:56:56 UTC
(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.
Comment 7 contributor 2012-07-18 17:58:45 UTC
This bug was cloned to create bug 18290 as part of operation convergence.
Comment 8 Ian 'Hixie' Hickson 2012-08-24 19:08:33 UTC
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.
Comment 9 Ian 'Hixie' Hickson 2012-08-27 22:30:06 UTC
Marking NEEDSINFO. The info I need is that a browser has done this and it wasn't catastrophic.
Comment 10 Ian 'Hixie' Hickson 2012-08-27 22:30:42 UTC
(moving to LATER so it doesn't drop off my radar)
Comment 11 Ian 'Hixie' Hickson 2013-03-09 01:14:51 UTC
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.