This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13034 - Consider [TreatNullAs=EmptyString] for some reflected attributes
Summary: Consider [TreatNullAs=EmptyString] for some reflected attributes
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2011-06-23 19:27 UTC by Aryeh Gregor
Modified: 2011-10-04 18:25 UTC (History)
13 users (show)

See Also:


Description Aryeh Gregor 2011-06-23 19:27:32 UTC
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 "":

#document.alinkColor (<body alink>)
#document.bgColor (<body bgcolor>)
#document.fgColor (<body text>)
#document.linkColor (<body link>)
#document.vlinkColor (<body vlink>)

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.)
Comment 1 Michael[tm] Smith 2011-08-04 05:02:17 UTC
mass-moved component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-08-10 01:13:49 UTC
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 ""?
Comment 3 Simon Pieters 2011-08-10 09:23:57 UTC
Because it aligns with ES ToString. We want "null" unless compat dictates "".
Comment 4 Jonas Sicking (Not reading bugmail) 2011-08-22 20:43:32 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2011-09-21 23:09:42 UTC
Adrian, do you have any input here?
Comment 6 Travis Leithead [MSFT] 2011-09-29 20:56:07 UTC
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.
Comment 7 Ian 'Hixie' Hickson 2011-09-29 22:11:52 UTC
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:

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.
Comment 8 contributor 2011-09-29 22:33:21 UTC
Checked in as WHATWG revision r6600.
Check-in comment: Legacy IDL attribute compatibility WebIDL fix.
Comment 9 Aryeh Gregor 2011-10-04 18:25:08 UTC
Tests updated: