The HTML attribute autocomplete="off" doesn't have an effect on iPhone Safari. In addition, iPhone Safari will look at the title, name, and placeholder fields to attempt to resolve the type of value that a field should autofill to.
As a result, an input written in JSX like this:
<input
placeholder="* Property Name"
autoComplete="off"
/>
Will always result in the field being autofilled to the user's full name - as if the autoComplete field (capital C in JSX, lowercase in HTML) were set to "name".
I have seen various threads with solutions that no longer work, such as autoComplete="new-password".
One solution that I have found that does work is to replace the latin 'a' in 'name' with the cyrillic 'а', like so:
<input
placeholder="* Property Nаme"
autoComplete="off"
/>
As a result, the field will no longer autocomplete to the user's full actual name.
However, this seems like a hacky solution that could potentially cause a crash if the character set of a device or font only has ascii characters.
How are others solving this in 2023?
Related
In my Angular application, capitalized umlauts are automatically changed to the related vowels by Edge and Chrome.
Example: In the following image, I typed "ÄÜÖäüö":
Edge texte input example
In the data the capitalized umlauts are passed correctly - they are just displayed incorrectly in the text input field. I don't want this behavior.
What I tried so far, but didn't trigger any effect:
autocomplete="off" in the input field
spellcheck="false" in the input field
<tag autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" /> in the index.html
different language settings in the browsers.
different language settings in the operating system (Windows 11)
Apparently, this problem is due to the display of the character set in Chrome and Edge. In input fields, the capitalized umlauts seem to be cut off at the top.
One workaround for me was to change the font-family. Is not satisfactory though.
Link to a helpful answer:
https://github.com/IBM/plex/issues/191
I have a simple form and one of the input fields is of type number.
<input type="number" step="0.5" required/>
This works in most browsers. However on Internet Explorer 11 the validation for type="number" is flawed. It only allows numeric values, however after a number has been entered the validation seems to stop working.
For example, in most browsers the validation for type="number" works like this:
50 is a valid value
example!50 is an invalid value
50example! is an invalid value
Whereas in Internet Explorer it works like this:
50 is a valid value
example!50 is an invalid value
50example! is a valid value
How would I ensure that only numeric values are allowed in the input field for Internet Explorer (whilst also allowing step="0.5" to continue working - i.e 10.5 would still be valid even though "." is non-numerical)
I can reproduce the issue in IE 11. To solve the issue, we can add regex. The example code is like below, it allows for exactly one decimal and works well in IE 11:
<input type="number" step="0.5" required oninput="this.value = this.value.replace(/[^0-9.]/g, '').replace(/(\..*?)\..*/g, '$1');" />
Was able to fix the issue with this regex:
~r/^\d+(?:\.[05])?$/
After a bit of research I guess that autofill works (on safari) if input has specific id or name, see list: https://stackoverflow.com/a/36151606/2366630
I tested each of them and it works perfect, but problem is that I can't change id or name attributes which are defined previously by my provider and they can't change server-side id or name.. also it doesn't match any from this list.
I also tried to change type and class attributes from this list but it doesn't work as well.
So my issue is next, beside id and name attributes how can I force input to work credit card autofill and scan function on safari..
This is what my input looks like:
<input id="cardn" name="cardn" type="text" autocomplete="cc-number" x-autocompletetype="cc-number" size="19" maxlength="19" class="form-input" required="">
I tried the <input type="number" /> but on Opera that outputs a strange input box coupled with an "up and down" handler. What I expected was a regular text field that once you focus on it prompts the number keyboard instead of the alphabets. Is that even possible?
p.s. I'm not trying to validate. It would be a nice user experience, that's all.
Use pattern="[0-9]*"
Example number input: <input type="number" pattern="[0-9]*" />
Example phone input: <input type="tel" pattern="[0-9]*" />
Note: Browsers that do not support type="tel" will default to a text type
Beware: Using type="number" can cause problems with some browsers and user experience for credit card, postal code, and telephone inputs where a user might need to enter punctuation or a comma being in the output.
References:
http://bradfrost.com/blog/mobile/better-numerical-inputs-for-mobile-forms/
http://danielfriesen.name/blog/2013/09/19/input-type-number-and-ios-numeric-keypad/
The official HTML5 way to handle phone numbers is:
<input type="tel">
You may not have liked the "strange input box" you got with Opera when you used<input type="number" />, but that really is the appropriate type of input area when you want to require visitors to enter a numeric value.
type="number" is HTML5 and many phones do not support HTML5.
For call link you can use type="tel" or
Special A.
You should look at CSS WAP extensions (page 56) too.
EDIT 10/2015:
Most if not ALL smart phones support HTML5 and CSS3, so type="number" is the best way.
This post is now invalid. All smartphones support HTML5 and CSS3 now, so adding type="number" does in fact prompt the number pad to pop-up. I just checked it on 2 different Android versions, and an iPhone. Just so no one in the future tries WAP instead of the correct HTML5 format.
This will work on mobile and will prevent the letter "e" (along with all other letters) from being allowed to be typed in in the desktop version of your page. type="number" by itself still normally allows "e" per spec:
<input pattern="[0-9]*" type="text" oninput="this.value=this.value.replace(/[^0-9]/g,'');">
If you use type="number" in the above, then if you type "123" then "e" the oninput JS will replace all contents of the box. Just use type="text" if you really just want integer values.
You can control the style of keyboard that comes up on input focus, independently of the input type, with the HTML attribute inputmode. What you're probably looking for is inputmode="numeric", which shows a number pad with 0-9. There are other options, such as a number pad with # and *. See the docs linked below.
This is ideal for uses cases where type="number" would not work, such as numbers formatted with dashes.
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode
Try <input type="number" pattern="/d*">
OR
<input type="tel" pattern="/d*">
This will help if you working with Android.
I happened to write this:
<input type="hdnStatus" name="hidden" value="1" />
Instead of:
<input type="hidden" name="hdnStatus" value="1" />
I was surprised that the first line generated a text box with no correct type
specified.
If first line generates text box, then is the below line of any use:
<input type="text" name="tbox" value="" />
It definitely is. What I mean is that rendering engines should be smart enough to
reject any incorrect input. Such things always create confusion and problems.
How did that happen?
Is this browser's fault or something else?
Or it is something wrongly correct?
From the HTML 4.01 spec:
Attribute definitions
type = text|password|checkbox|radio|submit|reset|file|hidden|image|button [CI]
This attribute specifies the type of control to create. The default value for this attribute is "text".
So it appears that your browser falls back to the default value for type if it is invalid. This seems like sensible behaviour to me.
All browsers (that I am aware of) will degrade to an input with type="text" if the type attribute is not valid.
Some people have even advocated using this to your advantage to get ready for HTML 5, which has more types.
For example you could do:
<input type="date" ...
which would still be a regular text box, but the fact that the type is distinct, you can use javascript/css to make it more usable by adding a datepicker or something automatically.
And then, once HTML 5 actually does come around, the browser itself would be able to render a custom input widget that is specific for dates.
Another usage of this feature is type="number", which is also a valid type in HTML 5. Using javascript to monitor fields with type number would allow for immediate feedback to the user if the data they entered was not actually a number.