7 ms·

Very significant limitation: it only links to the first instance of the target text. What is the expected behavior if you highlight a second instance of some t

Very significant limitation: it only links to the first instance of the target text. What is the expected behavior if you highlight a second instance of some target text and try to create a link to it? It’s bad that the spec doesn’t discuss it. I can see this happening with short selections, like linking to a single word. Seems like this could use more thought.

pasiaj 8y ago
Doesn’t the spec specify, that the link points to the first instance of the selected text? Does that not accurately define what happens when you try to link to a latter instance: It links to the first one.
- Buge 8y ago
  This isn't a question about where the browser will scroll. This is a question about what will the browser do if the user tries to create a link to something that can't be scrolled to.
- larkeith 8y ago
  That's not great from a UX point of view - for most users, their experience with the feature will be trying to use it, selecting a phrase, and having it silently link to an entirely different area.
kumarharsh 8y ago
Although you are right, it's already how browsers work in relation to IDs - only the first element with that ID is selected. (Yes, IDs are supposed to be unique, but it's not like HTML "breaks" if you don't follow this rule). Plus, you can always select more text.
dmortin 8y ago
They could add and index too, but linking to a search phrase is already prone to breakage if the text changes, so there's not much point in complicating it. Usually the same phrase is not repeated in the text if you select more than 1-2 words.
larkeith 8y ago
Perhaps it could automatically expand the selection until it becomes unique, and support an index property for cases in which that would result in an unreasonably large selection (or hits EOF). Using indices alone would also work, but would be exceptionally prone to link rot as text changes, especially in the case of short (e.g. 1-word) selections.
nbevans 8y ago
They could fix this by having a second query string parameter, say, "targetInstance". Which would take the number of the instance. Indeed, things like this would have come to light sooner if they went through a more normal RFC process.
jsilence 8y ago
Also will it be able to make the link opening party to execute malicious requests? Think 'delegated fuzzing'.
adrianmonk 8y ago
This whole thing is messy and fragile by its very nature. I'd argue that if you have to get as fancy as linking to the second instance of a string, then your odds of the link going to the right place later are not that great anyway. So it might not be worth even trying to solve that problem.
jchw 8y ago
I think this is being over thought a bit. Even in it's most primitive form, it could still be quite useful in practice. It's pretty easy to construct cases where it fails, but all such systems will fail either due to changes in content or changes in structure, and many will fail due to ambiguity as well. It's only really useful to compare how this might fare against other approaches. An example would be producing an XPath expression. Which may be more robust to ambiguity but weaker to structural changes. This system will fail if the content is different enough that the target text is gone, which I believe is very reasonable. And while you could construct ambiguous text that couldn't be disambiguated by picking a larger string, in practice the value added with the complexity of trying to solve that problem is probably not very good. For the purpose of linking to sentences and paragraphs, this system seems sufficient and probably even better than many alternatives. I don't think many articles have a lot of repeating sentences. Other use cases than linking to actual text would probably have their issues. Like, trying to link to a cell of a table would be quite problematic. That case may be better handled with something like an XPath expression, but in any case it's a fairly different use case imo. All in all, my initial opinion is that this design is useful and easy to understand. It gives you the equivalent of Ctrl+F which is not bad. (Disclosure: I work at Google, but this is the first I've heard of this and I don't work on Chrome.)
- beatgammit 8y ago
  Why not just use fragments? It's pretty easy to place a unique fragment at all places you care to link, except perhaps in the very nice case of reimplementing Ctrl+F, which would need JS anyway, so why not just expose an API call, like window.find[1]? I really don't understand what this brings to the table, besides making people upset. [1] https://developer.mozilla.org/en-US/docs/Web/API/Window/find https://developer.mozilla.org/en-US/docs/Web/API/Window/find
  - bokan 8y ago
    That depends on the author annotating their page with ids so it's highly content dependent. In addition, authors can't always predict what will be interesting to users and pages frequently don't have IDs on elements you might want to link to; this is particularly true of long passages of text.
sush99 8y ago
Yeah needs something like occuranceNumber=5 I.e. navigate to the fifth occurance
ollysb 8y ago
Perhaps it could actually prefill the standard find dialogue and scroll to the first match, then you could easily see if there was more matches and jump to them.

pasiaj 8y ago

Doesn’t the spec specify, that the link points to the first instance of the selected text? Does that not accurately define what happens when you try to link to a latter instance: It links to the first one.

Buge 8y ago
This isn't a question about where the browser will scroll. This is a question about what will the browser do if the user tries to create a link to something that can't be scrolled to.
larkeith 8y ago
That's not great from a UX point of view - for most users, their experience with the feature will be trying to use it, selecting a phrase, and having it silently link to an entirely different area.

kumarharsh 8y ago

Although you are right, it's already how browsers work in relation to IDs - only the first element with that ID is selected. (Yes, IDs are supposed to be unique, but it's not like HTML "breaks" if you don't follow this rule). Plus, you can always select more text.

dmortin 8y ago

They could add and index too, but linking to a search phrase is already prone to breakage if the text changes, so there's not much point in complicating it. Usually the same phrase is not repeated in the text if you select more than 1-2 words.

larkeith 8y ago

Perhaps it could automatically expand the selection until it becomes unique, and support an index property for cases in which that would result in an unreasonably large selection (or hits EOF). Using indices alone would also work, but would be exceptionally prone to link rot as text changes, especially in the case of short (e.g. 1-word) selections.

nbevans 8y ago

They could fix this by having a second query string parameter, say, "targetInstance". Which would take the number of the instance. Indeed, things like this would have come to light sooner if they went through a more normal RFC process.

jsilence 8y ago

Also will it be able to make the link opening party to execute malicious requests? Think 'delegated fuzzing'.

adrianmonk 8y ago

This whole thing is messy and fragile by its very nature. I'd argue that if you have to get as fancy as linking to the second instance of a string, then your odds of the link going to the right place later are not that great anyway. So it might not be worth even trying to solve that problem.

jchw 8y ago

I think this is being over thought a bit. Even in it's most primitive form, it could still be quite useful in practice. It's pretty easy to construct cases where it fails, but all such systems will fail either due to changes in content or changes in structure, and many will fail due to ambiguity as well. It's only really useful to compare how this might fare against other approaches. An example would be producing an XPath expression. Which may be more robust to ambiguity but weaker to structural changes. This system will fail if the content is different enough that the target text is gone, which I believe is very reasonable. And while you could construct ambiguous text that couldn't be disambiguated by picking a larger string, in practice the value added with the complexity of trying to solve that problem is probably not very good. For the purpose of linking to sentences and paragraphs, this system seems sufficient and probably even better than many alternatives. I don't think many articles have a lot of repeating sentences. Other use cases than linking to actual text would probably have their issues. Like, trying to link to a cell of a table would be quite problematic. That case may be better handled with something like an XPath expression, but in any case it's a fairly different use case imo. All in all, my initial opinion is that this design is useful and easy to understand. It gives you the equivalent of Ctrl+F which is not bad. (Disclosure: I work at Google, but this is the first I've heard of this and I don't work on Chrome.)

beatgammit 8y ago
Why not just use fragments? It's pretty easy to place a unique fragment at all places you care to link, except perhaps in the very nice case of reimplementing Ctrl+F, which would need JS anyway, so why not just expose an API call, like window.find[1]? I really don't understand what this brings to the table, besides making people upset. [1] https://developer.mozilla.org/en-US/docs/Web/API/Window/find https://developer.mozilla.org/en-US/docs/Web/API/Window/find
- bokan 8y ago
  That depends on the author annotating their page with ids so it's highly content dependent. In addition, authors can't always predict what will be interesting to users and pages frequently don't have IDs on elements you might want to link to; this is particularly true of long passages of text.

sush99 8y ago

Yeah needs something like occuranceNumber=5 I.e. navigate to the fifth occurance

ollysb 8y ago

Perhaps it could actually prefill the standard find dialogue and scroll to the first match, then you could easily see if there was more matches and jump to them.