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

201–210 of 332 posts

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

#201

Post by bryanrasmussen »

prepend wrote: post #195
rolae wrote: post #184

Earlier quoted context omitted.

I think he means it the other way around. You have a Single page application with routing based on #someRoute, then someone tries to share some link with the #targetText=... which will lead to an invalid route. Or am I missunderstanding something?

You’re thinking of ?targetText= or &targetText= Hash isn’t used for query parameters.

lots of older or poorly written SPAs use the hash exactly in this way. I guess their fault for being poorly written, like those people who allowed GET requests to /deleteaccount based on the theory that you had to be logged in with a browser for it to ever happen and not considering that google would make an extension that did all get requests on a page on entry.

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

#203

Post by coldtea »

jypepin wrote: post #151
lucideer wrote: post #133

Earlier quoted context omitted.

> It's an abuse of the purpose of URL fragments So what they're saying is, they expect a clash of their abuse of URL fragments with others' abuse of URL fragmentsto be rare because... The arrogance here is astounding: "It's OK for us to use this, because others shouldn't be using it"

Aren't url fragment originally used for page position already? Like url.com/#title would scroll to the page the div with id "title"? In that case I don't feel like using url fragment for a word position is so much breaking it, it keeps the use of url fragment for info about page position, right?

>Aren't url fragment originally used for page position already? Like url.com/#title would scroll to the page the div with id "title"?

That was the pre-SPA, traditional role of anchors...

If you did any html between 1995-6 and 2005, you'd use it for that.

Then, with AJAX/SPAs, # was used for state (pre-history API) -- and I'd assume many webpages are still left at that use.

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

#204

Post by Shish2k »

prepend wrote: post #195
rolae wrote: post #184

Earlier quoted context omitted.

I think he means it the other way around. You have a Single page application with routing based on #someRoute, then someone tries to share some link with the #targetText=... which will lead to an invalid route. Or am I missunderstanding something?

You’re thinking of ?targetText= or &targetText= Hash isn’t used for query parameters.

It is in client-side JS single-page-apps...

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

#205

Post by coldtea »

prepend wrote: post #195
rolae wrote: post #184

Earlier quoted context omitted.

I think he means it the other way around. You have a Single page application with routing based on #someRoute, then someone tries to share some link with the #targetText=... which will lead to an invalid route. Or am I missunderstanding something?

You’re thinking of ?targetText= or &targetText= Hash isn’t used for query parameters.

It was used in SPAs. It was a common technique in the mid-2000s up to 2010 or so.

But not for query parameters per se, for app state stored in the query string (and bookmarkable).

https://stackoverflow.com/questions/15238391/hash-params-vs-...

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

#206

Post by contravariant »

crehn wrote: post #190
csarven wrote: post #160

Earlier quoted context omitted.

I urge you to dig a little deeper and see why things like `prefix`, `exact`, `suffix` exists in that particular example: https://www.w3.org/TR/selectors-states/#TextQuoteSelector_de... Please note that you've actually changed the example! If you just want to include `exact` or "targetText", you can still do: http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto... or equivalent: http://csarven.ca/dokieli-rww#s…

Even with that in mind, the W3C spec adds unnecessarily verbose syntax fluff.

It's not like (un)necessarily verbose syntax is that uncommon in URLs. Or rather that's exactly where you'd expect an excrutiatingly verbose description of what you're linking to.

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

#207

Post by coldtea »

bryanrasmussen wrote: post #201
prepend wrote: post #195

Earlier quoted context omitted.

You’re thinking of ?targetText= or &targetText= Hash isn’t used for query parameters.

lots of older or poorly written SPAs use the hash exactly in this way. I guess their fault for being poorly written, like those people who allowed GET requests to /deleteaccount based on the theory that you had to be logged in with a browser for it to ever happen and not considering that google would make an extension that did all get requests on a page on entry.

They didn't use it because they were "poorly written", it was a "state of the art" technique back in the day.

Gmail used, others used it.

https://stackoverflow.com/questions/15238391/hash-params-vs-...

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

#208

Post by csarven »

crehn wrote: post #190
csarven wrote: post #160

Earlier quoted context omitted.

I urge you to dig a little deeper and see why things like `prefix`, `exact`, `suffix` exists in that particular example: https://www.w3.org/TR/selectors-states/#TextQuoteSelector_de... Please note that you've actually changed the example! If you just want to include `exact` or "targetText", you can still do: http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto... or equivalent: http://csarven.ca/dokieli-rww#s…

Even with that in mind, the W3C spec adds unnecessarily verbose syntax fluff.

We can only compare what's on the table, ie. arbitrary text selection. The targetText proposal doesn't necessarily result in a unique identifier that deterministically corresponds to user's original selection. So, I'm not sure if there is any point in discussing the syntactical differences on specificity further at this point. Having said that, at the end of the day, it is going to be the application that generates and uses the identifier.

Please have a closer into why we should be mindful of different use cases here, especially those pertaining to different resource representations, ways to "select", and factor in the state of the resource/representation at the time of the selection. It is there for use. It doesn't mean that all possible options needs to make its way into the identifier. This is important because people are going to use these identifiers in documents, and preserving context matters. Like I said earlier, the W3C Note has considered these, as well as permitting the use of different (RFC) selectors for different media. Let's reuse instead of NIH-FUD.

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

#209

Post by dspillett »

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…

While it does smack a little of the arrogance of a big player, they are using the fragment part for more-or-less what it used to be used for (navigating to a specific location on a page), and if you use something in a way it isn't intended (using a navigation aid for state management) perhaps you should expect certain things to break at some point when combined with other hacks of the same feature.

It is important to note that this won't break your site/app in the normal use case. People using your work will continue to do so uninhibited unless/until they wish to use this new feature in Chrome.

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

#210

Post by SquareWheel »

gcb0 wrote: post #194
SquareWheel wrote: post #74

Earlier quoted context omitted.

If that were true (and I'm not so sure it is), then you'd blame the search team for letting it be a ranking factor. It has nothing to do with web standards.

You are not wrong (about what is on the standards). But you are being downvoted because everyone who did implement AMP in the real world, did so for the SEO benefits.

Oh I have votes disabled on social media. I'd rather form my own opinion when reading comments.

Regarding AMP, I appraised it from a speed perspective and found it partially effective, but only a bandaid fix. Addressing real site speed issues is the better approach.

Post reply on HN