Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

chromestory.com

Post reply on HN
Print view View original

301–310 of 332 posts

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

#301

Post by bokan »

casual_slacker wrote: post #300
bokan wrote: 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…

It could also break pages that rely on full control over the hash, having targetText= injected unexpectedly would break a lot of crude params parsers.

That's true, but presumably these pages would have the same problem with existing id-fragments, no?

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

#302

Post by bokan »

creato wrote: post #296
bokan wrote: 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…

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

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

#303

Post by SquareWheel »

mstade wrote: post #293
SquareWheel wrote: post #290

Earlier quoted context omitted.

Thanks for being respectful and well-reasoned in your response. My opinion is that the collaboration is probably the best it's ever been right now. The example I gave lower down in this thread is that when WebAssembly was introduced, the Chrome team decided to deprecate their own solution, PNaCl. We're far from the days of ActiveX. https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...

> Thanks for being respectful and well-reasoned in your response. Likewise! WebAssembly is a very good counter example, but still my feeling – or fear, really – is that this is not in spite of Google's hegemony but because of it. Let's say they hadn't gotten on board with WebAssembly and instead doubled down on PNaCL or come up with a different competing proposal. Even if all other parties rallied around WebAssembly…

Cheers! It's a difficult thing to quantify anyway, so agreeing to disagree sounds good to me. Do enjoy your weekend!

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

#304

Post by breck »

bokan wrote: post #267
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…

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…

At Microsoft, I worked on a popular Web app that for various reasons had to resort to using the # to enable deep linking. If you put anything in the hash it will break things. We assumed an empty hash unless it was something we set.

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

#305

Post by kreetx »

Sujan wrote: post #279
kreetx wrote: post #173

Earlier quoted context omitted.

Are there any guidelines for chromium development? It seems like one can just commit a feature to it and make half the world use it. Regarding URL hash abuse elsewhere: this current development in Chromium is different from front-end frameworks and specific websites doing it because SomeSite can't break OtherSite while both having a different way to handle the hash. Now Chromium randomly claims part of the hash which…

Explanation: > ... and make half the world use it. vs. > Add about:flag for Scroll-To-Text > Adding chrome://flag to allow users (particularly on Mobile) to easily enable and test the feature. (Commit message via https://chromium-review.googlesource.com/c/chromium/src/+/14... ) So nobody will use the feature unless they explicitly choose to.

Sure, but that won't stay to be the case since otherwise no needle-moving group would start to use it, so what would step 2 be?

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

#306

Post by roywiggins »

blattimwind wrote: post #299
roywiggins wrote: post #271

Earlier quoted context omitted.

It doesn't have to, if you also provide routes on the backend so that pushState URLs actually resolve to a real URL that serves the same content. Or just provide a wildcard route and use JS to detect the URL like you would with hash-based navigation. It does require more coordination between the front and back-end though.

I meant using pushState using the state object for something other than caching. If I click on "About us" and this results in pushState({page:"about-us"}, "", "#") then linking just doesn't work any more. It's a regression back to the days of Flash.

Ah, gotcha. Yes, that's a truly awful way to use it.

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

#307

Post by Izkata »

nerdponx wrote: post #89
gcb0 wrote: post #80

Real use case for this is so Google can poke into context for links shared via services they have no ownership. They got used to know exactly what people share and, much more importantly, what people click on email, thanks to gmail rewriting all links to a google track url (while misleading the user by a fake status text on mouse over). When they sum the info of 1. who send it, 2. who clicked on it, 3. what was the e…

It's a shame because it is actually a good idea, but now Google has first-mover advantage, so any other implementations will just be a clone of what Google already did.

http://archive.is/ got there first, sort of. If you archive a page then highlight some text, the URL changes to a direct shareable link to that text.

Bonus: being its own site, and implemented in javascript, it's already cross-browser.

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

#308

Post by kreetx »

bokan wrote: post #294
kreetx wrote: post #173

Earlier quoted context omitted.

Are there any guidelines for chromium development? It seems like one can just commit a feature to it and make half the world use it. Regarding URL hash abuse elsewhere: this current development in Chromium is different from front-end frameworks and specific websites doing it because SomeSite can't break OtherSite while both having a different way to handle the hash. Now Chromium randomly claims part of the hash which…

> Are there any guidelines for chromium development? Absolutely! Launching a change to the web platform is a long, arduous process. This feature is currently taking the very early first steps. For more details, see https://www.chromium.org/blink/launching-features .

Thank you for the link and I may have come off a bit harsh with that last sentence.

Having some feature like this for the web would in itself be good, just claiming a key in the hash part just for this would (and I know that hash doesn't really have a format so "it's not a key" etc, but it does gets used that way).

A proposition: instead of using plain 'targetText' how about having some prefix for all Chromium's claims in the hash part so that the front-end (framework) developers can filter these out without needing to keep a list?

Good luck!

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

#309

Post by xg15 »

bokan wrote: post #267
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…

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…

Thank you very much for replying on this thread. It's absolutely a very useful feature and - when done in a standardized and privacy conscious way, I think it would absolutely be an enrichment for the web platform. (Can we extend the same for images, too, btw?)

I think the reason this sparked concern is because (by using fragments) this intrudes into a field that was previously under full author control.

I think clear guarantees about which aspects of a webpage are the responsibility of authors and which are under browser control are important - only going by real-world usage and assuming everything not directly used is free for the taking is not enough here.

E.g., I think there are failure modes for SPAs that are not easily found with a usage search. [1] Additionally, this would make it harder to know for new applications which kinds of fragment identifier are "safe" to use and which are not.

There seem to be some existing specs that deal with the same problem [2].

Maybe those could be a starting point for the feature to to forward without interop/responsibility problems?

[1] https://news.ycombinator.com/item?id=19170230

[2] https://news.ycombinator.com/item?id=19169582

Post reply on HN