Earlier quoted context omitted.
The hundreds if not thousands of ad supported calculator and flashlight apps on play store beg to differ.
Reasonable amount of competition is good.
Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
101–110 of 332 posts
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#102Because that is exactly what we have all been clamoring for. Gee thanks Google. Ok, that is more than a bit dismissive and I shouldn't be as cynical as I am about it but I switched to Firefox for a reason, this crap just keeps interfering. But oh wait, want to watch Youtube.tv in Firefox, oh so sorry you can't because it won't do video acceleration. I remember when you had to run Silverlight to watch Netflix too, tha…
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#103Earlier quoted context omitted.
amp is a self serving standard. Nowhere in the standard "higher search ranking on google inc" is mentioned as a must have feature. Yet it is the only feature anyone care about when discussing adoption.
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.
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#104Let me guess, it has nothing to do with https://www.w3.org/community/openannotation/
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#105Earlier quoted context omitted.
That's my point. The web is so complex that browser engines are becoming a monoculture. Even if you forked Chromium now, you'd need hundreds of engineers just to keep up with all the new things that are constantly added.
> new things that are constantly added By golly, that's the problem right there.
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#106Real 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…
They use the same trick for Google Search in a way that is transparent to the user - as long as you have JS turned on. When you switch it off, you realize instead of clicking on HNs URL, you actually click https://www.google.com/url?q=https://news.ycombinator.com/&s...
Now, they want to move a step further. I wonder when they're going to stop.
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#107How come I’m not surprised?
These links should if nothing else be prefixed chrome:// to be explicit about it not being real web-links.
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#108Something open, standardized, quite similar and already working is Web annotations. This includes 'robust anchoring' capability which could surely be used to solve this problem. https://www.w3.org/community/openannotation/ Hypothes.is is a well established open implementation.
This looks similar to Genius.com's annotations. I wonder how this will evolve with multiple providers allowing similar functionality. Ideally you'd be able to combine annotation networks for a single URI to get all possible annotations you want on a given page.
Problems with these types of systems are the same as product reviews like on Amazon. Astroturfing & false information. It'll be interesting to see how that evolves.
Re: Chrome will Soon Let You Share Links to a Specific Word or Sentence on a Page
#109In the blog post, there doesn't seem to be anything addressing this (or even just specifying how Chrome would combine the "targetText" fragment with an already existing fragment part)
Did they spend any thought on this?
Edit: Oh, right, the readme answers this:
> Web pages could potentially be using the fragment to store parameters, e.g. http://example.com/#name=test. If sites are already using targetText in the URL fragment for their own purposes, this feature could break those sites.
> We expect this usage to be exceedingly rare. It's an abuse of the purpose of URL fragments and page arguments are typically encoded using the '?' character (e.g. http://example.com?name=test). Still, we may run an experiment to see if targetText is available enough to use as a reserved token.
We'll just completely change the commonly understand processing model of fragment identifiers, but it'll be fine since we don't think anyone is using them anyway...
No further questions...