To anyone who makes sites like these, please consider removing the following CSS rule:
https://i.imgur.com/RWqwd0P.png
Thank you,
-- someone who thinks selecting text is not something you should screw with.
https://i.imgur.com/RWqwd0P.png
Thank you,
-- someone who thinks selecting text is not something you should screw with.
/s
Think of all the CPU cycles on all hardware (clients + network devices) and energy used just to fetch web "content" these days.
Might as well return to just burning coal at home to keep warm, thinking of the net effect on the environment.
It's absolutely stupid.
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.
Imagine having to download an app update every time someone merged to master. That’s most SPAs.
Still, if the deployment system involves frequent node module updates, the vendor files get "dirty" quickly, too.
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.
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.
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.
WCAG Guidelines https://www.w3.org/WAI/standards-guidelines/wcag/
Source: We're an accessibility accredited and audited design agency.
Thankfully floatplane doesn't seem to change any of that but you can't scroll with Vimium's [udjk] keys which kinda sucks.
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.
"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.
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.
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.
Which is also hostile. Why not use something like an img/svg?
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.
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.
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.
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.
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 :)
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.
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.
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.
javascript:(function(){function%20allowTextSelection(){document.onselectstart%20=%20null;%20document.onmousedown%20=%20null;%20document.onmouseup%20=%20null;%20window.console&&console.log('allowTextSelection');var%20style=document.createElement('style');style.type='text/css';style.innerHTML='*,p,div{user-select:text%20!important;-moz-user-select:text%20!important;-webkit-user-select:text%20!important;}';document.head.appendChild(style);var%20elArray=document.body.getElementsByTagName('*');for(var%20i=0;i<elArray.length;i++){var%20el=elArray[i];el.onselectstart=el.ondragstart=el.ondrag=el.oncontextmenu=el.onmousedown=el.onmouseup=function(){return%20true};if(el%20instanceof%20HTMLInputElement&&['text','password','email','number','tel','url'].indexOf(el.type.toLowerCase())>-1){el.removeAttribute('disabled');el.onkeydown=el.onkeyup=function(){return%20true};}}}allowTextSelection();})(); * { user-select: unset !important; }
There is no valid reason why cookies are needed to display HTML.
Agree in this case; really bad idea to not let people select text on whole like that.
There are tons of of cases, however, where not allowing selected text is totally a good behavior in UI.
Which should also be avoided
- Widget labels (time, short text, etc)
- Buttons, when text is just an arrow >
(I know, just use <button>) :)
- Navigation, but that might be bad too
Good going.
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.
https://userstyles.org/styles/178336/force-allow-text-select...
The article states that it's been turned back off, but I'm not sure when that edit was. At the very least, here's a report of it happening two months ago: https://old.reddit.com/r/IgnorantImgur/comments/diunko/why_d...