Thanks! So next q is non-chromium/Blink browser response. Cc'ing @othermaciej @bz_moz
-
-
Replying to @BrendanEich @tomayac and
Official Mozilla response to this will be at https://github.com/mozilla/standards-positions/issues/194 … -- we are still trying to sort out why exactly Google decided to not go with the existing fragmentions work and instead went off to create its own thing, and what that means in terms of what we should do.
2 replies 0 retweets 8 likes -
Replying to @really_bz @bz_moz and
assuming you mean: https://indieweb.org/fragmention , the main points: 1. fragmentation doesn't work where the page uses frag-based routing. Users might want to link to such pages and we can't tell a priori if it will work or not. It'd be confusing why some pages don't work.
2 replies 0 retweets 2 likes -
Replying to @david_bokan @bz_moz and
2. We did lots of trials with Google Search and found simple text strings to be ambiguous in too many cases. I'll see if I can post some of our findings publicly.
2 replies 0 retweets 3 likes -
Replying to @david_bokan @bz_moz and
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.
2 replies 0 retweets 3 likes -
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
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"?
-
-
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 @bz_moz and
Would you highlight both but only scroll to the first in this case?
1 reply 0 retweets 0 likes - 7 more replies
New conversation -
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.