I'm implementing my own autocompletion on an <input> field inside a UIWebView, and the built-in keyboard autocompletion interferes with the user experience. Is there a way to use HTML or Javascript to signal to iOS that it shouldn't try to autocomplete?
In my comments I mentioned using the html attribute autocomplete but I tested it, and it doesn't address your issue. However, there is an attribute specific to Mobile Safari which may help. You could try turning off autocorrect like so:
<input type="text" id="your-field" autocorrect="off" />
Related
I've noticed navigating in websites like Dell or Google, that typing in their search text box with iPhone, in the keyboard appears a blue button 'Search' instead of the standard 'Go' button that appears on any normal form.
What should you do to display the search button?
having type="search" is usually all you need to make software Search keyboard appear however in iOS8 it is mandatory to have a wrapping form with action attribute.
So the following code would have a software keyboard with “Return” button
<form>
<input type="search" />
</form>
But this code should have blue “Search” button instead
<form action=".">
<input type="search" />
</form>
You can influence this behaviour with:
<input type="search" />
JS Bin demo
Ignore the submit button's text being 'kettle,' I just wanted to be sure that it wasn't the submit button influencing the text of the iOS keyboard...
This is, of course, backwards compatible since a browser that doesn't understand type="search" will default to type="text", which is useful for creating forward-planning html5 forms.
I was not able to get the search button with
<input type="search" />
However, I did get it to appear with
<form>
<input name="search" />
</form>
On iOS 8 you can enable the blue "Search"-button on the keyboard by doing one of:
add input name=search
add input type=search
add id to input with the case sensitive word "search" in the ID, for
example the-search or thesearchgod
In HTML5 standard, adding enterkeyhint attribute on the input is the proper way to change the label on the virtual keyboard
<input enterkeyhint="search" />
If no enterkeyhint attribute is provided, the user agent might use contextual information from the inputmode, type, or pattern attributes to display a suitable enter key label (or icon).
See MDN Docs about enterkeyhint
When using #Anton Bielousov suggested solution, this also changes the styling of Android Devices. To counter this I had to:
Add form around input.
Add type="search"
Add name containing search
Add styling to counter the unwanted android styling
Android styling:
input[type=search] { -webkit-appearance: none; }
/* clears the ‘X’ from Internet Explorer */
input[type=search]::-ms-clear { display: none; width : 0; height: 0; }
input[type=search]::-ms-reveal { display: none; width : 0; height: 0; }
/* clears the ‘X’ from Chrome */
input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button,
input[type="search"]::-webkit-search-results-button,
input[type="search"]::-webkit-search-results-decoration { display: none; }
<form action="" class="search-bar__form-form">
<input
class="search-bar__input"
name="search-bar"
type="search"
/>
</form>
The keyboard is handled by the operating system (iOS) and cannot be directly altered. The type of input required determines the type of keyboard to display.
If the website in question is HTML5, then #David's answer is valid.
I've searched high & low for an answer on this and I can't seem to find an answer or anybody else having the same issue. Hope some one can assist?
I have a web page for signup which I'm viewing in an iPhone UIWebView. A user is asking if we can stop capitalization on the first letter of the email address being entered. I thought this didn't matter, but apparently it can for the local-part on some email systems (apparently it's only the domain that is only case insensitive).
It seems autocomplete is the culprit.
I've tried adding autocomplete="off" to the input element in the html, but iOS is obviously ignoring it:
Can auto-complete be turned off on a html input text field within a UIWebView?
Thanks
Add autocorrect="off" attribute to your input text field.
Seems like Apple have some documentation now:
Although the UIWebView class does not support the UITextInputTraits
protocol directly, you can configure some keyboard attributes for text
input elements. For example, you can include autocorrect and
auto-capitalization attributes in the definition of an input element
to specify the keyboard’s behaviors, as shown in the following
example.
<input type="text" size="30" autocorrect="off" autocapitalize="off">
You can also control which type of keyboard
is displayed when a user touches a text field in a web page. To
display a telephone keypad, an email keyboard, or a URL keyboard, use
the tel, email, or url keywords for the type attribute on an input
element, respectively. To display a numeric keyboard, set the value of
the pattern attribute to "[0-9]" or "\d".
These keywords and the pattern attribute are part of HTML 5, and are
available in iOS 3.1 and later. The following list shows how to
display each type of keyboard, including the standard keyboard.
Text: <input type="text"></input>
Telephone: <input type="tel"></input>
URL: <input type="url"></input>
Email: <input type="email"></input>
Zip code: <input type="text" pattern="[0-9]*"></input>
http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#Configuring the Keyboard for Web Views
Just ran into this recently and I thought it'd be helpful to share.
The HTML <label> element is supported in a weird way by iPhone's (v3) browser. Try this:
<input type="checkbox" id="chkTest" /><label for="chkTest">Click me!</label>
Tapping the "Click me!" label has no effect, the checkbox is not checked.
Lack of support in a touch device for <label> elements puzzled me and I tried to overcome this issue by using javascript. The surprise came when a I noticed a void javascript like the one below also did the trick:
<input type="checkbox" id="chkTest" /><label for="chkTest" onclick="javascript:void(0);">Click me!</label>
HTH
Further info:
Also works with an empty handler: onclick=""
Disabling JavaScript inactivates again the label, even if using the empty handler.
After a bit of experimentation it looks like assigning the following CSS rule to is enough to trigger the expected label behaviour on the iPhone:
label {cursor: pointer}
Is it possible to use form elements in Webkit HTML desktop notifications? I'm tried to open a HTML notification from a Chrome extension, and the <input> I added appears, but I cannot type in it. I'd like to be able to capture the input from it and save it.
var notification = webkitNotifications.createHTMLNotification(chrome.extension.getURL('input-prompt.html'));
notification.show();
<html>
<body>
<form><input type="text" name="here" value="test" /></form>
</body>
</html>
You can get around this in a pretty simple way. You can create a div that serves as your input box, and allow the content of the div to be edited (look here). Then you can use a button or another div as the submit button, then handle the form submit with javascript.
<div contenteditable="true" id="inputBox"></div>
<div id="submitButton" onclick="submitform();">Submit</div>
While I agree that desktop notifications are probably not meant to contain forms, I have a case where having a form in the notification is actually more convenient. I hope this helps.
Notifications are not meant for interactivity. They are meant to notify.
If you want to have interactivity, use an Action instead.
I was wondering if anyone has seen this issue before.
I have two button on a webpage. When I navigate away from the page and hit the back button to return the value of one button is placed in the value of the other.
E.g
<input class="SmallData" type="submit" id="logButton" value="Log In" tabindex="93"></input>
<input class="btn" type="submit" id="acBtn" value="Detailed Quote"></input>
When I come back to the page Detailed Quote replaces Log In e.g.
<input class="SmallData" type="submit" id="logButton" value="Detailed Quote" tabindex="93"></input>
There is no JavaScript causing this to happen. I look at the source everything looks fine but I inspect the DOM I can see that the there is a different value.
Is there something about how web kit handles the dom that it gets corrupted when the back button is used?
Thanks,
Try giving each input element a name="some_unique_name" attribute -- see if that helps Safari differentiate.
Mght it be because of having two submit buttons...?
Just my "random" suggestion though... :)
Check if the same thing happens in Chrome (if you have access to a Windows box) to see if it's a WebKit issue or Safari itself.