5 ms·
I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface
by da_chicken 8y ago
I've never understood this desire to make a web site behave like it isn't a web site. The entire benefit of web sites is that they've got a consistent interface even between web sites. Don't break that! Don't break copy and paste. Don't break the back button. Don't change or break the right click/context menu. Don't hide the toolbars.
- smadge 8y agoDon't have any application state transitions that are not hyperlinks or a forms.
- baddox 8y agoHmm, what about upvoting or liking a post? Or do you consider an AJAX POST request a “form?” There are also some more obvious smaller examples, like expanding/collapsing an accordion menu.
- smadge 8y agoYou could implement an upvote or like as a hyperlink or a form, then progressively enhance that feature to not initiate a full page reload (iirc this is how HN implements upvotes). Similarly expanding or collapsing an accordion menu could be a hyperlink which by default does request the additional content but which can be progressively enhanced to provide that feature with JavaScript for user agents that support it. As an added benefit to supporting more clients, I find it easier to reason about the state of the view when it is encoded entirely in the URL, and available state transitions being to be encoded using features of well known media types like html. This is one of the main benefits of REST: any user or user-agent which knows the media type knows how to interact with the application.
- dkersten 8y agoIt makes some sense to have an upvote be a form that posts somewhere and the response of which is a redirect (maybe a 307?) back to the page you’re on and then the progressive JavaScript enhancement would be to perform the request asynchronously instead of redirecting. It makes sense because adding an upvote is the same as adding other form data to a database semantically so really should be treated the same way.
- Aeolun 8y agoTry telling that to my enterprise. They’ve just discovered that displaying the URL bar is more secure than not.
- scarmig 8y agoA use case where disabling paste events makes sense: You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars. Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in. Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.
- int_19h 8y agoIf you need to do something like this, do it separately from the actual input. For example, something like "type in the name of the account you're trying to delete".
- contravariant 8y agoDisabling copy paste on the field that specifies the resource isn't a solution though, as that only increases the risk of typos.
- samatman 8y agoAn example of what GP is talking about is Github’s “type the name of the repository to delete it” workflow. Which I appreciate. A typo would just fail to delete, which is the correct response.
- Benjamin_Dobell 8y agoGithub does allow pasting though. The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting. Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text. Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.
- phs318u 8y ago> Don't break the back button. Can someone please tell SAP?
- adharmad 8y agoAnd Oracle.
- brazzledazzle 8y agoAdd it to the giant list of suck.
- ozim 8y agoBlocking paste was supposed to discourage keeping your passwords in plain text on your desktop in 'my_secret_passwords.txt'. Now we have pw managers and people in a lot of places like big corp are lagging 10 years with policies. Just like you have new NIST recommendation about not enforcing complexity. Big customers on the other hannd have it as number 1 requirement when they buy. So even if I wanted to have no complexity enforcement, I had to build in one...
- Sacho 8y agoKeeping strong passwords in a plaintext file on your desktop seems like much better security given the most common threat model - compromised dbs leaking the weak password you reused on several sites.
- dooglius 8y agoAnd one that so many screw up: don't make scrolling anything other than a proportional shift in the page.