3. Privacy. It makes sense to hide the text query string from even the destination page. Without the :~: syntax and fragment stripping, the page would be able infer sensitive information e.g. a user's search terms.
-
-
Replying to @david_bokan @bz_moz and
Oh, and on point #2: we started with a simple syntax-less string similar to fragmentation but got feedback from the WebAnnotations community that they'd been down that road and it was too ambiguous. We tried to match WA's https://www.w3.org/TR/annotation-model/#text-quote-selector … where we could.
2 replies 0 retweets 2 likes -
Replying to @david_bokan @bz_moz and
4. Fragmentation isn't well suited for dis-contiguous passages. E.g. Selecting two paragraphs separated by an image.
1 reply 0 retweets 1 like -
Replying to @david_bokan @BrendanEich and
Is the goal here "selecting" or "pointing at"? A lot of the proposal seems to focus on the "selecting" aspect; when I described it to someone their reaction was "this is just sticking the entire browser find functionality in the URL"...
1 reply 0 retweets 0 likes -
Replying to @really_bz @bz_moz and
Sorry, I'm being loose with terminology. It's "pointing at"; we specifically avoid creating selections for security. find-in-page via url is apt, though with more disambiguating power. We've thought about integrating it with the FIP UI but haven't yet (more of a UI issue though)
2 replies 0 retweets 0 likes -
Replying to @david_bokan @BrendanEich and
Again, the use cases I am aware of are more like "link to a thing that doesn't have an anchor provided", not "highlight all the instances of a thing". If there are use cases motivating this, I'd really like to understand what they are.
1 reply 0 retweets 2 likes -
Replying to @really_bz @david_bokan and
Or put another way, _why_ are we building find-in-page-via-URL if the problems we want to solve "just" need "indicate a spot on the page via URL"?
1 reply 1 retweet 4 likes -
Replying to @really_bz @bz_moz and
Ah, I think the misunderstanding is "match". In :~:text=foo&text=bar, we call both "foo" and "bar" the "match term". Both "foo" and "bar" be indicated but only the first occurrence of each (it differs from FIP in this way). Is there a section I could clear up?
2 replies 0 retweets 1 like -
Replying to @david_bokan @BrendanEich and
I don't think there's any misunderstanding going on. It's just not clear to me why we need to support multiple match terms for the use cases this is trying to address.
1 reply 0 retweets 0 likes -
Replying to @really_bz @bz_moz and
You said "highlight all instances of a thing" which is not the case, we highlight only the the first instance. Multiple terms allows highlights where a single range-based term would highlight unwanted content (e.g. ad between two paragraphs) because of how the DOM is arranged.
2 replies 0 retweets 0 likes
Who is generating these URLs? Users can't create a selection of the sort you describe, due to limitations in most browsers' selection code...
-
-
Replying to @really_bz @bz_moz and
Yes, this would be less useful for users (though they could still hand-craft them or create tools to make them). One major use case is search engines in which the URLs are generated by automated tools from the source HTML.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.