iOS Safari automatically converts numbers like 102.0000 or 1,374.1400 to telephone links. The first number, which is inside a <td>, is converted to <td>102.0000</td>, the second, which is also inside a <td>, is converted to <td>"1,"374.1400</td>. Annoying.
In the <head>er I've included the following: <meta name="format-detection” content=”telephone=no" />. It does not work.
Other than perhaps wrapping the decimal point between <span> or <label> tags, or encoding it to ., all hacks I've seen in some sites, is there any other easier way to prevent the automatic conversion of a number (###.####) into a telephone link in iOS?
Thanks.
Related
I'm looking to use the number_field_tag as it works great on mobile devices to allow the user to input with a 10 Key interface. However, the data that they will be entering on their mobile device may contain sensitive information (i.e., part of their Social Security Number).
How can I mask the inputted data as it is being typed while maintaining the 10 Key interface? By using the password_field_tag, it would revert the keyboard to a standard QWERTY.
Not really ruby-on-rails specific, but you could use this in HTML to get a password input that only accepts digits and shows the numeric keyboard on some mobile devices.
<input type="password" pattern="\d*">
I found a CSS solution that works on my mobile. I can use the webkit option to do this.
input[type=number] {
-webkit-text-security: disc;
}
Or for just a particular class as well.
.employee {
-webkit-text-security: disc;
}
Works on Galaxy S4 and Chrome so far with what I've tested.
The best iOS keyboard for entering USD currency values (pictured below) includes numbers 0-9, the decimal symbol, the comma symbol, and the dollar sign. As far as I know, the only way to get this keyboard on Mobile Safari is to use <input type="number">.
Unfortunately, iOS currently has built-in validation for the number input type which screens out commas and dollar symbols. Since this validation "feature" is embedded in the browser and Mobile Safari hasn't yet implemented the novalidate directive, there is currently no way to do this validation manually.
Using <input type="text"> would obviously solve the validation problem, but it also would bring up the regular alpha keyboard, which is not acceptable for my current project (a financial calculator).
I'm on the verge of doing something crazy, like using JavaScript to quickly switch the type from number to text after the input receives focus. I'm grasping at straws here. Any ideas?
For now, JavaScript is the only solution. Here's the simplest way to do it (using jQuery):
HTML
<input type="text">
JavaScript
$('input[type="text"]').on('touchstart', function() {
$(this).attr('type', 'number');
});
$('input[type="text"]').on('keydown blur', function() {
$(this).attr('type', 'text');
});
The idea is simple. The input starts off and ends up with type="text", but it briefly becomes type="number" on the touchstart event. This causes the correct iOS keyboard to appear. As soon as the user begins to enter any input or leave the field, the input becomes type="text" once again, thus circumventing the validation.
There's one downside to this method. When the user returns to an input that has already been filled out, the input will be lost (if it doesn't validate). This means the user won't be able to go back and edit previous fields. In my case, this isn't all that bad because the user may want to use the calculator over and over again with different values, so automatically deleting the input will save them a few steps. However, this may not be ideal in all cases.
You can use the attribute pattern for your input field as text. This instructs mobile safari to bring up the numeric keyboard. Try something along the lines of:
<input type="text" pattern="\d*" />
Just change your pattern regex to what you want.
Here is more information on the pattern attribute
UPDATE
After reading Apple's Documentation on managing Text in Webviews it seems like you are out of luck. You will have to do some javascript magic to do what you want.
You can see a live example of my little ASP.NET MVC3/Razor app here.
The text boxes and textareas all have the following attribute to require just word characters. The form uses jquery-validate.js.
pattern = #"\w{1,50}" //50 characters, etc.
In Firefox only (v13.0.1) these fields are getting highlighted as if they are invalid when they include spaces, or characters like dots, both of which should be legit characters. Why just this browser and how should I correct it? Should I be using a different pattern?
UPDATE: I realized that it is the built-in HTML5 "pattern" attribute that is being handled differently by Firefox, which is why the form still submits OK.
As per an user-request I'm trying to make my (PhoneGap) webapp work better with RTL languages, such as Hebrew. I want to make my inputs and textareas work better with these languages. When the user switches their keyboard to such a language, the input direction automatically switches to right-to-left, as intended. However, the text-alignment stays on the left side, which is unfortunate. I realize I can switch the text-alignment using the dir attribute like so:
<input dir="rtl" />
My plan is to use JavaScript to somehow detect an RTL input language and add this attribute to all inputs and textareas. However, this seems like a bit of a hassle. Is there an easier way I'm overlooking? I don't like the idea of adding more JavaScript for this simple task.
If the whole page is written in hebrew or arabic, you should add the dir attribute on the html element, along with a lang="he" / lang="ar" attribute (the latter is for VoiceOver not reading hebrew/arabic believing it's english. The alphabet and pronunciation are quite different :) ).
If only parts of the page are written in hebrew, then each element containing hebrew text should've these attributes (or its parent) and the other parts in english should've dir="ltr" lang="en" attributes so that no text is left without the appropriate lang and dir attributes. It's faster to add them on a single parent than on each individual HTML elements and if a parent has 5 nodes in english and 1 in hebrew, it only needs 2 attributes: 1 on parent for lang="en" dir="ltr", the other on the child element containing hebrew.
For styling problems caused by rtl writing, you can use one of these attributes as a giant switch for each CSS property like float that uses left or right values (and properties like right, border-right, margin-right, margin: t r b l;; please see the second part of one of my first answers here on UTF-8 and CSS. Note: iOS has no problem with advanced CSS selectors that were only dreams when we had to support IE6 ;) )
When I enter a text with line-breaks and long sentences, I don't want to see a wrapped or without line-breaks version. What is the CSS style to accomplish this? So far I tried white-space property but none gives the result I want.
You probably want the wrap attribute of the textarea tag. Have a look at this page: http://www.tizag.com/htmlT/htmltextarea.php
I'm not 100% sure what end result you want, but if you look at the options and explanations given via that link, you should be able to choose the one that fits your needs.
As #erik said, the way to do this is to use the wrap attribute on the tag itself, i.e.:
<textarea wrap="off"></textarea>
I just wanted to note, in case you're finicky about HTML validation, that the wrap property of textarea isn't part of any HTML standard.
Unfortunately, this is the only way to do this since the white-space CSS property, as you've discovered, doesn't work quite like you would expect when it comes to <textarea> elements.
Via Sitepoint:
Internet Explorer [...] The values normal and pre behave like pre-wrap on textarea elements. The value nowrap behaves like pre-line on textarea elements.
Firefox versions up to and including 3.0 don’t support the values pre-line and pre-wrap (although -moz-pre-wrap is similar to the latter). The values normal, nowrap, and pre behave like pre-wrap on textarea elements.
Opera 9.2 and prior versions don’t support the value pre-line. The values normal and pre behave like pre-wrap on textarea elements. The value nowrap behaves like pre-line on textarea elements.