I'm using the latest version of Chrome (74.0.3729.169) and noticed something slightly frustrating/interesting.
In the example below, begin typing an email address that you've used before. Once Chrome's suggestions appear, hover over one of them. Notice how dramatically the input shrinks.
input { padding: 5px; border: 1px solid #ccc; }
<input id="email" name="email" type="text" placeholder="Email">
I apologize if this doesn't recreate the behavior, however I've now been able to recreate it with this snippet across multiple computers, so I'm fairly confident this should work.
Additionally (to dip my toes into Meta a bit here) there's a fairly dramatic example of this on StackOverflow's very own login screen, in which the entire form shrinks as a result.
Compare the width of the two images below. Or, in the second image, compare the width of the "suggestion" with the input to which it corresponds.
From inspecting the input itself, I don't see any new styles that would explain this behavior. It doesn't seem related to padding either, as an input without padding still demonstrates this behavior.
My question is two-fold: Why does hovering a suggestion cause the input to shrink, and, is there a method/workaround to prevent this, other than fixed width or disabling suggestions entirely?
(I think that both of these workarounds are conditional. There are instances where you may not want to specify an input width for styling purposes, and disabling suggestions seems excessive and harmful to UX)
Or perhaps a Chromium bug ticket somewhere (I've searched with no luck - googling anything related to Chrome's autofill/autocomplete is a mess of unrelated articles about security)?
What you are facing is related to :-webkit-autofill pseudo class that is applying some default styling to the input with an autocomplete.
The :-webkit-autofill CSS pseudo-class matches when an element has its value autofilled by the browser.
Unnfortunately, I am not able to find where exactly those styles are defined but here is an example to confirm this. If you try to use the same value of width you will avoid the shrink effect:
:-webkit-autofill {
width: 173px;
}
<input id="email" name="email" type="text" placeholder="Email">
In the above link you can also read:
Note: The user agent style sheets of many browsers use !important in their :-webkit-autofill style declarations, making them non-overrideable by webpages without resorting to JavaScript hacks.
So even with !important you won't be able to override some styles:
:-webkit-autofill {
width: 173px;
background:red!important; /* will not work*/
border:2px solid blue;
margin-left:150px;
}
<input id="email" name="email" type="text" placeholder="Email">
For the width issue, I guess the only way is to define an explicit width as I have tried auto, initial, unset, etc and they aren't working.
If you cannot set a width and you want the default one, you can consider JS to do this:
document.querySelector('#email').style.width=document.querySelector('#email').offsetWidth+"px";
<input id="email" name="email" type="text" placeholder="Email">
Related
I have a simple textbox:
<input type="text" aria-label="First Name" title="First Name" />
I am showing the tooltip First Name on hover of textbox.
I used the aria-label as well as aria-labelledby but neither are working with Chrome or Firefox.
It's working on selection of the textbox, but not working on mouse hover.
But it's working fine with IE on mouse hover as well as on textbox select.
I am using the screen reader NVDA.
Its working on selection of textbox, but not working on mouse hover.
It's not intended to work on mouse hover.
NVDA reads the label for input elements on mouse hover, not the accessible name.
If you want something to be read, you have to add a label.
Just to avoid confusion the correct method for labelling an input is to simply use a <label>.
So you should have
<label for="firstName">First Name</label>
<input id="firstName" name="firstName" type="text"/>
The way to link labels and inputs is using the for attribute and point that at the input's ID.
The added benefit of this is that if you click on the label it will focus the corresponding input, which other solutions will not.
Should you for some reason require an input without a label then the following example illustrates how to do this correctly. (please do not do this if you can avoid it, labels are important for people with anxiety disorders to be able to check that they have filled in the correct field - however I know that sometimes 'designers' just won't budge and you have to workaround them....)
In this example we 'visually hide' the label using CSS and add placeholder text to the element. Just to reiterate this is a last resort for those designers who will not listen about accessibility and you should use visible labels.
At least doing it this way the input will function correctly for screen reader users.
.visually-hidden {
position: absolute !important;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
white-space: nowrap; /* added line */
}
<label for="firstName" class="visually-hidden">First Name</label>
<input id="firstName" name="firstName" placeholder="First Name" type="text"/>
Edit
Finally got chance to test this, works in Firefox, Internet Explorer and not in Chrome for announce on hover.
However if the label is visible it does work fine (if you hover the label, it does not announce if you hover the input itself even with a visible label), it also works fine for if you focus the input.
Final thoughts - show the labels (third time I said this in one answer. hehe), problem solved, no need to make it complicated.
Also, I am not sure why you think this is important, if someone uses a screen reader to assist while using a mouse they will click on an input, I have never come across anyone who would find not having a form field read on hover an accessibility issue if it works correctly once you click into the field.
Also the only people possibly affected by this are:-
screen reader users,
who use the mouse,
who have a sight impediment,
who use Google Chrome,
who also use NVDA,
and do not use a screen magnifier.
pretty specific, so not likely an issue.
I tested with NVDA on Firefox and Chrome and I can confirm the screen reader doesn't announce the value of aria-label on the input
I looked at 2.10 Practical Support: aria-label, aria-labelledby and aria-describedby and found out that aria-label isn't supported for input elements, but aria-labelledby and aria-describedby are. Taken from the link above:
aria-labelledby and aria-describedby are robustly supported for interactive content elements such as links and form controls including the many input types.
So I changed the code this snippet works with NVDA on Chrome and Firefox.
<input type="text" aria-labelledby="label" />
<span id="label">First Name</span>
Make sure to enclose the input and the "label" inside form for it to work optimally.
Sometimes you think you're going insane. This one of those times.
While working I had an issue that I couldn't change the font-size of a submit button. Then after going insane I boiled it down to this simple example:
https://jsfiddle.net/zf9sq2gx/
font-size: 100px;
I am sure this looks perfectly fine on your machine, but it does not on mine.
See:
I am working on a Mac here and this result is from Chrome.
- Firefox works as expected
- Other pages I made or visit online do work, however this basic example and the page I am working on right now, they exhibit this behavior.
It does not matter which number or unit of font size. Other values like padding are also ignored. WIDTH however is NOT ignored.
When changing the font-size in the chrome dev tools, the button flickers from its current font-size to a smaller one, but instantly jumps back. Even tho it should at least flicker to a big one in this case.
What if we change it to a different tag altogether? Now it works.
What if we just change the type from submit to text? It behaves as expected again.
What if we remove even the other tags like body and form and everything? Doesn't matter.
Updating meme. No change.
How could this possibly be a thing?
Not to mention that other pages may work with submit buttons. But I made this example in jsfiddle as simple as possible to go back to bare minimum, even using inline CSS (because !important did nothing).
Try to use
-webkit-appearance: none;
It will cancel default chrome styles for a button.
In addition to Petruk Dmitry's solution, you can solve this by setting -webkit-appearance: none, or by overwriting one of the vendor styles, if you don't want to add browser specific CSS. Appearantly, overwriting any of the vendor styles (see below for a list of tested styles) will remove the button styling completely. I've never had this problem before since I normally change the background and border when styling a button.
Examples:
<input type="submit" style="font-size: 60px;"><br />
<input type="submit" style="font-size: 60px; -webkit-appearance: none;" value="Webkit appearance"><br />
<input type="submit" style="font-size: 60px; background: blue;" value="background"><br />
<input type="submit" style="font-size: 60px; border: 1px solid green;" value="border">
EDIT: (some) More information on this behaviour can be found here, though it seems as if this "feature" isn't very well documented. For more reading on the subject however, you can check this page.
We have an application that has a text field with a specified length - 4.
Chrome:
Firefox:
Is there a way force Firefox / IE to use fixed-width spacing? This is an issue in the case of ID numbers, where the field is actually accepting the full input, but by default not displaying the full width (potentially causing user error if they are typing the field from the screen rather than copy/pasting).
Instead try changing size attribute to 5. So in all browsers, it will fit.
<input size="5" maxlength="4" value="WWWW" id="txt">
Try this CSS sector rule
#elementId
{
letter-spacing: 5px;
}
.elementClass
{
letter-spacing: 5px;
}
Instead of using size attribute try pure CSS. E.g. this
<input type="text" value="WWWW" id="txt">
#txt{
font-family: Courier New;
font-size: 15px;
width:40px;
}
should look about the same in all browsers.
HTML
<input size="4" maxlength="4" value="WWWW" id="txt">
CSS
#txt{
font-family: Courier New;
font-size: 15px;
}
DEMO
http://jsfiddle.net/pePXB/1/
It's a "combination" of some of the things suggested by others... I played around in jsfiddle with this for a bit using Internet Explorer, Firefox, and Chrome, and this combo seems to work the best for me, and provides consistent results across browsers.
I would recommend the following code
No matter which font family you use, It will make the textbox of specified character width.
HTML Code
<input size="4" maxlength="4" value="WWWW" id="txt">
CSS Code
#txt{
width:4em;
}
This will always make the textbox equal to the width of 4 "M"s so it gives you safe room to use any 4 characters in the box.
For more clarification on using various systems to set width, follow the following link.
http://www.webmasterworld.com/forum83/5001.htm
you don't need to worry about the code, but please check with fonts that you have listed for
TEXTBOX are available in both browsers ?
I believe this is what making the difference.
Try to set the width of the input element and just retain the values for size and maxlength attributes. It will have the same length all throughout the different kinds of browsers but still have different rendering.
input {
width: 50px;
padding: 5px;
}
make some little bit of css in your input text like
HTML
<input type="text" class="blabla">
CSS
.blabla{
width: 100px;
}
Dont forget to add px after you type size on your CSS.
Here's the pickle. To resize checkboxes in html, it is usually recommended that you utilize js to force the browser to resize the elements.
However, in our case, we are using wkhtmltopdf (a command line converter that utilizes webkit to create the html output that is then converted into PDF,) which to my knowledge, does not execute js.
In this context we still need to shrink down some checkboxes and radio buttons (actually, 'some' is wrong - a whole heck of a lot of them!)
What is a possible method for doing this, and if there is more than one, the best practice?
I know this is pretty old thread, but I had the same problem and did not find a proper answer anywhere so I wanted to help other people with similar problem. I was dealing with size of checkboxes in generated pdf by mdpf. Only thing that worked was font-size. Try something like:
<input type='checkbox' style='font-size: 20pt;'>
Hope this helps somebody.
Have you tried to set a print stylesheet to see if it affects the output?
#media print { /* css code */ }
Have you tried using CSS to change their size? This works fine in Chrome which is a webkit based browser.
input.big{
height: 2em;
width: 2em;
}
input.small{
height: 0.5em;
width: 0.5em;
}
<input type="checkbox" id="small" class="small"/><label for="small">Small</label>
<input type="checkbox" id="big" class="big"/><label for="big">Big</label>
http://jsfiddle.net/Q8AzW/
I'm designing a html page with strict doctype and there's a form element in my page.
What I want to do is to change background-color of inputbox when mouse touches my form. I've done this with css :hover selector on form tag, but problem is that IE only understands hover on "a" tag!
I've googled my problem and what I found is to:
using an htc file;
using javascript to create a hover class on elements;
creating a big "a" tag and put all elements inside it;
but I don't want to do any of these solutions!
Isn't there any better way to fix this problem in IE?
My HTML Code:
<form id="footer-search-form" title="Search" action="#action">
<fieldset>
<input type="text" class="footer-search-input" id="q" name="Search"></input>
<input type="button" class="footer-search-button" title="Search" value="Search"></input>
</fieldset>
</form>
My CSS Code:
#footer-search-form:hover .footer-search-button { background-color: #fff; }
#footer-search-form:hover .footer-search-input { background-color: #fff; }
Update: and after hours of searching I did it by using js:
onmouseover="this.setAttribute(document.all?'className':'class','footer-search-hovered');" onmouseout="this.removeAttribute(document.all?'className':'class','footer-search-hovered');"
and
.footer-search-hovered .footer-search-input, .footer-search-hovered .footer-search-button { background-color: #fff !important; } /* For IE6 compatibility */
I hate it, but it seems that there's no better way...
You're really only going to run into trouble if your users are using IE6. The majority of web developers nowadays don't even bother providing support for such an old browser, so I wouldn't worry about it.
IE has supported :hover on any element since IE8 (or even IE7? I don't remember), which has been released for over three years. Admittedly far too many people still use IE6 (mostly because IE doesn't have an auto-updater - it really needs one), but for something as simple as this aesthetic effect you really don't need to worry about support in old relics.