4 ms·
To be fair, the "standard" part of this proposal doesn't really have anything to do with headless browsers. You could just as easily have a typical server-side
by unlinkedlist 17y ago
To be fair, the "standard" part of this proposal doesn't really have anything to do with headless browsers. You could just as easily have a typical server-side app that generates these URLs as appropriate.
For example, a common approach to presenting content in an AJAXy kind of way is to just put a path after the hash. E.g.
http://www.example.com#/products/bungee-cords
It's probably really easy for the web app to figure out the right content to serve up for #/products/bungee-cords, headless browser or not.
I know you'll be saying, "Of course, but apps should be doing that anyway with progressive enhancement." That's all well and good, but that leads to two separate sets of URLs: one that most users see, and one that search engines see. This fixes that.
- seldo 17y agoI don't understand what you're saying. Firstly, web apps can never see anything after a # in a URL: the browser does not send it to them. Javascript can see it, but I don't think that's what you meant. With progressive enhancement, your URLs should look like http://www.example.com/products/bungee-cords http://www.example.com/products/bungee-cords. If clicked they should render the page as appropriate. JavaScript, if enabled, will attach a handler to the links and when it sees you trying to click on /products/bungee-cords will halt that click and instead make an AJAX request for the equivalent content. There should be no need to have # links whatsoever.
- boucher 17y agoThat ignores the fact that people want the URL field to reflect the current state of things, so that URLs can be copied out and pasted elsewhere. It also ignores the fact that there is no way to set the URL field (through JavaScript or any other mechanism) without actually triggering a page change.