Timeline for How do websites block selecting text and how do I unblock that?
Current License: CC BY-SA 3.0
25 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 9 at 21:28 | comment | added | Andrew Koster |
@SeanBurton At a bare minimum, the browser should have a simple option to disable this kind of easily-abused feature on a per-domain basis. Just like every modern browser has a way to prevent a site from showing alert() pop-ups, RIGHT IN THE POTENTIALLY MALICIOUS POP-UP, since this feature is easily and often abused.
|
|
| Jan 10, 2018 at 2:23 | audit | First posts | |||
| Jan 10, 2018 at 2:24 | |||||
| S Jan 9, 2018 at 2:23 | history | suggested | chicks | CC BY-SA 3.0 |
formatting
|
| Jan 8, 2018 at 17:40 | review | Suggested edits | |||
| S Jan 9, 2018 at 2:23 | |||||
| Jan 8, 2018 at 2:22 | comment | added | Anders | @phihag Browsers already do this without CSS, links have a larger hit target than the link itself when touched. Sometimes to the point of being annoying and you have to zoom when you actually want to select text because the browser is trying to be too helpful. | |
| Jan 7, 2018 at 20:25 | comment | added | Lucas Trzesniewski | Well, this is what happens when the developer forgets to disable selection (that's a UI built with web technologies). If you want your app to feel like an actual app and not a text document, disabling selection is the way to go. But doing this on a website is a very poor design choice. | |
| Jan 7, 2018 at 15:59 | comment | added | William | Another detail is to keep in mind that HTML isn't just for web. There are plenty of games that use it for the interface, where selecting text doesn't make sense and where the user will click and drag the mouse for various reasons. | |
| Jan 6, 2018 at 13:53 | comment | added | TOOGAM | Oh, and to add to my last comment to @SeanBurton... At the time I said "by default" (but I forgot when I made my last comment), I was also thinking that in addition to Dev Tools, add-ons or Javascriptlets (bookmarks containing JavaScript code) could also be used (and would probably be a lot easier than Dev Tools). Kevin's comment in the question suggests such a thing (and reminded me). | |
| Jan 6, 2018 at 13:39 | comment | added | TOOGAM | @SeanT - I view the browser's job as serving the user to let the user see rendered code in the way that the user desires. The web page's code instructs the browser what is desired, but the browser decides, and it is not the browser's job to perform whatever the page's code says, because the browser serves the user, not the web server (or webmaster/page designer). If a menu shows some unicode/emoji that I want to copy and paste into Google to find out the character's code, I don't like JavaScript/CSS trying to disable my ability to easily select text if that's what I'm trying to do. | |
| Jan 6, 2018 at 13:33 | comment | added | TOOGAM | @SeanBurton: The line is drawn here: proper interface presumes that users have full control over how the browser renders things. Based on that line, disabling users from standard actions seems wrong. MS IE has an option about whether images are displayed, and if that is ever unchecked then, yes, the user must (re-)enable them. My thoughts about "by default" referred to the idea that Firefox and Chrome's built-in Dev Tools would allow the user to override the CSS, so disabling the user's ability to select is the default action (but can be overridden easily-ish, thanks to dev tools) | |
| Jan 6, 2018 at 12:07 | comment | added | Ismael Miguel |
Another way is to add onselectstart="return false;" to the body. Some other techniques (like, removing the selection with JavaScript) work as well.
|
|
| Jan 6, 2018 at 4:57 | history | edited | Zombo | CC BY-SA 3.0 |
deleted 5 characters in body
|
| Jan 5, 2018 at 19:28 | comment | added | Acccumulation | @SeanBurton First you say that this 'doesn't sound like "by default" to me', then you say that if it's not enabled by default then it's essentially useless. | |
| Jan 5, 2018 at 16:57 | comment | added | Sean T | @Acccumulation The user-select: none feature is used all over the place to maintain the style of a webpage e.g, stopping an ugly blue background when selecting an option from drop down lists. You just don't notice because it's being implemented correctly. The problem here is that it's been implemented in a restrictive way to the user, and a browser has no way to differentiate between the two. Therefore, blame the dev's :) | |
| Jan 5, 2018 at 16:21 | comment | added | Chris |
@SeanBurton: Hey, Lynx has the "follow <a> tags when selected" and the "insert line breaks on <br>" features on by default. Its much better than this hypothetical browser. ;-)
|
|
| Jan 5, 2018 at 16:16 | comment | added | Sean Burton | No browser user is going to go to the bother of configuring their browser to explicitly enable a feature like this one, if it's not enabled by default then it's essentially useless and might as well not be implemented at all. And if you are suggesting that every feature must be explicitly enabled by the user, then where do you draw the line? Must the user enable the "images" feature before a website can display images? Must all browsers basically be Lynx by default until the user enables all the features they want? | |
| Jan 5, 2018 at 16:14 | comment | added | Acccumulation | @SeanT Again, if the browser exists to serve the person looking at webpages, then its job is to respond to what the web server sends however the user tells it to. If the user tells it to mute the page, or disallow pop-ups, or copy text, then the browser should do so. | |
| Jan 5, 2018 at 16:11 | comment | added | Acccumulation | @SeanBurton if you view the webmaster as a "user" of a browser, then it makes sense to allow them to enable features. But if you view a browser as existing solely to serve the person looking at webpages, then it should be up to them as to whether a feature should be enabled. | |
| Jan 5, 2018 at 16:10 | comment | added | Sean T | @TOOGAM It's not right to lay the blame at the "major browsers" for enabling it by default. The browser's job is to display/ perform whatever features it comes across in a page's code, not debate if it should be there or not. If you want to blame someone then you should probably point the finger at the restrictive design choices made by the dev's/designers and the way that they implement said features. | |
| Jan 5, 2018 at 15:22 | comment | added | Chris H | This should be quite easy in Greasemonkey | |
| Jan 5, 2018 at 15:18 | comment | added | Sean Burton | What do you mean "by default"? This setting is only enabled if the website specifically enables it, that doesn't sound like "by default" to me. There will always be features that can be misused by bad web designers, there's not much you can do to prevent that without negatively affecting those who do have a legitimate reason to use those features... | |
| Jan 5, 2018 at 15:14 | comment | added | TOOGAM | Thank you, @phihag, for the helpful other point of view. Still doesn't sway my disappointment seeing the major browsers implementing this as default behavior affecting my general computing (on a full-sized computer). Over the years, makers of major web browsers made other decisions I've disagreed with, and I've learned to accept the idea that they have some different opinions than I do. Even so, when I see them do things like (by default) taking control away from the user (and giving it to webmasters instead), my understanding of this reality doesn't mean I can't be still disappointed. | |
| Jan 5, 2018 at 14:00 | comment | added | phihag |
The user-select CSS style is pretty helpful when applied responsibly. For instance, if you want (especially older) users on a touchscreen clicking on buttons near label text, you don't want them to mark the label text instead of clicking the button.
|
|
| Jan 5, 2018 at 13:09 | vote | accept | user6329530 | ||
| Jan 5, 2018 at 10:00 | history | answered | TOOGAM | CC BY-SA 3.0 |
