Hacker News Reader

Comment by abalone | Hacker News Reader

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.

View on HN

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.)

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

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.

Simple, it doesn't depend on requiring the content to have lots of identifiers. While you may convince some web developers to just add more identifiers, you can't convince everyone. And for largely unstructured plain text like mailing list archives, there's not really a logical way to do that anyways.

Re: making people upset. I mean, nearly anything will upset people. One way a search engine could incentivize people to add more usable fragment identifiers is by ranking pages with them higher, but I am certain many wouldn't be thrilled by that.

If this is implemented I don't think it will actually raise serious compatibility issues, and it's not a huge deal to remove it later, it should degrade softly.

> I don't think many articles have a lot of repeating sentences.

This misrepresents the comment you're replying to. The case I gave was "linking to a single word." Articles have a lot of repeating words.

I can see users highlighting and linking to a key word or two in the section they want to link to. This is going to result in a broken link if it's not unique. This is not an edge case. It's not even mentioned as a potential issue in the spec.

Should the browser at least warn that this is going to result in a broken link as the doc currently stands? Should it disable the feature until sufficiently unique text has been selected? Should it just silently let you copy a broken link and chalk it up to PEBKAC (which is what the spec seems to imply)?

Needs more thought IMHO.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

Reply on news.ycombinator.com