Why on earth would they even do that?! It's just as infuriating as sites that muck around with the scroll. No...just don't. Don't try to be fancy, leave the scrolling to me.
People with disabilities and accessibility issues (blind, low vision, limited or poor motor function, etc) all have friends and family.
These users buy gifts for their friends and families. Sometimes they even buy groceries for themselves.
That makes these users your potential customers.
Traversing the web for them is already remarkably difficult, but they do it to buy things for their loved ones.
When they traverse the web they do so using a multitude of tools including specialised screen readers or keyboard and mouse controllers.
Do you know what these users do when they come across your super-aesthetic futuristic website and you hijack the selection functionality for their screen reader? They just bounce to another site or service where selection works.
If your site sells something but has been designed for aesthetics only (hijacking the scroll function, removing indicators of selection, disabling right-click functionality etc) you are excluding almost anyone over 50 (that suffers from low vision) and EVERYONE with accessibility requirements. Don't do it.
Amazing design is being able to make something aesthetically gorgeous, while also meeting or exceeding as much of the WCAG guidelines as possible.
Often it's dysfunction; some stake holder or lawyer, etc., having funded the development of some site, observe that one can 'steal' content with copy+paste and freak out, so the front end developers stick this placebo in to shut them up.
There are legitimate use cases; the classic being 'sort a table by clicking on a column heading', where without 'user-select: none;' (or some other mitigation) the column heading will often end up being selected. Often when one creates a site that involves users interacting with text using a traditional pointer device outside of form controls a need for this will appear.
From personal experience I've seen it mostly pulled out as a solution to an XY problem. Normal text tags give you the text cursor. If you don't want the text cursor, why not disable selection? The proper solution is to just apply the default cursor. I haven't experienced your situation before but that sounds completely reasonable; many non-web devs I know don't even know about the dev console.
It's part of making a Progressive Web App: the user should believe they're using a regular smartphone app, and being unable to simply select and copy text goes a long way towards maintaining the illusion.
Continuous Deployment implies at least a few releases per day. Especially for bundled JavaScript (which is most setups) this means you’re invalidating the cache of the entire app at every payload.
Imagine having to download an app update every time someone merged to master. That’s most SPAs.
This can be the case, but if any of the engineers on staff spend a day reading docs it should generally be fixable. A 30mb it should be chunked by the build process in such a way that small updates usually cause cache invalidation for only a few kb worth of files.
If the library you use to build your SPA (React, Vue, etc.) is relatively up to date you should also probably not be sending the whole app over the wire at once to anyone. Routes and components can be set to only load when the user actually attempts to access them inside the SPA, reducing egress significantly.
In Webpack the chunks whose content don't change don't get new file names and so the cache needn't be invalidated for them. Vendor code which is often the largest part, can stay cached over many deployments so long as the versions are locked. Of course, your host could still send no-cache headers and invalidate everything, but that's a problem with the host/cdn.
Sure, I really do hope that engineers do their best to fix things, but in the sad world of contemporary web frontends, I'm a bit pessimistic (then again, if one has to err on the side of build system over-engineering, you're rarey disappointed).
Still, if the deployment system involves frequent node module updates, the vendor files get "dirty" quickly, too.
Sad!? You must not be old enough to remember when we used the global namespace for modules, and there was no console.log(). You wanna talk about sad, try debugging with alert().
I think they are talking about bundling before code-splitting (like we did back in the Browserify days) and that's true, but we have Webpack, or ESModules now.
And all the people who don't have $500+ phones, unlimited data plans and fast internet connections.
I used a ~$50 android and pre-paid plans for over a year while traveling Latin America. Wast swaths of the internet are basically inaccessible unless you have tremendous patience and nerves as well as leftover money to throw at the ISPs.
The worst imo are sites that mess with how opening links work.
Left click should open the link in the current tab and scroll click or Ctrl+left click should open it in new tab (without switching to that tab). Sites that mess with this and refuse to open links in new tabs really annoy me.
Thankfully floatplane doesn't seem to change any of that but you can't scroll with Vimium's [udjk] keys which kinda sucks.
Oh, yes, I also often have that issue(although I use middle mouse click for that).
I also have these issues with Vim plugins - suddenly websites make scrolling almost unusable with an animation(which is never seen when scrolling with a mouse, touchpad etc. but seems to exist solely to annoy keyboard users), or they can't be scrolled at all, or the whole website UI is built with crazy JS magic so that the plugin can't even find a single link on the whole page.
I don't want to know how bad it must be for blind people who have to rely on automatic tools.
In fairness, this might have just been an overly-broad solution to a certain problem. That is, if you have an element that is clickable and isn't an <a> or <button>, double clicking it can cause page content to be selected when this was not intended.
"user-select" should be disabled more specifically than it is in this case, for sure, but that is what I suspect is really going on here.
Why can’t we just remove user-hostile features like this from browsers? At this point I’m starting to feel like we need to start over. Create a new web, focused on the user, that doesn’t have any of this nonsense.
it makes sense to apply user-select: none on draggable components, or those where the text is not actually text such as icon fonts. But it's one of those instances where a tool that's legitimately useful in one small, specific instance is used more generally without due consideration (or in other examples such as `confirm()` on window exit, actively malicious). I'm sure a better solution for the legitimate use cases could be designed though.
I believe the major advantages of icon fonts over SVGs were potentially smaller file sizes and better browser compatibility. I think the former is minor if it exists at all, and the latter is probably a much smaller concern now.
Not every text in a user interface is supposed to be selectable. Can you select the text on your buttons, your tabs, your dropdowns? Of course not, because it doesn't make sense.
If you think it shouldn't be possible to develop user interfaces that rival the desktop inside the browser, then just say so. If you merely believe existing web standards make this possible without "hacks" like "user-select:none", then you are mistaken.
By the way, I'm a "read with selection" guy myself and I find this behavior on paragraphs of text unacceptable. On the other hand, none of the text on that website is worth reading anyway.
> Not every text in a user interface is supposed to be selectable. Can you select the text on your buttons, your tabs, your dropdowns? Of course not, because it doesn't make sense.
It would make sense, and all text in a user interface should be user selectable and offer the same behaviors.
Maybe you need to copy and paste a lengthy error message. Maybe there’s a word you don’t understand you want to look up in a dictionary. Maybe the interface isn’t in your native language and you want to translate it.
The fact that most mainstream computing environments don’t offer this in 2019 doesn’t mean it’s the right thing to do, rather that our systems have regressed in some (many?) areas when it comes to usability.
> It would make sense, and all text in a user interface should be user selectable and offer the same behaviors.
How would you know? You have never used such a system because it doesn't exist, how do you know it's better?
If you had ever implemented something like a drag and drop UI, a context menu, or even a a simple button using plain old HTML, you would've immediately noticed that selectable text interferes with user interaction. It's the first thing you disable and it's the reason why "user-select:none" must exist.
> How would you know? You have never used such a system because it doesn't exist
I have, it does, it's called Oberon, it was glorious.
Copying text from UI elements was also never an issue for me in GTK2 (can't speak for 3, haven't used it much), it was great (although I admit I don't know if there were a few places in the system where I couldn't copy text, it may not have been 100% the case).
When I'm working in terminal apps (more often than you can likely imagine) on Linux I can also expect to copy text everywhere, it's great.
I'd encourage you to use a diversity of computing systems, it'll broaden your perspective and imagination and sense of possibilities :)
Pardon my ignorance, I assumed we were talking about actual GUIs, not (glorified) text interfaces.
I have used text interfaces, but they are inferior for most users and many types of applications.
> I'd encourage you to use a diversity of computing systems, it'll broaden your perspective and imagination and sense of possibilities :)
I suggest the same to you, but at the application level, not at the "computing system" level. There are a lot of possibilities with graphical user interfaces that aren't limited to text.
I don't think there are that many situations where it is actually productive to prevent user from selecting and copying text even if it's just part of the UI. To focus on your example, copying user interface text might be useful for users who are not sufficiently proficient in the language that the app/website is written in and would like to copy the text into something like Google Translate. This is especially a problem with many mobile apps that prevent selecting text.
The worst bit is applications that prevent copying error messages, because they prevent copying all UI text. And then use complicated error codes. This makes searching for the error message/code excessively difficult!
If there's even one important situation where it is necessary to disable text selection, then disabling text selection must be supported.
I gave you several examples of these. The text for many UI elements isn't supposed to be selectable, because it interferes with user interaction.
Your off-chance example where somebody is trying to copy-paste the text for translation because the application is in a foreign language is subordinate to this.
Good UX is about choosing the right tradeoffs between functionality and usability.
> Can you select the text on your buttons, your tabs, your dropdowns
Usually it's possible by just starting the selection beside the button and dragging across. For example, you can select a navigation button on HN easily this way, along with most sites. I use this all the time when I'm reading about products and want to copy the product name or model number, but it's part of a breadcrumb navigation. It would actually be nice if there was a browser shortcut, where if I hold "s" I can disable opening links during that time and select buttons like normal text.
I've been thinking lately it would be fun to make a web browser that only implements a small percentage of the most useful HTML and CSS specs. Maybe no JS at all. Then start writing my personal sites to be compliant with that browser. Similar in concept to AMP but with very different driving incentives.
Why can’t we just remove user-hostile features like this from browsers
I wonder about what kind of a performance decrease you'd expect from being able to blacklist or whitelist chunks of the web API, like how you can blacklist syscalls in some container platforms.
There are so many reasons why the web would be awful with granular prefs (and I say this as someone who has wanted it for JS in particular). First off, it depends on how you define your block/allow list.
Are they run-time prefs that can be toggled? There is UI/UX overhead, and related attack surface.
If they are run-time prefs, are they loaded when the browser is run, or on each page load/content type load? Do you have to maintain a list of prefs by domain? etc, etc, etc.
If they are compile time, then is it even worth doing for dramatic increase in complexity trying to support users with unusual configuration (e.g. THAT user that decides that preffing off JSON support is a good idea.)
How granular do you allow user prefs on this, and how do you account for the fact that a user may pref off an api/feature that you use as a part of exploit mitigation?
Do you want to log entries that are pref'd off so that users know what is making their favorite app fail?
What are the abuse cases for pref'd features?
How much attack surface is introduced by allowing pref'ing of features?
Does doing this actually contribute to usability on the web, or will it simply lead to a proliferation of "Please ensure that all features are pref'd on" pages, similar to the Javascript pages you often see when browsing without javascript.
I have longed for the universe where all and every JS/CSS stuff are done on the user side. Basically the only thing that the web provide is the very basic HTML and its up to the user to colour their experiences.
One would argue that there would be bloat -- having to install multiple extensions. But then visiting random websites is completely safe, and the only ones that we have to care about is the popular ones that many people have extensions for.
I didn't check but I bet you can turn it off in Firefox, like that ridiculous block on pasting passwords. And that ridiculous no-zooming-allowed on mobile sites. One wonders who though of such bad ideas in the first place let alone the fact that actual people implement them.
There's a sibling comment to yours which a number of people replied to, with a pretty good list of situations where you would want to disable text selection.
I only think thats ok for some very specific things like button / input fields where it looks dumb if its selected by mistake. But for content you're immediately reading, it shouldnt be messed with. Maybe you want to take meaninful notes.
How is this nitpicking over something irrelevant to the primary purpose of their site the top comment on hn?...
They just released a video streaming platform...how about we talk about that?
Anything with Drag & Drop functionality. When users press inside the draggable to try and move it, sometimes text will select instead and need to be cleared before dragging (particularly annoying on mobile devices).
Also video controls that use the UNICODE characters for e.g. play/pause/stop/etc instead of graphic icons (so it scales better at higher DPI). You don't want people to be able to select the text inside the button when pushing the button.
There's actually tons of great usage of user-select: none. This is definitely not one of them though.
It's often a bad idea, but here's some when I used it:
- Widget labels (time, short text, etc)
- Buttons, when text is just an arrow >
(I know, just use <button>) :)
- When double click makes accidental text selection on UI. I had this for a whole page overlay displaying a song's artist and title. (there's another link to the source with selectable text)
Navigational elements, such as a list of clickable links. Gets really annoying when the user is trying to select text, their finger slips and suddenly half the menus on the page are highlighted, and now you need to take into account non-euclidean geometry to get them unhighlighted.
I disabled the selection of various components in apps along the years when I simply find myself accidentally selecting things in regular use that break things or creat selection states that are hard to exit. Most recently it was in a modal-heavy media gallery SPA. If you click and drag outside of a modal when you mean to click, it highlights a grid of media elements that’s hard to exit and really makes for a wonky experience. Like all UX work, you don’t notice it when it’s done well.
I use it for some drag and drop stuff where selecting text would get in the way and would be largely unnecessary (e.g. reordering table columns by dragging a header cell), but that's about it.
Imagine a list of objects with descriptions or names and these objects need to be drag/dropped. It would make since to disable highlight the object names by mistake.
In our application we disallow generated command lines for selection and provide a safe "copy command" icon. As my u see a visual correct command (for a browser view) the resulting select + copy don't include f.e. whitespaces.
It's an command builder where you can drag and drop arguments too - overall user selection don't make sense for this purpose - at least not in our case.
Says the person who wants people to load a ridiculously heavy web page that needs a few billion CPU cycles to run Javascript, all to load a tiny image...
imgur does some referer detection server side to redirect you to the html page if they think they can. So it's possible that the user is getting sent to the web view.
https://i.imgur.com/RWqwd0P.png
Thank you,
-- someone who thinks selecting text is not something you should screw with.