A reader asked me an interesting question yesterday. His system required all form input to be in capital letters. He wanted to know if there was a way to force the caps lock key to be abled on the client machine. As far as I know, this isn't possible. You can detect the status of the caps lock key, but actually enabling it is not something you can do via JavaScript. However, it is pretty trivial to simply automatically capitalize the user's input. Here is one simple example in jQuery.
I began with a simple form containing two inputs:
<form>
Name: <input type="text" name="name"><br/>
Email: <input type="text" name="email"><br/>
</form>
I then whipped up this simple jQuery:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>
<script>
$(document).ready(function() {
$("input").keyup(function() {
var val = $(this).val()
$(this).val(val.toUpperCase())
})
})
</script>
This code binds to all input fields on the page. I'd probably filter it to a particular FORM ID normally, but this works fine. I listened for the keyup event and simply took the entire val and converted it to upper case. You can see a demo of this here. Not terribly exciting, but it works, as long as JavaScript is enabled of course.
Archived Comments
Using this method, a user might likely think there is something wrong with their computer if everything keeps getting switched to uppercase.
Wouldn't it be just as easy to use uCase() on the server side when handling the data?
Scott beat me to the punch. Relying on the client-side might not always produce the expected results. Even if you were to check for Javascript being enabled and handling it server-side if it wasn't, you may as well just handle everything server-side.
I agree with Scott. Not only could it scare the less savvy but it would be quite annoying while typing.
Replacing the .keyup with a .each and running that bit of script either onsubmit or right before the ajax post (depending on how you're choosing to submit the form) would probably smoother.
@Scott/Robert: Sorry - I should have made it clearer - server side wasn't an option here. They were posting to some old school system.
Also - there would have been text on the form saying to use caps. By itself, the demo I used doesn't really provide any context for why it is capping stuff.
@Danny: Yeah, I can see how doing it on submit could be a bit nicer.
Also, what would happen if the user copy & pastes text into a field? Maybe apply the logic on blur?
Why not use css and assign a class with a text-transform=uppercase to inputs to be capitalized?
regards
Wow you guys are picky today. ;)
@Salvatore: That's a good one too. I don't tend to think of CSS as being 'transformative' (if that makes sense), but yeah, that would do it too.
@Eric: That's where Danny's idea of doing it on submit would help out.
Ray,
imho this rule is not transformative: uppercase can be viewed as a property such as bold, underline, size, font etc.
bye
@salvatore: if it changes the actual data though - I think it would be. Bold changes the _look_ of the data. Capitalization changes the data itself. If you submit the form, I assume you get the caps, right?
Interesting question, Ray.
yes, you could be right, if you think about that submitted value has to be persisted in a case sensitive db.
But there is another aspect: if later on you want to cancel input's capitalization, you have only to cancel a css attribute, without updating any js code or html script.
best regards
I think I'd be going bonkers if content was going in ALL CAPS and my local kbd wasn't set for ALL CAPS. Its like those online forms where somebody embedsa tab function between fields. Argh! If I wanted to tab, id'a tabbed! An' if I wanted to type in ALL CAPS, id'a typed in ALL CAPS.
Now, if there is a business case for displaying the input in ALL CAPS, that's another issue...
@Allan: Yeah, I agree - it would make me bonkers as well. Again though - that was the business need - and the form would have made it clear _why_ things needed to be all capped.
Heh, who knew such a small little post would be so controversial! ;)
I thought your original code fit the use case quite well. There is always more than one way to solve a problem. ;)
One problem with this approach becomes evident when you try to move around in the field using arrow keys. For extra fun, type "aaaacccc", then go back and try to add "bbbb" between the a and c. Having been a long way down this road, what we ended up with was a combination of css text-transform for cosmetics (which others have rightly pointed out does not change the actual data), and adding an uppercasing pre-processing routine to the form's submit function (using jQuery).
Wow,
Who knew this simple question would generate so much information. This was my question. The original system was a desktop app so the system was able to set the caps lock to on if the user was in the application. I am converting it to CF and need to mimic as best as possible that same function.
I see I could use CSS to do this for viewing and then ucase on the server side to insert it into the db. I see a JQuery solution, however, since this is AJAX, my company and the specific Gov't group has not approved AJAX as a viable option...something about it not being secure enough or something...IE 6 is still their standard browser so my life is still a bit hard :)
If there are more ideas, please keep posting them, if not, I thank Ray for posting this, and I thank you all for the many ideas.
@Dan, you could mimic the original app behaviour adding a button, a radio or something that can simulate caps lock on a keyboard: its action can be:
1) toggle a ccs class to text-transform for the upper/lower case on the client;
2) alerting with a message if caps lock is on or off;
3) use this control (the one toggling text-transform) of the form on server side to determine action on the inout value.
you can add a toggle control on every input too.
@Ray: what about changing in your code the keyup event with the change one?
super regards
@Salvatore: When I first wrote it I did use change. It works well too, and probably better for cutting/pasting/etc.
I agree with @Scott Stroz
just loop over the fields using for form.fieldnames on your backend submit page before you do anything.. and use UCASE(), as javascript can fail for many reasons... including other functions on the page causing scripts to be turned off.
Elso why not use ExtJS since it's built in? Why JQuery?
@Chris: While Ext is "baked in", I'd rather not write code that makes use of the libraries under CFIDE. If I'm going to do something unique, I'll use my own download. Maybe I'm being too picky. ;) As for Ext vs jQuery - jQuery is better for me. That's why pretty much 99% of my blog posts involving JS/Ajax stuff make use of jQuery.