This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
WebIDL now says that converting null to DOMString should result in "null" instead of "". This largely matches IE/Opera and contradicts Gecko/WebKit. Usually it's a better idea to match Gecko/WebKit, but I assume there was some good reason for it. However, IE9 converts the following reflected attributes to "" instead of "null", so all browsers except Opera convert them to "": body.aLink body.bgColor body.link body.text body.vLink #document.alinkColor (<body alink>) #document.bgColor (<body bgcolor>) #document.fgColor (<body text>) #document.linkColor (<body link>) #document.vlinkColor (<body vlink>) font.color frame.marginHeight frame.marginWidth hr.color iframe.marginHeight iframe.marginWidth img.border object.border table.bgColor table.cellPadding table.cellSpacing td.bgColor th.bgColor tr.bgColor It would be more consistent to have these convert to "null" like everything else as the current spec requires, especially since the list is pretty short, but it wouldn't match browser behavior. So I'm just documenting the list in case we want to sacrifice some consistency in favor of better matching current reality, and add [TreatNullAs=EmptyString] to these. I have no problem with a WONTFIX. (Note: IE9 also treats null as an empty string for basefont.color, marquee.bgColor, and table.border. But we'd have no interop on those anyway: Gecko doesn't support the first two, and setting table.border to null or "" makes the attribute "1"; and WebKit unsets the DOM attribute of all three when you set the IDL attribute to null.)
mass-moved component to LC1
Anyone have any opinion on this? How about moving the whole spec over to [TreatNullAs=EmptyString]? Why is the default to treat null as "null" rather than ""?
Because it aligns with ES ToString. We want "null" unless compat dictates "".
I don't have a strong opinion. It's a pretty short list of mostly/only deprecated attributes. We need to flip our default handling in Gecko and it'd be interesting to see what would happen if we didn't add special handling for these attributes to see if something fails. I'd of course also love to hear from microsoft why they have these exceptions.
Adrian, do you have any input here?
I've been meaning to do an exhaustive test of our DOM in order to document any exceptions we may have to the default null->"null" and undefined->"undefined" conversions... so thanks Aryeh! These conversions (and APIs!) are carryovers from our classic behavior--I don't have any data on what the web compatibility story might be like for these. Considering that old versions of IE are probably the biggest consumer of these APIs from a compatibility standpoint, I think the safest approach for web compat is to simply call out each of these in HTML5 with the [TreatNullAs=EmptyString] annotation. As was said before, its a pretty short list.
Cool, thanks. 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: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r6600. Check-in comment: Legacy IDL attribute compatibility WebIDL fix. http://html5.org/tools/web-apps-tracker?from=6599&to=6600
Tests updated: http://dvcs.w3.org/hg/html/rev/1822fb46fc41