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

291–300 of 332 posts

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

#291

Post by codezero »

bokan wrote: post #286
codezero wrote: post #282

Earlier quoted context omitted.

Would you append the & to the fragment, or to the query? If to the fragment couldn’t that affect routing for SPAs? To be clear, I agree that this format is exceedingly unlikely to collide with real fragments, but still seems like there is a safer approach.

> Would you append the & to the fragment, or to the query? If to the fragment couldn’t that affect routing for SPAs? To the fragment. Tt could, depending on how the app was written. Is there a framework or some common techniques that use this I could read-up on?

There was a time several spa frameworks used explicit hash routing rather than url-like push state but I don’t have sources handy. I thought angular was one of them but they may have done away with this behavior.

I work in analytics so I’ve seen things like UTM params get couched into the hash, breaking parsing, so at least it’s something to keep an eye out for.

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

#292

Post by aesthetics1 »

Interesting. I think this is useful if implemented correctly.

I had an idea similar to this a few years ago. Basically, you would be able to bookmark your place on the page and come back to it later or send the link to someone else. I didn't think that using a word or phrase was useful because it could show up multiple times on the page. Instead, I used the scroll distance. Here's a crude demo:

http://jboyer87.github.io/page-progress/

Of course, this isn't device-independent. I never went much further with it.

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

#293

Post by mstade »

SquareWheel wrote: post #290
mstade wrote: post #287

Earlier quoted context omitted.

Well that's the argument, isn't it? Collaboration doesn't mean necessarily mean being in sync or following suit. When there's a hegemony then a level of collaboration might still exist, but if the interests don't align with the dominant party they can just go ahead anyway and more or less force others to fall in line – e.g. EME. Even if everyone syncs up, it's not necessarily good collaboration. Conversely, the domin…

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 there's a very good chance the dominance of Google would make it stillborn. If it's not in Chrome, it's simply not worth bothering, purely due to its dominance.

I recognize though that this is a bit of a straw man argument, and one based more in my opionins and feelings in the matter rather than anything resembling objective truths. I suppose that's also why we'll have to agree to disagree. :o)

> We're far from the days of ActiveX.

Thankfully!

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

#294

Post by bokan »

kreetx wrote: post #173
csarven wrote: post #140

I would like to urge the browser developers/makers to adopt existing proposals which came through open consensus which do precisely cover the same use cases (and more!) W3C Reference Note on Selectors and States: https://www.w3.org/TR/selectors-states/ It is part of the suite of specs that came through the W3C Web Annotation Working Group: https://www.w3.org/annotation/ More examples in W3C Note Embedding Web Annotat…

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.

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

#295

Post by bokan »

codezero wrote: post #291
bokan wrote: post #286

Earlier quoted context omitted.

> Would you append the & to the fragment, or to the query? If to the fragment couldn’t that affect routing for SPAs? To the fragment. Tt could, depending on how the app was written. Is there a framework or some common techniques that use this I could read-up on?

There was a time several spa frameworks used explicit hash routing rather than url-like push state but I don’t have sources handy. I thought angular was one of them but they may have done away with this behavior. I work in analytics so I’ve seen things like UTM params get couched into the hash, breaking parsing, so at least it’s something to keep an eye out for.

Thanks, I'll make sure to dig into that some more!

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

#296

Post by creato »

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…

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

edit: Hmm, I may have misunderstood the compatibility issue.

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

#297

Post by ben174 »

gioele wrote: post #230

Why aren't XPointer/XPath fragments used instead of yet another half-backed reimplementation of the same concept? XPointer and XPath have been ratified by the W3C in (...checks...) 2003. They have since been revised, slimmed down and used in countless XML-based applications and specs. The cool thing about XPointer is that it is basically impossible that its fragments are already used in the target document. No site w…

I suppose it could be argued that the DOM might change on a page, but the text content is less likely to. We want deep links to the text content, not the DOM element.

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

#298

Post by fixermark »

ecshafer wrote: post #272
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…

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.

Historically, web specs often start more descriptive than proscriptive. Building a spec without a reference implementation is a great way to build an unimplementable spec.

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

#299

Post by blattimwind »

roywiggins wrote: post #271
blattimwind wrote: post #255

Earlier quoted context omitted.

pushState is bad for many use cases because it completely breaks linking.

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.

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

#300

Post by casual_slacker »

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…

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.
Post reply on HN