18290 2012-07-18 17:58:42 +0000 Consider making `null` for reflecting IDL attributes remove the content attribute 2013-02-07 18:58:51 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED NEEDSINFO http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes P3 normal --- 1 contributor eoconnor eoconnor ian mike plh public-html-admin public-html-wg-issue-tracking zcorpan public-html-bugzilla oldest_to_newest 71045 0 contributor 2012-07-18 17:58:42 +0000 This was was cloned from bug 17283 as part of operation convergence. Originally filed: 2012-06-01 11:34:00 +0000 ================================================================================ #0 contributor@whatwg.org 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 ================================================================================ #1 Simon Pieters 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. ================================================================================ #2 Simon Pieters 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. ================================================================================ #3 Simon Pieters 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. ================================================================================ #4 Ian 'Hixie' Hickson 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? ================================================================================ #5 Ian 'Hixie' Hickson 2012-07-10 16:26:42 +0000 -------------------------------------------------------------------------------- (is there a corresponding bug on WebIDL about changing the behaviour for all attributes?) ================================================================================ #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. ================================================================================ 72224 1 Ms2ger 2012-08-15 17:13:25 +0000 Filter on [Idon'tcareaboutHTMLWGbugspam]. 73342 2 eoconnor 2012-09-06 17:50:51 +0000 As Ian points out in https://www.w3.org/Bugs/Public/show_bug.cgi?id=17283#c8 such a change has the potential to be massively backwards incompatible. We shouldn't make such a change in the HTML5 timeframe. Assigning this to HTML.next so we can re-evaluate in the future. 81656 3 robin 2013-01-21 15:57:53 +0000 Mass move to "HTML WG" 81767 4 robin 2013-01-21 16:00:34 +0000 Mass move to "HTML WG" 82706 5 eoconnor 2013-02-07 18:58:51 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Additional Information Needed Change Description: No spec change. Rationale: We shouldn't make this spec change before we hear from a browser engine which has made the change and found the resulting level of breakage acceptable. Let's revisit this when we've heard from such an implementation.