Re: [whatwg/url] Good defaults on URL() (#71)

Hmm, I still care. One of the objections seems to be that in a contextless environment this cannot be resolved. In the bug that I posted, it was said that JavaScript doesn't have a MissingArgument exception and yet this thread is filled with purity objections (as far as I know, JavaScript exceptions are extendable). The exception thrown (also with a parser error) should be the equivalent of python's ValueError. Type is only relevant when passing non-string objects.
So if Node.js has no way of resolving relative URLs, then this should probably be in the lines of NotImplemented /  Unsupported / WhatHaveYou. But as it stands, the URL() object is not capable of handling input a user expects it to handle. The creation of RelativeURL for this, should then change URL to AbsoluteURL and URL should probably be an interface defining all methods but the constructor, so we can even create FilteredURL() for a soho proxy in node or privacy extension in the browser, a SecureProtocolURL(), which always returns the secure version of provided scheme, etc etc.
But note that splitting this into two objects, requires me to do partial parsing, which is exactly what I was looking to avoid and thought URL() was supposed to do. Or I catch the exception and start guessing what exactly the cause of the exception is (as there are three entirely different ones under the same umbrella and no way to determine programmatically which).
As for the sane default: The calling script's script element's ownerDocument location (so run up the tree, not reference a global, solved that too). Authors will understand that this is the only sensible default and will work for things like validating document resources in a user script (which is what triggered my issue) or grabbing all resource URLs for statistical purposes.
It is also very easy to understand from this perspective what the exceptions are going to be.

So my summary:
* If URL() is to handle only absolute URLs, then it should be renamed
* The exception thrown caused by parsing errors or the inability to resolve a relative URL should be in the value or implementation realm and not in type.
* It should be programmatically possible to determine why the construction of the object failed.
* Wheter the API is low level or not, it is the expectation of authors that it can handle any valid input
* Use one sane default, do not play the guessing game. From the default it should be easy to understand the exceptions.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/71#issuecomment-204037942