2014 May 22, 9:25
The DOM location interface
exposes the HTML document's URI parsed into its properties. However, it is
ancient and has problems that bug me but otherwise rarely show up in the real world. Complaining about mostly theoretical issues is why blogging exists, so here goes:
- The location object's search, hash, and protocol properties are all misnomers that lead to confusion about the correct terms:
- The 'search' property returns the URI's query property. The query property isn't limited to containing search terms.
- The 'hash' property returns the URI's fragment property. This one is just named after its delimiter. It should be called the fragment.
- The 'protocol' property returns the URI's scheme property. A URI's scheme isn't necessarily a protocol. The http URI scheme of course uses the HTTP protocol, but the https URI scheme is
the HTTP protocol over SSL/TLS - there is no HTTPS protocol. Similarly for something like mailto - there is no mailto wire protocol.
- The 'hash' and 'search' location properties both return null in the case that their corresponding URI property doesn't exist or if its the
empty string. A URI with no query property and a URI with an empty string query property that are otherwise the same, are not equal URIs and are allowed by HTTP to return different content.
Similarly for the fragment. Unless the specific URI scheme defines otherwise, an empty query or hash isn't the same as no query or
But like complaining about the number of minutes in an hour
none of this can ever change without huge compat issues on the web.
Accordingly I can only give my thanks to Anne van Kesteren and the awesome work on the URL standard
moving towards a more sane (but still working
practically within the constraints of compat) location object and URI parsing in the browser.