In reply to this conservation:
@glennjones that's a tough one indeed. What else could IE do not to cause that issue? /cc @adrianba
Find it a little sad some of the browser APIs are introduced in such an incomplete state the only way to use them is in try/catch blocks
@glennjones are these implementation issues or spec ones?
@adrianba I don't know. Would not shipping a partial implementation help? @glennjones
@tobie @glennjones We shipped a complete implementation of what was in the File API spec at the time (which only defined static members).
@tobie @glennjones IE10+ only supported the static methods on URL so there is no constructor. At the time what else could it do but throw?
@tobie @adrianba I don't known the history, but it does look like the URL object should not have been extended in this way, not a IE issue!
@glennjones @tobie It's complicated because I think things were proceeding in parallel. I actually don't think there is a problem here.
@adrianba I'm not blaming IE, btw. We just don't have a good story for these issues. @glennjones
@tobie just looking at URL and URLUtils the constructor of URL takes 2 arguments to resolve absolute URL, but the early IE version blows up
@adrianba agreed. Still, that makes it painful for devs. There must be a better way. @glennjones
@adrianba sounds like the @urlstandard should have taken that in account then. @glennjones

@tobie @adrianba @w3ctag its an issue with API design, developer expectations and documentation. Wrote post: http://bit.ly/1RkmWqP

‐ Also on:
Mentions:
@glennjones BTW, I expect IE11 to be around for a long time, but not IE10.
@glennjones Not wonderful, but you might be able to test window.URL.prototype.constructor.length or some such. @tobie @adrianba @w3ctag
@robinberjon I'm sure you meant window.URL.prototype.constructor.prototype.constructor.length. #bettersafethansorry @glennjones @adrianba