There are a ton of features in the web platform that take a URL. (As the platform is build around URLs, that makes a ton of sense, too.) XMLHttpRequest, <img>, background-image, <script>, @font-face, … The semantics around obtaining a resource from such a URL however are not very well defined. Are redirects followed? What if the server uses HTTP authentication? What if the server returns 700 as status code for the resource? Does a data URL work? Does about:blank work? Is the request synchronous? What if I use a skype URL? Or mailto? Is CORS used? What value will the Referer header have? Can I read data from the resource returned (e.g. via the canvas element)? Can I display it?
For what seems rather trivial, is actually rather complicated.
At the moment Ian Hickson has defined some of this in the HTML Standard. In an algorithm named fetch. Then CORS came about (for sharing cross-origin resources) and the idea was that it would neatly layer on top, but it ended up rather intertwined. And now there is another layer controlling fetching, named CSP. To reduce some of this intertwinedness and simplify defining new features that take a URL, I wrote the Fetch Standard. It supersedes HTML fetch and CORS and should be quite a bit clearer about the actual model as well as fix a number of edge cases.
It is not entirely done, but it is at the point where review would be much appreciated.