How to hide autofill safari icon in input field - html

Every one of my input fields has the little person icon with the arrow in safari. How to I disable that? By the way, I have any other similar page and that's not happening. I tried turning off all styles in the web inspector and the one page still has the icon.

If you want to hide it completely, you can use the following css tricks. Basically it detect that 'contacts-auto-fill-button' and move it away from your input field. Make sure you have 'absolute:position' to avoid extra padding from your fields.
input::-webkit-contacts-auto-fill-button {
visibility: hidden;
display: none !important;
pointer-events: none;
position: absolute;
right: 0;
}

You don't have to cancel all properties of the autofill buttons.
To hide Safari's icons altogether, you can also just hide its wrapper.
As the icons are Shadow Content, the DOM won't show it but the shadow DOM does. Just turn on the '<>'-button in the inspector.
There you'll find the wrapping container you can target with css like this:
input::-webkit-textfield-decoration-container {
display: none; /* or whatever styling you want */
}
Inside you will find the password keychain and the caps-lock indicator:
input::-webkit-caps-lock-indicator {
}
input::-webkit-credentials-auto-fill-button {
}
Oh, and while you're at it, don't forget IE with its clear buttons and password eye icons:
input::-ms-clear {
}
input::-ms-reveal {
}

Hide autofill Safari icon in input password field:
::-webkit-credentials-auto-fill-button {
visibility: hidden;
position: absolute;
right: 0;
}

Related: I wanted to adjust the position of the the key icon for a input[type="password"] but couldn't find the pseudo element selector anywhere.
So I cloned the webkit source and was able to find it :)
input::-webkit-credentials-auto-fill-button

As a note – check your field labels and any placeholder attribute values too – as these can also cause autocomplete popups to appear, despite CSS styling rules being applied to the contrary.
See below for more detail...
It should be noted that in Safari (version 11+ at least, and likely earlier versions too, and other recent browsers, e.g. Chrome, Firefox, etc), that even if the various CSS workarounds to hide the autocomplete popups are in place, if the field appears to be a username or password field to the browser, then the autocomplete field still appears.
I found that the browser is not only checking the <input> tag's name attribute for keywords such as username, login and similar variants, but also appears to consider the contents of any placeholder attribute text on the field, as well as most surprisingly, any text adjacent to the <input> field such as that used as a form field label. The label text does not need to be placed into a <label> tag to have this effect - just to be in close proximity to the field, although I haven't had opportunity to extensively test and determine what is considered 'close proximity' - this will require some further research and experimentation or where possible, review of the various web browser rendering engines' source code - such as for WebKit.
As such if you have keywords word such as username, user name, login or similar variants, as well as variants for password, the browser will show the autocomplete popup when the field is focussed, despite any CSS rules to try and hide it!
While I was not as surprised to see the popup being activated by the <input> tag's name or placeholder attribute values, I was surprised to see that label text was considered too by the browser, as such I had to change the wording and labelling of the fields to ensure the popups did not appear. I found for example modifying the placeholder text from 'Please enter your username...' to 'Please enter your user-name...' prevented the browser from recognizing the field as a username field – also notice the hyphen between the words user and name – without the hyphen between the words – the popup still appeared, so it shows how may edge cases the browsers are checking for. As a note, I had already modified the field's name attribute and the adjacent labelling by this stage to remove references to the triggering keywords or their variants.
It is clear that browsers are doing some interesting page inspection to determine if to show username/password popups - and while this is great overall behavior that helps encourage users to take advantage of password managers for more secure credential generation and storage, there are times when you don't want the autocomplete popup to appear. There are use-cases such as within an admin interface that allow administrators to manage staff user accounts for example - where you want to offer a field to search for a staff user by their username. In cases like this you don't want the autocomplete popup to try and fill the field with your own username, but rather allow you to enter any number of staff usernames for example. It would be great if one of the standard autocomplete='off' flags or a future variant could be adopted by the browser vendors to provide this clean control of the autocomplete behavior or a standard CSS attribute that if applied always had the intended effect... but alas this is not currently the case.
For now however, if you are dealing with this issue, make sure you are also considering the contents of any placeholder attribute you have added to any username or password <input> fields - as well as any label-like text that appears nearby. By adjusting and experimenting with the values of these labels/attributes you should be able to work around the page-inspection logic the browsers are using to enable these autocomplete popups.
As always with the web, and as some of browser's rendering engines are closed-source, this will likely continue to be more of an art than a science, until a standard is developed to provide control of this feature for all browsers on all platforms, and it may be necessary to occasionally revisit the code to check it against new browser versions to ensure that popups are not re-appearing due to changed page-inspection logic.

If you use <input> field without wrapping it in <form> tag, Safari 11+ or latest would show you auto-fill suggestion. So here is what you can do.
Option 1: Make sure <input> elements are wrapped inside <form> element. Don't set value of name attribute to "username" or "login".
Option 2: Add name attribute and set its value as "search". <input type="text" name="search">
Note: Using autocomplete="off" or autocomplete="false" on either <form> and <input> would not help.
Neither adding following CSS properties would work.
input::-webkit-autofill,
input::-webkit-contacts-auto-fill-button,
input::-webkit-credentials-auto-fill-button

Even with visibility:hidden or/and display:none Safari Ios keeps popping up icons and buttons. For me, the best solution was to set opacity to 0. This doesn't remove unwanted icons, but makes them completely transparent, and thus invisible. Furthermore, it works on whatever background color or img you're using.
input::-webkit-contacts-auto-fill-button {
opacity: 0;
}

The answers are all correct, however most of them are just curing the symptoms. Mostly, you just need to check your name attribute. In case you didn't give any name, name your input something. This helped in my case as without a name safari makes mistakes in recognizing autofillable inputs

Related

How to remove the default time (12:30 PM) in desktop Safari?

I'm using some type="time" inputs to gather local times in a web app. It's important that the user can see which inputs they've included, and which inputs are not yet entered. In desktop Safari, I notice that webkit seems to automatically insert 12:30 PM as a default time. I want to have the user see clearly that there's currently no time in that field. I want to either find a way to not have ANY input appear when the user hasn't included a time themselves, or if that doesn't work, find a way to specifically target the fields that don't have input so I can change the styling to be clearly different (i.e. have transparent coloring).
My desired behavior is to have the empty input appear empty, as if hour/minute/meridian placeholder text was clear.
I can verify using the fiddle below that times appear correctly empty in all browsers I've tried other than desktop Safari. I have other code to adjust widths, but the fiddle's CSS is copied from the properties of one input for simplicity's sake.
Link to minimal recreation of the problem with current styling here: https://jsfiddle.net/1g92ek3z/1/.
This answer is related but trying to target the datepicker: How to customize html5 datepicker.
I've uncovered browser pseudo selectors that can be used to target the browser default elements in the time input:
::-webkit-datetime-edit,
::-webkit-datetime-edit-wrapper,
::-webkit-datetime-edit-hour-field,
::-webkit-datetime-edit-minute-field,
::-webkit-datetime-edit-meridiem-field
Beware - if you set display: none or visibility: hidden on these corresponding elements it also breaks the input functionality.
So my solution ended up changing the input color based on whether the field has a value and/or focus; something like:
input[type="time"]:not(.has-value):not(.focus-visible) {
color: #EFEFF0;
}
...where has-value is a conditional class when the input has a value and focus-visible is a conditional class when the input has focus.

Strange icon on input fields in Safari [duplicate]

Every one of my input fields has the little person icon with the arrow in safari. How to I disable that? By the way, I have any other similar page and that's not happening. I tried turning off all styles in the web inspector and the one page still has the icon.
If you want to hide it completely, you can use the following css tricks. Basically it detect that 'contacts-auto-fill-button' and move it away from your input field. Make sure you have 'absolute:position' to avoid extra padding from your fields.
input::-webkit-contacts-auto-fill-button {
visibility: hidden;
display: none !important;
pointer-events: none;
position: absolute;
right: 0;
}
You don't have to cancel all properties of the autofill buttons.
To hide Safari's icons altogether, you can also just hide its wrapper.
As the icons are Shadow Content, the DOM won't show it but the shadow DOM does. Just turn on the '<>'-button in the inspector.
There you'll find the wrapping container you can target with css like this:
input::-webkit-textfield-decoration-container {
display: none; /* or whatever styling you want */
}
Inside you will find the password keychain and the caps-lock indicator:
input::-webkit-caps-lock-indicator {
}
input::-webkit-credentials-auto-fill-button {
}
Oh, and while you're at it, don't forget IE with its clear buttons and password eye icons:
input::-ms-clear {
}
input::-ms-reveal {
}
Hide autofill Safari icon in input password field:
::-webkit-credentials-auto-fill-button {
visibility: hidden;
position: absolute;
right: 0;
}
Related: I wanted to adjust the position of the the key icon for a input[type="password"] but couldn't find the pseudo element selector anywhere.
So I cloned the webkit source and was able to find it :)
input::-webkit-credentials-auto-fill-button
As a note – check your field labels and any placeholder attribute values too – as these can also cause autocomplete popups to appear, despite CSS styling rules being applied to the contrary.
See below for more detail...
It should be noted that in Safari (version 11+ at least, and likely earlier versions too, and other recent browsers, e.g. Chrome, Firefox, etc), that even if the various CSS workarounds to hide the autocomplete popups are in place, if the field appears to be a username or password field to the browser, then the autocomplete field still appears.
I found that the browser is not only checking the <input> tag's name attribute for keywords such as username, login and similar variants, but also appears to consider the contents of any placeholder attribute text on the field, as well as most surprisingly, any text adjacent to the <input> field such as that used as a form field label. The label text does not need to be placed into a <label> tag to have this effect - just to be in close proximity to the field, although I haven't had opportunity to extensively test and determine what is considered 'close proximity' - this will require some further research and experimentation or where possible, review of the various web browser rendering engines' source code - such as for WebKit.
As such if you have keywords word such as username, user name, login or similar variants, as well as variants for password, the browser will show the autocomplete popup when the field is focussed, despite any CSS rules to try and hide it!
While I was not as surprised to see the popup being activated by the <input> tag's name or placeholder attribute values, I was surprised to see that label text was considered too by the browser, as such I had to change the wording and labelling of the fields to ensure the popups did not appear. I found for example modifying the placeholder text from 'Please enter your username...' to 'Please enter your user-name...' prevented the browser from recognizing the field as a username field – also notice the hyphen between the words user and name – without the hyphen between the words – the popup still appeared, so it shows how may edge cases the browsers are checking for. As a note, I had already modified the field's name attribute and the adjacent labelling by this stage to remove references to the triggering keywords or their variants.
It is clear that browsers are doing some interesting page inspection to determine if to show username/password popups - and while this is great overall behavior that helps encourage users to take advantage of password managers for more secure credential generation and storage, there are times when you don't want the autocomplete popup to appear. There are use-cases such as within an admin interface that allow administrators to manage staff user accounts for example - where you want to offer a field to search for a staff user by their username. In cases like this you don't want the autocomplete popup to try and fill the field with your own username, but rather allow you to enter any number of staff usernames for example. It would be great if one of the standard autocomplete='off' flags or a future variant could be adopted by the browser vendors to provide this clean control of the autocomplete behavior or a standard CSS attribute that if applied always had the intended effect... but alas this is not currently the case.
For now however, if you are dealing with this issue, make sure you are also considering the contents of any placeholder attribute you have added to any username or password <input> fields - as well as any label-like text that appears nearby. By adjusting and experimenting with the values of these labels/attributes you should be able to work around the page-inspection logic the browsers are using to enable these autocomplete popups.
As always with the web, and as some of browser's rendering engines are closed-source, this will likely continue to be more of an art than a science, until a standard is developed to provide control of this feature for all browsers on all platforms, and it may be necessary to occasionally revisit the code to check it against new browser versions to ensure that popups are not re-appearing due to changed page-inspection logic.
If you use <input> field without wrapping it in <form> tag, Safari 11+ or latest would show you auto-fill suggestion. So here is what you can do.
Option 1: Make sure <input> elements are wrapped inside <form> element. Don't set value of name attribute to "username" or "login".
Option 2: Add name attribute and set its value as "search". <input type="text" name="search">
Note: Using autocomplete="off" or autocomplete="false" on either <form> and <input> would not help.
Neither adding following CSS properties would work.
input::-webkit-autofill,
input::-webkit-contacts-auto-fill-button,
input::-webkit-credentials-auto-fill-button
Even with visibility:hidden or/and display:none Safari Ios keeps popping up icons and buttons. For me, the best solution was to set opacity to 0. This doesn't remove unwanted icons, but makes them completely transparent, and thus invisible. Furthermore, it works on whatever background color or img you're using.
input::-webkit-contacts-auto-fill-button {
opacity: 0;
}
The answers are all correct, however most of them are just curing the symptoms. Mostly, you just need to check your name attribute. In case you didn't give any name, name your input something. This helped in my case as without a name safari makes mistakes in recognizing autofillable inputs

Disabling a textarea and text input while maintaining a consistent cross browser style

I am looking to disable a few html controls and I am running into cross browser issues with the differences between IE and Firefox/Webkit browsers. The primary issue is evident with the following line:
<input type="text" name="badIE" disabled="disabled" style="color:blue;" value="IE won't show this correctly" />
In IE, the above input would have grey text, while the text is blue in every other browser I have tested. It would appear that IE allows the disabled field of a text input to take precedence over the CSS rules for the text color. Is there any established best practice or IE CSS hack to address this type of issue?
According to the upvoted (but not accepted) answer here, you're kind of stuck with using 'readonly'.
Just out of curiousity - why are you displaying text in a textarea that you don't even want your users to be able to focus on? Seems to me you'd be better off displaying that in a regular text HTML element (e.g. <p>).
It turns out that there are few different ways to attack this problem but there isn't one exact answer. In order to provide the most complete answer possible, here is a list of the possible solutions.
Accept the differences between browsers and continue using the disabled field. This is probably the right answer. As chipcullen suggested on his comment, there is rarely a necessity that all browsers look identical. It is better to simply accept the differences between and work with them.
Use the readonly attribute instead of disabled. The problem with this method is that a user can still interact with a readonly control. For example, users could focus on the control or stick a blinking cursor in the middle of the text. If interaction is a major concern, you can always shield the disabled control behind an invisible element, although that method is on the hacky side.
The option I chose was to replace the input elements with a pure text element. Although this method might not be as straightforward as it might sound. My page was interactive and certain elements would be enabled/disabled depending on client side actions. In order to handle the transition, I threw together the following Javascript (after chipcullen's suggestion and with the help of jQuery):
function disabledToSpan() {
$('input[type=text]:disabled, textarea:disabled').replaceWith(function () {
return $('<span>' + $(this).val() + '</span>').attr('class',
$(this).attr('class')).addClass('disabledTextInput');
});
}
In summary, this will find all disabled text inputs and textareas, switch them to spans while preserving both their values and classes, before finally adding a disabledTextInput class to specially stylize the disabled elements.

IE8 + IE9 HTML and CSS Focus

I'm working on an HTML page where we would like the input fields and select dropboxes to have a border around it as it is tabbed through and in focus. I've defined an input class within my CSS like so:
input.highlight:focus {
border: #003366;
border-style: solid;
border-width: 2px;
}
The input field is defined within my HTML file like so:
<input class="highlight" name="attorneyName" id="attorneyName" type="text" value="John Jackson" size="50" maxlength="30">
The focus seems to work fine in Chrome, but in IE the focus remains on one of my buttons no matter what I do. The button seems to steal the focus attribute and the page never focuses on any input fields, so the fields are never shown with a border around them while they are being tabbed through. What might be the cause of this problem?
From another thread, someone was able to point out that the :focus attribute is only recognized in IE9. This explains why the jsFiddle version works properly. When running the HTML file from my local drive, however, IE9 runs in compatibility mode for IE8 and lower and the :focus attribute is never recognized.
Have you tried to set the tab index attribute to the page elements. This property is supported by all major browsers. Supporting Browsers are : IE, safari,firefox,chrome.
" The button seems to steal the focus attribute and the page never focuses on any input fields, so the fields are never shown with a border around them while they are being tabbed through."
If i understand your question clearly then you have an issue while tabbing from one element to another right?. If that is the case the tab-index with increasing index value(or any order) will let you to select next elements while tabbing based on the tab-index set up, and the DOCTYPE Tag specifies the rules for the markup language, so that the browsers render the content correctly. Of course the changes in the Doctype tends to changes in the page. Have a quick look on w3 schools about doctype, Hope it may spot some light.
Cheers,
Arun

While hovering over a label, mouse pointer changes to hand

When I am hovering over an HTML label the mouse pointer changes to a hand image which we generally get when clicking a link. How can I avoid that?
The reason why you might get a hand cursor in some browsers, is because one of the main purposes of a label element in most browsers is to provide a clickable description for a form input element. For example, this is a typical use of the <label> element:
<input type="checkbox" name="TermAgreement" id="TermAgreement" />
<label for="TermAgreement">I agree to these terms</label>
In most browsers, this will result in the text "I agree to these terms" being clickable. When you click on the text, it will toggle the checkbox with an ID of TermAgreement, just as if you had clicked on the check box itself.
(Note: The W3C specification for <label> in HTML 5 doesn't require this behavior, but it does say that the browser's implementation of <label> "should match the platform's label behavior". In practice, this usually means <label> elements are clickable.)
So essentially, the cursor behaves as though the <label> is a link because it is a link, of a sort. If you're using it differently, you might want to consider using a different HTML element instead.
Whether or not a particular user sees a hand cursor when mousing over a label will vary depending on their OS and browser. Chrome and Firefox aren't displaying this behavior for me on Windows XP, but other platforms might. Also, it's possible that you have a CSS file included which specifically calls for this behavior. There would be a rule in your CSS that looks something like this:
label {
cursor: pointer;
}
If you want to override the element's default behavior, you can use cursor: default; in your CSS, as #rickyduck said. You can find information on the CSS cursor property here. Note that changing the cursor will not necessarily mean the element won't respond to being clicked.
If this doesn't solve your problem, please provide us with more information. Sample code, the URL of the page displaying the behavior, as well as which browser you're using would also be good to know.
<label style="cursor:default">Text<label>