I'm normally not a fan of Chrome unilaterally adding something to the platform, but this has been a long time coming.
[1] https://github.com/mozilla/standards-positions/issues/194#is...
[2] https://github.com/mozilla/standards-positions/issues/194#is...
If it was simply a matter of being used in the way outlined in the article, when someone creates a a link that references a particular piece of text, then fine, someone has deliberated intended the link to behave like that.
And then we have the lovely folk at Google search... who think it's fun to drag my attention off to a random part of a page that isn't where I want to be, forcing me to right-click, remove annotation and scroll back up to the top of the page.
That doesn't seem like a massive hardship, but it gets quite frustrating when multiplied over the many searches done in a day/week/month.
/path/to/file:/from.*to
It pains me to see the web having strayed so far from its focus on interlinking. It's easy to make a parallel when on one side device makers have taken control back by removing access to files and putting applications first (this is the only model on mobile), to the point that those makers have enormous control over apps' existence, and the web where applications are now the only way to access content, to the point that content may or may not available if the right API exists.
See also hyperbole for emacs.
Document-Policy: force-load-at-topI see that there is a method and an object to see if its enabled or not. And there is a way to get the whole fragment which can be parsed.
Are there methods to see whether some text in the fragment was actually highlighted or not? Are there methods to programmatically select text?
Could there be a way to, for example, draw a rectangle around the highlighted section, to get the coordinates of the text, to read out the selected text, to store what words people select and link to etc
Maybe it's an external link about headline news and the news title got changed by the editor. Maybe the developer may want to change the selection to the edited title so the user isn't surprised. Maybe its a multi lingual blog post and the user links using another language... etc etc
I think though that this is a pretty niche feature though, so it's unlikely to be a big source of data. In my experience, the median sophistication web user has discovered that the browser's Back button exists and can Open in New Tab. Bookmarks, zoom, ctrl-F are all too confusing. A feature that requires right-clicking may as well be black magic to most people.
The thing I really hoped this "new" version would account for is when text changes and having links survive minor edits/changes. Perhaps I missed it and it does.
- https://github.com/NYTimes/Emphasis
- https://open.nytimes.com/emphasis-update-and-source-6ffac5e6... (2011)
It does. Text changes. It is not frequent, often minor. Corrections can be more significant depending on their nature.
…why not put a css-selector in the link?
Besides XPointer and its precise addressing I used to be very fascinated about more generic link types. I don't remember the spec (was it XLink?) but there was one where source, target and the location where the link was specified were independent. A link could also have multiple ends.
So you could create a personal document that linked a HN comment to two different sentences in a Wikipedia page for example.
https://example.com/page.html#:~:text=[prefix-,]textStart[,textEnd][,-suffix]
https://example.com/page.html#:~:text=...
https://example.com/page.html#:~:text=...¶m2=two&:~:param3=three
WICG/scroll-to-text-fragment#4: "Integration with W3C Web Annotations" (2019): https://github.com/WICG/scroll-to-text-fragment/issues/4#iss...
All meaning all the browsers listed in the linked table. These may be the major browsers, but not all of them.
I don't know how to design it separately. The default is that selections are blue and fragments are purple, but if you choose different colors for both, in line with your color scheme, how will people know which is which? I guess you can still choose different tones of blue and purple.
Why shouldn't selecting text automatically update the address?
> If you’re using Chrome, simply highlight some text, right-click, and you’ll find the “Copy link to highlight” option in the context menu
I agree you should prefer IDs but they aren't always available, and often using them is very convoluted for users (how many are going to know how to use the element inspector, or even what an ID is?).
And "add useful UX features that people want" is not "EEE", especially when there's a standard doc and test suite for it.
https://wicg.github.io/scroll-to-text-fragment/
> This specification was published by the Web Platform Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
It's not implemented in Firefox ESR and won't be until June 2025 [1]
Can you elaborate on this a bit?
And also that they believe that adding features like this to browsers is bad behavior in the first place. If that were the case and people abided by the "do nothing until the W3C acts" rule we'd probably all be using IE6-level browsers still.
shift+i -> "permissions" -> disable "override keyboard shortcuts"
Usually in Chrome and when visiting sites that are not 100% pure text (e.g., bloated Confluence docs)
Because of this bloat in Confluence, we actually just use it for editing and serve the content in a more lightweight way using the API and our own templates.
If sites choose not to load the page all at once they can provide another search bar with a different experience. But that's not the Ctrl-F search.
Normally I think related side notes are fine. Heck, I’m guilty myself. But nowadays I always open the link first to make sure it's the right topic and to make sure it’s not addressed in the article. Often leads to a better response as well.
Yes, we know scroll-jacking or any other override of browser behavior is extremely disliked here.
In these cases I usually click outside the editor and then control+f works as usual.
If not, you can also try F3, and if that's hijacked too browsers usually have a shortcut to "find in page" in the hamburguer/three-dots menu
https://github.com/settings/accessibility
But for whatever reason this only seems to work temporarily (if it is already toggled off for you, you need to enable it again, save preferences, then toggle it off, and save preferences) and then it does not hijack '/' for a few minutes.
I'm open to feedback! What would be a better approach? Please don’t just suggest “no custom shortcuts for any web app”—people spend 60-70% of their workday using the UI components my team maintains. While random sites hijacking shortcuts is definitely frustrating, in our case, the pros seem to outweigh the cons.
Maybe allowing users to disable or customize shortcuts could be a solution? Or would that be over-engineering?
Honestly, I think the web platform could use a standard API for defining shortcuts, with browsers providing a UI to manage or disable them. Maybe I'm still over-engineering here.
Would really appreciate hearing others’ thoughts!
e.g. GitHub. If I'm on a source file and I hit Ctrl-F, yes, in fact I do want to search the source code and not GitHub's UI -- and their search bar for that purpose is delightfully simple and not distractingly different than the normal search I expected to see when I hit that key.
What would make me rage throw my computer through a window would be if I hit Ctrl-F and it loaded a full-screen modal which showed a search results page of result snippets or something. So I'm impressed with the restraint shown by the front-end developers (or their "UX designer" taskmasters) in this case.
(I'm still puzzled why so many more people choose to use a browser distributed by the world's largest ad network over one with all the same features plus a few nice add-ons, made by a software company.)
> immutable hardware-derived identification,
Is this in the telemetry data? Not in headers, right? Just curious to learn more