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

151–160 of 332 posts

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

#151

Post by jypepin »

lucideer wrote: post #133
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…

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

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

#152

Post by ru999gol »

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…

I'm so glad that google just sometimes ignores W3C's horrible design-by-committe nonsense. Its the same reason XHTML failed.

    #selector(type=TextQuoteSelector,exact=foo)
vs.

    #targetText=foo
/edited to be a more fair comparison

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

#153

Post by askmike »

chillydawg wrote: post #147
martin_a wrote: post #141

Earlier quoted context omitted.

What are you missing? I was feared of this too, but they seem to be just fine.

Can't inspect websocket frames. It's ridiculous.

While I run into this too from time to time, it's not something everyone uses. Also it takes me 5 seconds to workaround by debug logging incoming ws messages. Most web devs I talk to can do everything with FF devtools more than fine.

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

#154

Post by jhasse »

VadimPR wrote: post #145
jhasse wrote: post #142

Earlier quoted context omitted.

No hardware video decoding on Linux ...

Indeed - but it's hardly an issue in practice.

Well, watching videos is one of the things I do most with my browser. So this is a no-go for me, as the fans of my laptop will start spinning with Firefox (and battery life is worse).

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

#155

Post by airza »

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…

Good lord, I see pages that would break from this constantly...

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

#156

Post by BorRagnarok »

fareesh wrote: post #137
Slartie wrote: post #126

Earlier quoted context omitted.

Did exactly this, a few weeks ago. Was heavy Chrome user, now fully on Firefox (and Safari on mobile). I am so satisfied with this decision, and the transition was much easier than expected.

I would do it instantly if the devtools were half as convenient as Chrome. Unfortunately they are super clunky

I use both, Chrome for client side dev, Firefox for everything else. Chrome is just the dev tool. Works like a charm because switching between tabs inside a browser is just as quick as alt-tabbing between browsers.

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

#157

Post by pfortuny »

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…

We shall stop using the turning lights (blinkers)... It is an abuse but anyway, novody uses them.

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

#158

Post by chrismorgan »

sascha_sl wrote: post #122
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…

Hmm, who provided the first popular JS framework that used fragments for navigation again? I think it was called "Angular".

Gmail was probably the first very-widely-used app that used the fragment for navigation, and Google drove the whole #! thing.

That technique is now considered obsolete, with the History API (history.pushState and all that lot) having supplanted it. IE9 is the most popular browser currently in use that doesn’t support it; there are still definitely some systems out there that will use the History API if it’s available, or fall back to using the hash if it’s not, but I find that using the hash for navigation in deployed apps is surprisingly dead, given that it’s shy of six and a half years since IE10 came out, and Firefox and Chrome only had a year and two’s lead (and Chrome’s implementation especially was unreliable for quite some time).

Using the hash for navigation is still very common in development workflows. But that can be ignored for a feature like this.

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

#159

Post by raimue »

ru999gol wrote: post #152
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…

I'm so glad that google just sometimes ignores W3C's horrible design-by-committe nonsense. Its the same reason XHTML failed. #selector(type=TextQuoteSelector,exact=foo) vs. #targetText=foo /edited to be a more fair comparison

The W3C design seems to be extensible for future use cases with a consistent syntax while keeping everything under one keyword. Something like this could also be applied to other types of documents, not only to text. Let's say to quickly draw a highlight on an image or specify a page in a PDF document. While "#targetText=" is simple, it is not a generic solution.

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

#160

Post by csarven »

ru999gol wrote: post #152
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…

I'm so glad that google just sometimes ignores W3C's horrible design-by-committe nonsense. Its the same reason XHTML failed. #selector(type=TextQuoteSelector,exact=foo) vs. #targetText=foo /edited to be a more fair comparison

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#selector(type=TextQuoteSelecto...

but that selects all instances of the text "annotation" in the document. Which is precisely why we need `prefix` and `suffix` to be able to identify the actual selection that the user made.

So, here is the equivalent of your example:

http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...

I hope that clarifies.

This is just tip of the iceberg! Let's stick to fair comparison and consider extensibility.

Post reply on HN