Posted by damir 10/25/2024
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.
https://en.wikipedia.org/wiki/WHATWG
The Web Platform Incubator Community Group is "a lightweight venue for proposing and discussing new web platform features" within the W3C
It's not implemented in Firefox ESR and won't be until June 2025 [1]
Be honest and admit that full, reliable support for this feature among all the main browsers is not going to be there until at least next year.
If you decide to not update or use a version that is updated less often, that is not the fault of the people working on the software.
Be honest and admit that you are knowingly using a Firefox version that gets major updates only every 52 weeks and still complain about not getting a released feature.
If you're thinking of promoting use of this non-standard feature, consider how many people it _doesn't_ work for, rather than thinking "oh and yes even Firefox (asoftendaysagoandonlythedesktopmainlinereleasenottheesrormobileversion) so I'll rush out and proseletyze this amazing feature that clearly everyone can use"
If you generate links that include and depend on #:~:text= to make sense, accept that it will confuse users whose browsers do not support it. They will be linked to the top of the document and no text will be highlighted. Consider not only linking, but also quoting what you wanted to be highlighted, e.g.
John says <a href="https://example.com/#:~:text=I%20dislike%20this">he dislikes it</a>:
<blockquote cite="https://example.com/">
Down with this sort of thing. <em>I dislike this</em> and can't abide it.
</blockquote>Browser support isn’t about what version you personally decide to run, it’s about what version your users are running. What Firefox ESR supports is the relevant factor here.
> Be honest and admit
Can you make your point without accusing people of dishonesty?
I was just returning the favor to amiga386 to make them see this is not a normal form of communication. They lead with
> Be honest and admit that full, reliable support for this feature among all the main browsers is not going to be there until at least next year.
When I think they meant to say support for most users isn't there until next year. Because all major browsers have support already now in the current version.
They did say that though:
> full, reliable support
“Reliable” in the context of browser support means widely supported in the browser versions people actually use – i.e. web developers can rely upon it being there. Something that is only available in a browser version released last week is not “reliable” in the sense of browser support.
The onus is now on users that use Firefox. You're right that many Firefox users don't run the newest version, and you can't in general rely on a Firefox user having a browser new enough to support this feature.
Maybe this is a pedantic distinction, but it feels weird to say "Firefox doesn't support X" to mean "Old version of firefox, that some people use, doesn't support X"
As I said in my earlier reply, that is not what “reliable” is referring to in the context of browser support. “Reliable” means “We can rely upon our users having it available in their browser”.
This feature does not have reliable support and will not have reliable support until common browser support matrices – of which Firefox ESR is a part – includes support.
OP was correct to say that browser support is unreliable and that Firefox ESR is the thing causing this and will continue to be until next year.
Are you a web developer? “Reliable browser support” is a very well-understood term of art.
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.
1. If I'm interacting with the URL/address input, I'm either entering a full URL, or searching through my local history to jump to a previously-visited page (or, in Firefox, a tab I may have open on another device). I don't want that shipped off to my search provider for autocomplete suggestions.
2. If I'm interacting with the search input, I want autocomplete suggestions. Additionally, because it retains the value of the last term I searched for, I can use it as a shortcut to jump back to the results if I no longer have the tab handy.
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.