[Bug 23532] Dealing with undefined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23532

--- Comment #27 from Boris Zbarsky <bzbarsky@mit.edu> ---
(In reply to Domenic Denicola from comment #20)
> I thought we were discussing WebIDL rules, not what specific APIs should do.

If you change the meaning of a given string of WebIDL, that immediately changes
all APIs that use that string of WebIDL.

The only options to not do that are to either make the new behavior uses a new
syntax not used in current APIs or to go through all existing APIs and change
them (or some subset of them, perhaps) to use some new syntax that opts out of
the new behavior.

> That said, we can still make fixes in the name of increased consistency
> where possible, and I'd argue that if setAttribute doesn't throw for
> undefined, it should not throw for missing argument. From what I can tell
> you believe this is still web compatible?

It's web compatible.  I just think it's developer-hostile.

(In reply to Joshua Bell from comment #22)
> Assuming func is not overloaded, then in Blink (and WebKit last I knew)
> func() throws TypeError but func(undefined) coerces.

That's not the case in many cases.  See the simple testcase linked at the end
of comment 12.

On the other hand, in Chrome document.querySelector() (with no arguments) does
throw due to what looks like an arguments.length check.  But
document.getElementById() (again, with no arguments) silently returns null.  So
I can't tell when WebKit/Blink treat no argument as undefined and when they
throw an exception.  Certainly it seems wholly uncorrelated with what any spec
says right now.

(In reply to Jonas Sicking from comment #26)
> And then slowly try to migrate old APIs to the new convention.

In the long run that gives us a mix of APIs using the two conventions, I would
expect...  Happy to see someone prove me wrong.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 24 October 2013 00:27:05 UTC