Live data from Hacker News

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

chromestory.com

311–320 of 332 posts

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

#311
post #43
post #9

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.

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…

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

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

#312
post #302
post #296

Earlier quoted context omitted.

This is not rare at all, I use it almost every time I link to a wikipedia article, for example: https://en.wikipedia.org/wiki/Newton%27s_method#Examples That said, it seems easy to make this backwards compatible: if the existing #blah syntax is a valid link, that should take precedence. FWIW, I think there's way too much cynicism in this thread. My first reaction on seeing the title was "cool! I would use that!". edi…

> That said, it seems easy to make this backwards compatible: if the existing #blah syntax is a valid link, that should take precedence. That's indeed how it works. The majority of the compatibility concerns appear to be with apps that a using _custom_ parsing of the fragment to perform app-specific logic, which is a valid concern.

Angular 1 does this.

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

#313
post #296
post #267

Earlier quoted context omitted.

Feature author here. I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a dra…

This is not rare at all, I use it almost every time I link to a wikipedia article, for example: https://en.wikipedia.org/wiki/Newton%27s_method#Examples That said, it seems easy to make this backwards compatible: if the existing #blah syntax is a valid link, that should take precedence. FWIW, I think there's way too much cynicism in this thread. My first reaction on seeing the title was "cool! I would use that!". edi…

The parent comment's example includes a trailing equals sign on the fragment that could be used to differentiate (#targetText= vs #targetText).

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

#314

Earlier quoted context omitted.

Such fragments don’t need to be particularly human-readable, only machine-readable. Given that, greater flexibility is generally a virtue: different matching strategies will work better in different contexts, and different tools can benefit from it. Consider the increased scope of the annotations feature—it’s designed for things like more robust referencing, bookmarking with annotations and other things like that. Th…

it adds a huge amount of unnecessary complexity for such a simple feature There is a reason nobody implemented the W3C proposal, If I have the choice between a simple working solution that anyone can describe in a single sentence specification and a hundred page specification with tons of unneeded features that nobody is going to implement ever, I choose the former. I wonder how much hate Mozilla would've gotten for…

But various tools have implemented the W3C proposal; just not browsers yet, probably mostly because getting the UI right is tricky, and the risk of breaking things higher. The problem is not in the particular syntax, but the feature as a whole.

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

#315
post #276

Earlier quoted context omitted.

Why is this not being pushed to become part of the web spec first? That seems more reasonable than pushing a feature with the possibility of breaking pages that are spec compliant.

It will. The specification process needs to be informed by implementation and experimentation. When implementing a feature we'll learn all sorts of things and hit bumps that will help guide the design. Once we have a working implementation, it helps to be able to use it to answer things like: - How does this perform on existing pages - How does this feel from a user perspective - How can I write pages that user this…

> Edit: To clarify, "implementation" does not necessarily mean shipped to users.

Literally just today we got an article about Web Bluetooth on the front page of HN, a user-shipped capability in Chrome that is still in the Draft phase of standardization.[0]

Beyond that, we have the Web USB API, which is also in the draft phase, but is of course shipping to users in Chrome, on by default.[1]

Beyond that, we have HTML imports, which have been rejected from the standard but are still shipping to users in Chrome.[2]

I don't doubt your intentions, but if you think that Chrome is going to wait for standardization on this before it ships, you are not paying enough attention to the teams you're working with. And once Chrome ships a feature to users, the web standards body has basically two options: accept Google's vision of the standard wholesale, or change the standard and break websites that are already using Google's implementation.

I would be more confident and trusting of the process you describe if there was some kind of official commitment from the Chrome team that this feature will stay behind a browser flag until the standardization process is completely finished. But I think some of the reason you're getting immediate pushback to an extremely early draft of the spec is because developers don't trust Google not to ship this on-by-default once it reaches a WD stage.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...

[1]: https://developer.mozilla.org/en-US/docs/Web/API/USB

[2]: https://developer.mozilla.org/en-US/docs/Web/Web_Components/...

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

#316
post #53

Earlier quoted context omitted.

I use Chrome for a few spare things (like Youtube and full-screen gslides) but for all else FF or Safari (both with ublock+umatrix) are much better. FF handles XML rendering way way faster than Chrome - great for my job.

How do you run umatrix with Safari? I’ve thought it’s not available.

I got that part wrong - sorry to tease. No uMatrix in my Safari. Just content blocker + ublock-origin.

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

#317
post #267
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…

Feature author here. I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a dra…

Everything after # in the URL is not sent to server, which makes it handy for storing tokens.

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

#318
post #296
post #267

Earlier quoted context omitted.

Feature author here. I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a dra…

This is not rare at all, I use it almost every time I link to a wikipedia article, for example: https://en.wikipedia.org/wiki/Newton%27s_method#Examples That said, it seems easy to make this backwards compatible: if the existing #blah syntax is a valid link, that should take precedence. FWIW, I think there's way too much cynicism in this thread. My first reaction on seeing the title was "cool! I would use that!". edi…

FYI, there's even a Chrome extension that makes this easier:

https://chrome.google.com/webstore/detail/display-anchors/po...

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

#319
post #267
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…

Feature author here. I'd like to first clarify that this is still in the super-early stage of development; none of this is shipped or finalized yet. The feature hasn't even requested approval to ship at which point these kinds of issues would be brought up. We take web-compat very seriously. If this breaks even a small percentage of pages, it won't ship. Part of the shipping process is ensuring we have at least a dra…

I’m not sure what internal resource exist or what access is available to your team, but I would think that Google’s search indices would be the best resources on the planet for analyzing existing URL fragment design patterns. It seems like you could classify various implementations and run tests against each of the major groupings so that you can be confident that xxx.xxx% of sites that currently use fragments will be supported by this design.

It’s an exciting possibility to link more directly to resources. I hope it is implemented in such a way that all browsers can follow those links with parity in the future. If that is the case I have a few hundred thousand outlinks that could be refined for clarity.

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

#320

Earlier quoted context omitted.

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.

This is a good point, which I didn't get until your comment. I think they should surface this on that page, because it seems everyone is thinking this will be a big clash, but as you say, if someone shares a sentence, the likelihood is low. To double check, does this means things like, https://www.spa/#!/path/to/view Can become https://www.spa/#!/path/to/view&targetText=percent%20encoded The only part I don't get abo…

You could use two hashes like that and stick with http. I reckon browsers would cope, and you could strip the second one.
Post reply on HN