I am designing a web app. In some places, the user will have to enter a single digit. I would like the input for the digit to meet the following criteria:
I don't want the arrow buttons (a.k.a. "spin buttons") to show up, since I think they are unnecessary clutter.
I want the number keyboard to show up on any device without a physical keyboard, or at least on recent iOS and Android devices. The normal text keyboard is full of unnecessary clutter.
I do not want the validation behavior for number inputs built into recent versions of Firefox (red border, tooltip). I am planning to use my own validation, or maybe do without it.
I would prefer to avoid any browser-specific hacks.
This is what I tried and why my attempts were disappointing:
First, I tried using <input type="number">. The arrow buttons showed up in Firefox on my Mac. I managed to disable Firefox's validation by setting an input event handler on the input with the line this.setCustomValidity(" ").
Next, I tried doing some research and found this question. It mentioned a bunch of stuff that looked like it would only work on Webkit. I didn't actually try it.
Next, I tried using a text input (<input type="text">) with the pattern attribute set to [0-9*]. According to this answer, that should make the number keyboard come up. It did that in iOS, but not in Android.
I know about the inputmode attribute that is meant for this purpose, but it doesn't seem to be supported at all.
Does anyone know of a way to implement a sane cross-browser number input? Is what I am asking for unreasonable?
I had the same problem, but after a lot of trial and error found a very simple work-around: live demo.
The code:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Demo</title>
<style>
input[type="tel"]:invalid {
box-shadow: none; /* 0 doesn't work */
}
</style>
</head>
<body>
<form novalidate>
<input type="tel">
</form>
</body>
</html>
.
There is (just) one imperfection: on Androids, it pulls up the phone-number keypad in stead of the normal numeric keypad. But those are almost identical, and I don't think many users will notice.
The novalidate (for which novalidate="novalidate" is valid syntax as well) plus the CSS declaration might seem redundant, but there is a lot going on in browser world when it comes to form behavior, with significant interbrowser and intrabrowser inconsistencies. Have a look here, for example.
Apparently, that behavior is not yet standardized by the W3C. Therefore, I would choose redundancy over taking chances.
Related
I am using the event listener structure like below to do some stuff when the input box loses focus.
But it won't work. What event should I listen to, to get the moment the input box loses the cursor inside it (i.e. user clicks outside of it)?
document.getElementById('div inside which input is located')
.addEventListener( 'blur', function(e){
if(event.target.className=='editInput'){
doStuff(event.target);
}
} , false );
The correct event is onBlur. Look at this code:
<!DOCTYPE html>
<html>
<head>
<title>element</title>
<script type="text/javascript">
function message() {
var text = document.getElementById("test").value;
alert(text);
}
</script>
</head>
<body>
<input type="text" name="test" id="test">
<script type="text/javascript">
document.getElementById("test").onblur=message;
</script>
</body>
</html>
It works and prints the content of the input when it loses focus. Maybe your error is that you attached the event to the div and not to the input?
var input = document.getElementsByTagName('input')[0];
input.onfocus = function() {
this.className = 'highlight';
}
input.onblur = function() {
this.className = '';
}
Setting a handler for the blur event using vanilla Javascript:
You could set the blur event's handler for the specific element "test" in vanilla jQuery using code such as this
document.getElementById("test").onblur= yourEventHandler
You can use the event handler in your question without any modifications. That's that part covered. However, I believe there is more to be said here.
The big picture:
The blur/focus events on text inputs are among the least troublesome events to work with in terms of compatibility across browsers. But if you are going to do any serious development I recommend using a framework such as jQuery, YUI, Dojo, MooTools etc. These will both help you write nicer code and will shield you from compatibility problems.
Unfortunately, the reality web developers have to face is that of many browsers with similar, but not identical behaviours. It is not enough to find a solution that happens to work on a browser we happen to be using at the moment we test the piece of code we have just written. We need to ensure our code works correctly across all browsers our application is targetting. So what happens if you suddenly discover that your way of assigning the blur even does not work on some browser for some specific element but another one does? Do you go everywhere in your code and put if's there? Are you sure you haven't missed anything if you go this route? And then, if you find another problem with another browser do you add another if' and so on and so forth? Maybe you decide to define a function setBlurEventHandler that does what it says on the box and use it everywhere in your code instead of statements such as the above. Do you do that just for the blur event or for pretty much everything you do? It makes sense to do it for other things too. Great. You now have a framework for writting code that is compatible across browsers. If all of us kept our frameworks to ourselves we would be spending a lot of time re-discovering and fixing the same problems. Enter open-source Javascript frameworks. You can just use them taking advantage of the hours of hard labour others put into them, but you can also contribute by reporting bugs, writing code and documentation. Doesn't this make more sense? (Or if at some point in the future you are sure you have a framework based on some very clever ideas, however incomplete, by all means put it out there and see both what you can offer to the community and what the community can do for you ... )
To better drive this point home, let me show you some comments taken from jQuery's source. As I said before, the blur/focus events on text inputs are among the least troublesome events to work with in terms of compatibility across browsers. But how confident are you that you are aware (or remember!) the various browser peculiarities your code has to deal with when the handling of even the most basic and least troublesome events comes with such inline code documentation?
// IE<9 dies on focus/blur to hidden element (#1486)
// IE doesn't fire change on a check/radio until blur; trigger it on click
// This still fires onchange a second time for check/radio after blur.
For the reasons outlined above I recomment against working with the DOM directly.
A better approach using jQuery:
Suppose you had a div called formDiv with three input elements only one of which initially had the editInput class.
<div id=formDiv>
<input type="text" name="test1" id="test1" />
<input type="text" name="test2" id="test2" class='editInput' />
<input type="text" name="test3" id="test3" />
</div>
Using jQuery, you could simply do something like (I copied the actual logic of the event handler from your code):
("#formDiv input").blur(function(){
if(this.className=='editInput'){
doStuff(this.target);
}
});
which I believe is closer to what you wanted to do, than other solutions here. (In your code you were trying to attach the event to the div containing the inputs. I may have misinterpreted your intentions but I thought this was what you wanted.)
You can try this solution with this jsFiddle: http://jsfiddle.net/r7tuT/3/
Some parting thoughts:
There are people that will tell you that this or that framework is better and they may be right. I will only comment that jQuery is the most popular one and is pretty decent. The choice is yours, but as I said I believe you should start using one of these frameworks sooner than later as it will improve the quality of your work, let you do certain things in a blink of an eye and change the way you approach problems. When a framework or programming language does this to you, is a great moment in your life as a coder :-)
Try onblur instead of blur.
blur is a method which causes an object to lose focus, whereas onblur is an event that is raised when the object loses focus.
We have a site where users can enter statistics for an item.
The statistics are simply int's or float's no formatting required.
We could set it up so that each td gets replaced with a <input type="text" />, but that requires us formatting the inputs so they look like they aren't inputs, and that comes with a whole host of cross browser css problems!
So we are looking at contenteditable, But I am wondering how many issues we are likely to run into with this?
We are looking at using an implementation basically like this: http://jsfiddle.net/hailwood/XQhh3/
There are many HTML rich text editors that use this approach, and your problem appears considerably simpler. If you are only worried about client side issues, compatibility is the biggest problem I can think of. Many mobile browsers do not support this.
Most of the difficulties I can see you running into pertain to DOM selection and manipulation if you have more complex content than text nodes, but otherwise you should be fine.
I'm building a form using jQuery Mobile but if I use an input filed with the attribute type="number" the numbers entered get formatted using the thousands convention
example:
if I enter 1234567
the number will be converted in to 1,234,567
<input type="number" name="number" id="number" value="">
is there a way to avoid this?
thanks
Most browsers do not do that, but WebKit-based ones (like Chrome), does. Incorrectly, I might add, since I believe it is stated in the HTML5 specification that no such formatting should be done.
This is a major problem for me when it comes to HTML5 input items; that they are not customizable enough and almost unusable in any sort of production environment because of different client behavior. But this (I hope) will get changed as the specification becomes more mature, so that the developer can decide things instead of the browser.
Another example is how required works on some browsers, and how the error message is decided on.
The solution to your problems is to not use type="number", and instead go back to using type="text" and adding the attribute pattern with the regex value of "[0-9]*" which will make it show up as a number input at least on Apple phones. Not on Android, however, I think.
What you could do is check on the requests what kind of client it is, and use different methods depending on that. Like using type="text" pattern="[0-9]*" for iPhone and desktop computers, and type="number" for Android.
Why is it that when I use Firefox to enter: 漢, the GET will transform to:
q=%E6%BC%A2&start=0
However, when I use IE8 and I type the same chinese character, the GET is:
q=?&start=0
It turns it into a question mark.
Mark the encoding of the page as UTF-8 and this problem will go away. Firefox will fail to autodetect your encoding without this hint sometimes, too. And you may have manually changed the encoding in IE once, so that becomes the new default for unmarked pages.
put this in your <HEAD>:
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
If your content isn't really in UTF-8, then you'll need to use an alternate method. There's an html attribute on FORM that hints to IE that you want non-ANSI codepage characters to be sent as UTF-8, but it's far nicer to just use the correct content type.
Also, the address bar may not be the best place to look at the resulting text, as the last time I checked, it didn't reliably work with non-ACP characters. Make sure you're looking at the actual request data.
If you're talking about entering text into the address bar or search box in the browser, and not a specific web page, I don't reproduce this problem on English Windows 7. Perhaps you're using a very old version of Windows and your system ANSI code page does not contain that character; Win95/Win98/WinME would certainly have that problem.
Edited to add:
In IE 8, entering the character you specified on a page containing this content works exactly as expected for me. I've verified this with Fiddler. Whatever problem you are having is probably different than what you have described so far.
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
</HEAD>
<BODY>
<form accept-charset="utf-8" method="get" action="http://www.example.com/something">
<input type="text" name="q">
<input type="submit">
</form>
</BODY>
</HTML>
You actually don't need the accept-charset unless you are using an alternate encoding for the page itself. But I am leaving it in for illustrative purposes. For it to be actually useful, at least in earlier versions of IE (things may have changed; a colleague of mine specified the behavior back in IE5 or so), you need a hidden "_charset_" field with no value to encourage the browser to mark what charset it actually used, but that's superfluous in a utf-8 page).
It can either be font installation or URL encoding issue
One of main issue which I have seen when dealing with CJK characters is the installation of East Asian Language fonts not done by default when OS is installed. These characters show up properly in MS Word even without installation being done.
To make sure all applications in OS can deal with CJK (Chinese, Japanese and Korean), doing the below exercise is better
Go To Control Panel
Select Regional And Language Options
Go to language tab
Select checkbox to install fonts for East Asian Languages
Hopefully you have the windows CD with you to proceed with this.
After that IE8 hopefully would show characters properly.
Also in case you are doing any url encoding make sure you always use UTF-8 as the character encoding when dealing with non ASCII characters.
To begin with, IE believes that Chinese characters can be sent 'as is' in UTF-8, while Firefox thinks they need to be URL-encoded.
Have you watched the GET request on the wire? I bet that it's really a three-byte sequence and that the tool you are using to display it is reducing it to a ?.
On a web page that is to be displayed on an iPhone, is there a way to get the number pad to come up when the user taps in the field, instead of the qwerty keypad?
This guy says here's how to do it, but as of 2.0, this "feature" was disabled.
I'm guessing there's some fancy javascript to employ to get around this limitation?
If you use the HTML5 number input type, the keyboard will default to showing numbers. It's not the number-only keyboard, but it's a bit better than just text.
Yes, this used to be possible by including the word "zip" in your text field's name attribute. Unfortunately, Apple seems to have removed this in 2.0 and later. I suggest you file a bug.
You can make calls from JavaScript to Objective-C and then display what ever you want. If you want a framework to help you out you could check out QuickConnectiPhone. It is available at https://sourceforge.net/projects/quickconnect/.
You could also check out http://tetontech.wordpress.com. This is the develpment blog for QuickConnect. It has some example code in addition to that which is included in the sourceforge download.