4 ms·

For one, widespread support for that feature is relatively recent -- in fact, it's slated for the next version of IE. For another thing, it's a bit more compli

by chc 14y ago

For one, widespread support for that feature is relatively recent -- in fact, it's slated for the next version of IE. For another thing, it's a bit more complicated to implement (you need to have a valid URL for every little piece of every page on your site) for not a lot of benefit that most people would notice. In fact, if you don't do them really well, it might confuse people when their bookmarks don't take them to the start of the page. They're sort of the awkward middle child between permalinks to an index and permalinks to posts, and even if they were there people wouldn't want them as often as the other two. This would probably put it in the "Maybe get to this later" pile.

andrewaylett 14y ago
replaceState still works for changing the hash-code without updating the history list, so you can stay on the same 'page'. You can then read the hash-code using browsers like IE, just not create new ones. I used this as a quick hack to get permalinks on http://ares.aylett.co.uk/xkcd/ http://ares.aylett.co.uk/xkcd/ -- when you move (on at least FF and Chrome, but not IE), the hash-code updates, and at least FF, Chrome and IE can decode the hash-code on page load. Not to say that I don't agree with your conclusions about infinite scroll -- I'd much prefer sensible pagination.
epidemian 14y ago
Well, the inconsistencies between browsers is quite a good point if it would cause inconsistencies in user experience. I'd like to point out, however, that FB already does some kind of similar trick with the URL hash when browsing photos: if you open someone's photo, it'll open in a modal dialog where you can navigate to other photos and this in-page navigation _will_ change the URL hash. If you go to that modified URL directly (or refresh the page) FB will show a different page (inside the person's "album") with that photo. I'd reason that, for FB, a photo is more of a tangible thing than an item in your infinite stream, thus it deserves separate URLs when browsing the them.

by chc 14y ago

andrewaylett 14y ago

replaceState still works for changing the hash-code without updating the history list, so you can stay on the same 'page'. You can then read the hash-code using browsers like IE, just not create new ones. I used this as a quick hack to get permalinks on http://ares.aylett.co.uk/xkcd/ http://ares.aylett.co.uk/xkcd/ -- when you move (on at least FF and Chrome, but not IE), the hash-code updates, and at least FF, Chrome and IE can decode the hash-code on page load. Not to say that I don't agree with your conclusions about infinite scroll -- I'd much prefer sensible pagination.

epidemian 14y ago

Well, the inconsistencies between browsers is quite a good point if it would cause inconsistencies in user experience. I'd like to point out, however, that FB already does some kind of similar trick with the URL hash when browsing photos: if you open someone's photo, it'll open in a modal dialog where you can navigate to other photos and this in-page navigation _will_ change the URL hash. If you go to that modified URL directly (or refresh the page) FB will show a different page (inside the person's "album") with that photo. I'd reason that, for FB, a photo is more of a tangible thing than an item in your infinite stream, thus it deserves separate URLs when browsing the them.