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.
This isn't Harry Potter. Text doesn't change.
New revisions are issued, but the text changes no more in those instance than it does when a publisher releases an update to a print work originally published in 1985 with a second edition. The text of the second edition might differ from the first edition, but the first edition's text doesn't change, and the first edition is still the first edition (instead of the first and second editions being synonymous). And the publishers of the print editions could try lying about the identity of these two distinct manifestations the way that online publishers lie about the identities of the works they publish, but no amount of lying about it makes the lie true.
Text doesn't change.
…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?).
I'm assuming Firefox has this context menu feature on the road map as well, though I suspect it will be a long time before Safari adds it just because Apple.
The average person doesn't even understand a URL at all—as far as they're concerned they're generated by computers for computers and are copied around with little regard for what the various components mean. This feature doesn't change that, it just gives a new way of creating a URL that does something slightly different.
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 addition to unrelated gripes, it's generally considered bad practice to comment only based on the title.
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!
I think Github handled this well by letting you choose between a few canned shortcuts, or disabling the feature altogether [1]. Since I seldom print, I opted to bind the command palette to "CTRL + P"
> 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.
I'd agree with this sentiment. It's hard, but an obvious (IMO) pain point that has numerous sites reinventing the wheel and needing to introduce some state to save user preferences.
This group isn't usually silent (far from it), they're just not usually your users.
If you're building a web app a la Notion, Figma, Google Docs, Slack, or anything similar: just ignore the "the web should just be documents that strictly use the platform" complaints. Ensure you build in the required accessibility hooks (since those don't come natively to most custom work), but your users will thank you for accommodating their specific needs better than the platform does.
If you're building a web page that mostly presents information... yeah, maybe listen to the people here.
The main thing you're seeing here is that there's a subset of developers who haven't ever really liked the idea that the web became the primary means of deploying applications.
I think this is really cool and would also allow some interesting features...
- Easier using random input devices. Game engines like Unity with their newest input manager abstracts everything away. Bind inputs not only to standard navigation actions but also app-defined shortcuts.
- Custom UI provided by the browser based on available shortcuts. PCs could get a quick actions bar and phones could have a shortcut drop-down menu exposing functionality.
- If there is an API for enabling/disabling shortcuts the browser can provide context-sensitive shortcut suggestions like some of the profession creation tools like Fusion360 [iirc] where available shortcuts are shown in the status bar.
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
https://news.ycombinator.com/item?id=39181863
But the zeitgeist I’ve seen in 2024 is that Edge and Chrome collect the data they want, plus the data each other is collecting. Tabs, history, etc. Google appears to be more careful, speculatively because it would be easier to prove anti-trust if Google blocked Microsoft’s collecting.