Well any website serious about security - yes. But if a single website decides to do it it would work fine. It would be quite easy to just add a js file with this. For example this one for the Stanford JS Crypto Library: https://github.com/bitwiseshiftleft/sjcl/blob/master/core/sh...
We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.
How would protecting a single website help? If the password is shared among different sites, and one of the sites turns out to be malicious, I'll be able to access your single website just fine by typing the sniffed password into your textbox, whereupon it can use however much hashing and encryption as it wants and it won't help.
Ah I see what you're saying. You're right, in the interim period before everyone changes to client side hashing that is an issue. Though there's no loss to implementing it, but it's just not as beneficial until more sites have it.
For example:
If there is no client side hashing: a user uses the same password for n websites. If one of the n websites gets hacked, an attacker can login to all n sites.
If one on site you have client side hashing: a user uses the same password for n websites. If one of the n-1 websites gets hacked, an attacker can login to all n sites. If the client side hashed website is hacked, the attacker can only login to 1 site.
Once each site has a unique salt, then we're secure.
Another issue is how can a website migrate over to client side hashing? I don't think there's an elegant way to do this.
We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.