4 ms·

At first glance, this seems like a really half baked idea to me. Some immediate thoughts: - Wasn't there a draft spec floating around in the early 00s that tri

by mstade 8y ago

At first glance, this seems like a really half baked idea to me. Some immediate thoughts: - Wasn't there a draft spec floating around in the early 00s that tried to accomplish this, but didn't catch on? - Fragments are already used to link to fragments, albeit more author friendly than user friendly I suppose - This won't fly very well with sites that still make use of fragment based navigation, will it? (Believe it or not, I still see new projects use this over the history API!) - What happens if there's an element in a page with the id or name `targetText`? This is not mentioned in the very tiny compatibility section[1] (where some actual data wouldn't hurt, btw) - The linked proposal[2] already mentions that more specific fragment semantics is defined in other media types, so why not follow suit and propose the HTML spec is amended, instead of making this a user agent feature? - Fragments in URLs are already pretty useless in sites that don't load content until after the dom is ready, i.e. anything that just loads a bunch of JS and then builds the site in the client – how would this fare any better? [1]: https://github.com/bokand/ScrollToTextFragment#web-compatibility https://github.com/bokand/ScrollToTextFragment#web-compatibi... [2]: https://github.com/bokand/ScrollToTextFragment#encoding-the-text-snippet-in-the-url-fragment https://github.com/bokand/ScrollToTextFragment#encoding-the-...

leeoniya 8y ago
> (Believe it or not, I still see new projects use this over the history API!) want to guess which one doesnt need JS, or server-side handling to work?
- mstade 8y ago
  I think maybe you're misunderstanding what I meant by fragment based navigation – that's probably my fault. I refer to the shebang style fragments, that was used to implement deep linking in primarily JS driven sites. This of course watered down the use of fragments in pages, and nearly made them useless frankly. Ironically, the history API – which of course as you say requires JS to work – is what probably saved fragments from being completely useless, since it meant everyone could return to using paths for deep linking and still implement their sites as JS blobs if they so chose. Moreover it opened up for hybrid approaches, where the server can actually serve a pre-rendered site that's then amended by JS (or not!) since the server would now see the full path that users were navigating to, as opposed to /my-catch-all-entry-point. Servers never get to see the fragment, after all.
  - leeoniya 8y ago
    the issue is that your server now needs to somehow understand which part of the path is the "fragment" without any distinguishing characters by which to parse it out of the url. if the server now sees deep urls like `/products/patagonia/parkas`, how does it know which part is the fragment? is it /parkas or /patagonia/parkas? what if you have urls that are not completely uniform? or have different uniformity at different prefixes? the router needs to be more complex. but i agree that the history API has advantages over shebangs for deep app links.
    - mstade 8y ago
      Point isn't so much that the server needs to do anything, you can still just serve up the same response no matter the path, and have the client render different results – just as you would with a shebang style navigation in the past. The difference is that you know have options, which you didn't before since the server never saw the fragment part of the url, only / or /entry-point or whatever. So you can have more complex logic server side (really, this was done in the past long before in-client routing was a thing) but you don't have to, it can still be deferred to the client to deal with. Using shebang style navigation you never even really had the option – the history API enabled this.
      - giornogiovanna 8y ago
        Lots of (mostly free) hosting just serves the files you upload, so that wouldn't work unless you copied the files to be served at every possible route.
        amichal 8y ago
        “#” Fragments aren’t sent to the server at all. They are ONLY used to get to a specific anchor (old school) or processed by JavaScript to do something (often fake navigation by showing and hiding content). This article is adding a 3rd magic use for them.
        8y ago
samstave 8y ago
Honest question: is there a specific person who is smugly grinning about this at google. Like the people at FB who run around thinking how awesome they are for coming up with a new spying technique and what idiots the world is for not recognizing their innovation?
- mstade 8y ago
  I would hope not, but who knows? I guess it's more like the road to hell is paved with good intentions.
- gnomewascool 8y ago
  > Honest question: is there a specific person who is smugly grinning about this at google. I sort-of understand where you're coming from, but isn't this needlessly hostile? Unlike in the case of "spying innovation" you brought up, Chrome's "Scroll to Text" seems to be intended with the user's benefit in mind (and only indirectly Google's — via greater user satisfaction, but that's exactly the product design model we want). It would have obviously been far preferable if this had gone through the "proper channels" (discussion at the W3C, standardisation etc. first), but I don't think that there's any evidence to believe that anybody at Google thinks that they're the first to come up with this.

by mstade 8y ago

leeoniya 8y ago

> (Believe it or not, I still see new projects use this over the history API!) want to guess which one doesnt need JS, or server-side handling to work?

mstade 8y ago
I think maybe you're misunderstanding what I meant by fragment based navigation – that's probably my fault. I refer to the shebang style fragments, that was used to implement deep linking in primarily JS driven sites. This of course watered down the use of fragments in pages, and nearly made them useless frankly. Ironically, the history API – which of course as you say requires JS to work – is what probably saved fragments from being completely useless, since it meant everyone could return to using paths for deep linking and still implement their sites as JS blobs if they so chose. Moreover it opened up for hybrid approaches, where the server can actually serve a pre-rendered site that's then amended by JS (or not!) since the server would now see the full path that users were navigating to, as opposed to /my-catch-all-entry-point. Servers never get to see the fragment, after all.
- leeoniya 8y ago
  the issue is that your server now needs to somehow understand which part of the path is the "fragment" without any distinguishing characters by which to parse it out of the url. if the server now sees deep urls like `/products/patagonia/parkas`, how does it know which part is the fragment? is it /parkas or /patagonia/parkas? what if you have urls that are not completely uniform? or have different uniformity at different prefixes? the router needs to be more complex. but i agree that the history API has advantages over shebangs for deep app links.
  - mstade 8y ago
    Point isn't so much that the server needs to do anything, you can still just serve up the same response no matter the path, and have the client render different results – just as you would with a shebang style navigation in the past. The difference is that you know have options, which you didn't before since the server never saw the fragment part of the url, only / or /entry-point or whatever. So you can have more complex logic server side (really, this was done in the past long before in-client routing was a thing) but you don't have to, it can still be deferred to the client to deal with. Using shebang style navigation you never even really had the option – the history API enabled this.
    - giornogiovanna 8y ago
      Lots of (mostly free) hosting just serves the files you upload, so that wouldn't work unless you copied the files to be served at every possible route.
      - amichal 8y ago
        “#” Fragments aren’t sent to the server at all. They are ONLY used to get to a specific anchor (old school) or processed by JavaScript to do something (often fake navigation by showing and hiding content). This article is adding a 3rd magic use for them.
        8y ago

samstave 8y ago

Honest question: is there a specific person who is smugly grinning about this at google. Like the people at FB who run around thinking how awesome they are for coming up with a new spying technique and what idiots the world is for not recognizing their innovation?

mstade 8y ago
I would hope not, but who knows? I guess it's more like the road to hell is paved with good intentions.
gnomewascool 8y ago
> Honest question: is there a specific person who is smugly grinning about this at google. I sort-of understand where you're coming from, but isn't this needlessly hostile? Unlike in the case of "spying innovation" you brought up, Chrome's "Scroll to Text" seems to be intended with the user's benefit in mind (and only indirectly Google's — via greater user satisfaction, but that's exactly the product design model we want). It would have obviously been far preferable if this had gone through the "proper channels" (discussion at the W3C, standardisation etc. first), but I don't think that there's any evidence to believe that anybody at Google thinks that they're the first to come up with this.