Backward compatibility? Some click targets are meant to be clicked more than once, and can you guarantee that none of those targets may inadvertently be swept up in a change like this?
I'd flip the proposal around, and go for:
<form action="/something" onlyOnce>
...
</form>
The problem then is for the hung responses which still happen frequently enough, the typical hack to unfreeze a requeust is to mash the link/button a second time. Now, would the user have to hunt for the "Cancel" button (an increasingly diminishing target) before being able to click Submit again?
Since you can't guarantee a client will have this behavior, you have to plan for it anyway on the server. I think that's why features like this tend not to be deployed. Features that might help most of the time tend to be beaten to death by the people who keep insisting that they don't completely and entirely solve a problem, so somehow that means it's better not to have them at all, i.e. false hope.
never a good idea to camelCase html attributes :) (in case you didn't know, this won't work:
$('form').attr('onlyOnce')
but this will
$('form').attr('onlyonce')
Mixed case in attribute names is perfectly valid HTML, and tag and attribute names are case insensitive. If jQuery attribute selection isn't, then maybe it should be considered a bug in jQuery.
That's not to say that it isn't a bad idea, but I don't think the inconsistent behavior in jQuery should be considered in arriving at that conclusion.
no it's not valid html.. that's like saying writing gibberish is valid HTML. You can't read mixed case attribute names.. jQuery nor Javascript. It's always converted to lowercase without you knowing.
I'd flip the proposal around, and go for:
The problem then is for the hung responses which still happen frequently enough, the typical hack to unfreeze a requeust is to mash the link/button a second time. Now, would the user have to hunt for the "Cancel" button (an increasingly diminishing target) before being able to click Submit again?Since you can't guarantee a client will have this behavior, you have to plan for it anyway on the server. I think that's why features like this tend not to be deployed. Features that might help most of the time tend to be beaten to death by the people who keep insisting that they don't completely and entirely solve a problem, so somehow that means it's better not to have them at all, i.e. false hope.