251–260 of 332 posts
Earlier quoted context omitted.
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-...
sure, it was state of the art back in the day, but state of the art over time depreciates to technical debt, and the ones that are left using what was once state of the art are now poorly written.
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…
https://chrome.google.com/webstore/detail/target-search/nohm...
Earlier quoted context omitted.
I agree with you on Google's monopoly but imagine if every browser has to go through proposal process to release any feature? Everything will just stagnate. Browsers copy features from each other. If this is a useful feature, it would make its way to other browsers pretty soon.
> Everything will just stagnate. And that is bad exactly why?
Earlier quoted context omitted.
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…
So Chrome users will unknowingly be offered to create links which won’t work in other browsers? How come I’m not surprised? These links should if nothing else be prefixed chrome:// to be explicit about it not being real web-links.
Earlier quoted context omitted.
Yes but this is about namespacing/syntax and likelihood of clashes. Normally, url fragments were intended to be used by page authors , making clashes impossible (page author controls both page and anchor syntax). Google are breaking this contract, but argue that the fact that they're using parameter-style syntax should not clash with author usage, because using parameter-style syntax is "an abuse" of the feature.
This is a good point, which I didn't get until your comment. I think they should surface this on that page, because it seems everyone is thinking this will be a big clash, but as you say, if someone shares a sentence, the likelihood is low. To double check, does this means things like, https://www.spa/#!/path/to/view Can become https://www.spa/#!/path/to/view&targetText=percent%20encoded The only part I don't get abo…
Earlier quoted context omitted.
Yes but this is about namespacing/syntax and likelihood of clashes. Normally, url fragments were intended to be used by page authors , making clashes impossible (page author controls both page and anchor syntax). Google are breaking this contract, but argue that the fact that they're using parameter-style syntax should not clash with author usage, because using parameter-style syntax is "an abuse" of the feature.
This is a good point, which I didn't get until your comment. I think they should surface this on that page, because it seems everyone is thinking this will be a big clash, but as you say, if someone shares a sentence, the likelihood is low. To double check, does this means things like, https://www.spa/#!/path/to/view Can become https://www.spa/#!/path/to/view&targetText=percent%20encoded The only part I don't get abo…
Page authors are unlikely to use web+text: if it means cutting off old browsers from access.
Earlier quoted context omitted.
I think this is being over thought a bit. Even in it's most primitive form, it could still be quite useful in practice. It's pretty easy to construct cases where it fails, but all such systems will fail either due to changes in content or changes in structure, and many will fail due to ambiguity as well. It's only really useful to compare how this might fare against other approaches. An example would be producing an…
Why not just use fragments? It's pretty easy to place a unique fragment at all places you care to link, except perhaps in the very nice case of reimplementing Ctrl+F, which would need JS anyway, so why not just expose an API call, like window.find[1]? I really don't understand what this brings to the table, besides making people upset. [1] https://developer.mozilla.org/en-US/docs/Web/API/Window/find
At first glance, this seems like a really half baked idea to me. Some immediate thoughts: - Wasn't there a draft spec floating around in the early 00s that tried to accomplish this, but didn't catch on? - Fragments are already used to link to fragments, albeit more author friendly than user friendly I suppose - This won't fly very well with sites that still make use of fragment based navigation, will it? (Believe it…
Honest question: is there a specific person who is smugly grinning about this at google. Like the people at FB who run around thinking how awesome they are for coming up with a new spying technique and what idiots the world is for not recognizing their innovation?
I sort-of understand where you're coming from, but isn't this needlessly hostile? Unlike in the case of "spying innovation" you brought up, Chrome's "Scroll to Text" seems to be intended with the user's benefit in mind (and only indirectly Google's — via greater user satisfaction, but that's exactly the product design model we want).
It would have obviously been far preferable if this had gone through the "proper channels" (discussion at the W3C, standardisation etc. first), but I don't think that there's any evidence to believe that anybody at Google thinks that they're the first to come up with this.