Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page

Post by lucideer » Fri, Feb 15, 2019, 12:39 PM UTC

jypepin wrote: post #151

lucideer wrote: post #133

Earlier quoted context omitted.

> It's an abuse of the purpose of URL fragments So what they're saying is, they expect a clash of their abuse of URL fragments with others' abuse of URL fragmentsto be rare because... The arrogance here is astounding: "It's OK for us to use this, because others shouldn't be using it"

Aren't url fragment originally used for page position already? Like url.com/#title would scroll to the page the div with id "title"? In that case I don't feel like using url fragment for a word position is so much breaking it, it keeps the use of url fragment for info about page position, right?

Post by giornogiovanna » Fri, Feb 15, 2019, 12:47 PM UTC

mstade wrote: post #161

leeoniya wrote: post #123

Earlier quoted context omitted.

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 differ…

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 co…

Post by hiccuphippo » Fri, Feb 15, 2019, 1:06 PM UTC

xg15 wrote: post #109

Technical question, apart from the (valid IMO) political arguments: Google's idea to implement this is to append the text fragment to the URL in a "#targetText" pseudo-query-argument in the URL fragment part. This sounds like it would extremely easily break existing web pages who use the fragment part for their own state. In the blog post, there doesn't seem to be anything addressing this (or even just specifying how…

Post by deepstream » Fri, Feb 15, 2019, 1:08 PM UTC

lucideer wrote: post #221

jypepin wrote: post #151

Earlier quoted context omitted.

Aren't url fragment originally used for page position already? Like url.com/#title would scroll to the page the div with id "title"? In that case I don't feel like using url fragment for a word position is so much breaking it, it keeps the use of url fragment for info about page position, right?

Yes but this is about namespacing/syntax and likelihood of clashes. Normally, url fragments were intended to be used by page authors , making clashes impossible (page author controls both page and anchor syntax). Google are breaking this contract, but argue that the fact that they're using parameter-style syntax should not clash with author usage, because using parameter-style syntax is "an abuse" of the feature.

  https://www.spa/#!/path/to/view

  https://www.spa/#!/path/to/view&targetText=percent%20encoded

  web+text://https://www.spa/#!/route/to/view#targetText=percent%20encoded

Post by larkeith » Fri, Feb 15, 2019, 1:14 PM UTC

mediumdeviation wrote: post #63

larkeith wrote: post #33

Earlier quoted context omitted.

I must say I prefer the RFC version - while still vulnerable to rotting from text changes, at least it should still link to the same general vicinity.

HTML documents don't generally have the concept of lines since text reflow based on the way user agent (browser) is rendering the document. That's why the RFC only talks about text/plain MIME type - browsers render those with all line breaks intact. You can maybe use a CSS selectors, but that adds a tremendous amount of complexity and is not easy for non-web developers to read anymore.