How to style button inputs to be identical in Chrome and Firefox? - css

Take a look at this JSFiddle example in Chrome and FireFox.
In Chrome, the button should be a tad smaller than in FireFox. I have added the solution CSS from How to reset default button style in Firefox 4 + (which made the button a little smaller) but the button is still bigger in FireFox. The difference isn't very visible in this example, but have a look at how it affects my design.
Chrome:
FireFox:
As you can see the button is thicker in FireFox and is affecting the layout. Is there any way of avoiding this short of using styled divs in place of buttons?
Also, I'm using Meyer's CSS reset stylesheet

Firefox adds a special padding to inputs and button elements. This takes care of it:
button::-moz-focus-inner,
input[type="button"]::-moz-focus-inner,
input[type="submit"]::-moz-focus-inner,
input[type="reset"]::-moz-focus-inner {
padding: 0 !important;
border: 0 none !important;
}

I have concluded that the only way of ensuring that button/submit inputs remain identical across browsers is to recreate them using divs. Creating button inputs is easy since you can attach click events onto divs the same way as on buttons. Creating submit inputs is barely any harder. I solved it using jQuery by declaring a class, for instance 'submit', and adding the submit button functionality to all elements that have that class on load. Here's an exampe:
// On page load:
$('.submit').on('click', function(e) {
$(this).closest('form').submit();
});
Divs with the submit class that are not in a form will do nothing when clicked.
If you add tabindex="n" (where n is a number) to the element, it can also be focused using tab, just like a normal button. You can also style it to show that it's focused by using the :focus css pseudo-class. Then you could use space or enter to click the button with this event handler:
$('.submit').on('keypress', function(e) {
if (e.keyCode == 13 || e.keyCode == 32)
$(this).closest('form').submit();
});
(I wrote that last snippet in a hurry and haven't actually tested it. If you find an error in it or test it successfully please edit this answer accordingly.)

Have you by any chance set a line-height on the buttons on your page? You haven't on the fiddle, but line-height's other than normal, aren't accepted on firefox, and some other browser I believe - maybe IE, I'm not sure.

Have you tried a CSS reset? I dont have FF on this computer or else I would check if this works.
<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/3.5.1/build/cssreset/cssreset-min.css">

Related

Google Chrome showing black border on focus state for button user agent styles

Recently i was working on a web design project, and noticed something odd, after the last Google Chrome update. The default border style(user agent style) for button is changed, and which is looking visually annoying to me.
Is there any method to modify/restore the default browser styles, i.e., user agent styles permanently?
here are some images of the problem:
i have also checked other websites and even google
also checked the dev tool, found this border styles applied on the focus state of the button
This is because the new chrome update
https://developers.google.com/web/updates/2020/05/nic83#forms
you can override black outline in most cases by
*,*:focus,*:hover{
outline:none;
}
and you can see this article
https://web.dev/style-focus/#use-:focus-visible-to-selectively-show-a-focus-indicator
if you want to remove outline just for mouse user.
You could try disabling this flag: chrome://flags/#form-controls-refresh 
Apparently the 83+ version of chrome changed how forms are rendered / handled:
https://blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html
Here is a relevent Google Support page which links to the blog post above:
https://support.google.com/chrome/thread/48974735?hl=en
The issue isn't Chromium's new contrasting focus ring, it's the default behavior across browsers that clicking triggers the focus ring.
The focus ring appears on click when the <button> appearance is altered or receives tabindex attribute.
Accessibility is a must and the new contrasting black and white focus ring is a great step forward. However there are developers (including me) that don't want the focus ring to be present when using the mouse.
Solutions
:focus-visible css pseudo selector. Supported on all modern browsers MDN Browser Compatibility
/*
This will hide the focus indicator if the element receives focus via the mouse,
but it will still show up on keyboard focus.
*/
button:focus:not(:focus-visible) {
outline: none;
}
focus-visible polyfill
/*
This will hide the focus indicator if the element receives focus via the mouse,
but it will still show up on keyboard focus.
*/
.js-focus-visible :focus:not(.focus-visible) {
outline: none;
}
if you're using a framework that overrides classes, use the focus visible attributes.
[data-js-focus-visible] :focus:not([data-focus-visible-added]) {
outline: none;
}
Keep in mind that for mobile users, if there's an element that triggers the soft keyboard to pop up, such as <input type="text">, it should have visual indication that it is focused.
There are 2 way to handle it.
configuration in chrome which few has suggested.
Programmatically approach outline: 0px transparent !important; in style Or outline: none !important; Both have worked for me.
Since we can't force user to do configuration, I would suggest for second Option but it is long process If you have any shorter way tell us.
This solved it for me:
chrome://flags/#form-controls-refresh
And disable this: screenshot
settings in chrome > Appearance > Show a quick highlight on the focused object.
Disable this option.
Go to chrome desktop browser
settings->Advanced->Accessibility->(Turn off)Show a quick highlight on the focused object
to avoid the shadow boxes when u click on your browser

User Agent Style shows as being overridden, but when the page renders, it's not

I am trying to hide the autofill style for a password input field that comes in via the user-agent-styles.
When inspecting the element, the computed styles show that the color coming from the user-agent-style is being overridden and #fff is being applied, but the actual computed style is still the one coming from the user-agent.
Any idea on how to get rid of this?
Here is the CSS I am using to try and override it:
.password {
border-right: none;
background-color: #fff !important;
}
#MainContent_txtPassword:-webkit-autofill, input:-internal-autofill-
previewed, input:-internal-autofill-selected, textarea:-internal-autofill-
previewed, textarea:-internal-autofill-selected, select:-internal-autofill-
previewed, select:-internal-autofill-selected {
background-color: white !important;
}
I found an answer that works for me! See https://webagility.com/posts/the-ultimate-list-of-hacks-for-chromes-forced-yellow-background-on-autocompleted-inputs
I had initially come across https://css-tricks.com/snippets/css/change-autocomplete-styles-webkit-browsers/ but that only works for opaque backgrounds, and not transparent ones. The webagility article includes a nice hack for transparent backgrounds too.
To summarise both the articles, the solution I applied is:
input:-webkit-autofill,
input:-webkit-autofill:hover,
input:-webkit-autofill:focus,
textarea:-webkit-autofill,
textarea:-webkit-autofill:hover,
textarea:-webkit-autofill:focus,
select:-webkit-autofill,
select:-webkit-autofill:hover,
select:-webkit-autofill:focus {
-webkit-transition-delay: 99999s;
}
The reason this works is because chrome applies autocomplete styles via a css transition. If you delay all transitions on that input, the styles will never be applied.
This behaviour is seen in Chrome only (it is not in Firefox, I didn't test Edge or others). Chrome applies a pale yellow background (#E8F0FE) and black text to all autofilled inputs. This user agent style for autofilled text has hard-coded priority in Chrome's rendering since Chrome version 74. This behaviour is intended by the Chrome developers.
In Chrome, these hard-coded styles will override anything you can set yourself in the document or via Javascript. In the original question, Style Inspector shows the OP's background-color: white !important style as having precedence over the user agent style input:-internal-autofill-selected. Style Inspector is wrong to show that: it looks like it does not know that the user agent style for autofilled text has hard-coded priority.
I replicated the OP's issue in a (codepen). Note that I even tried to update the input:-internal-autofill-selected user-agent style in the document's own CSS, with the !important suffix. Even with that in the CSS, Chrome still uses the original, hard-coded user-agent style. This codepen also shows you that none of the following methods will be effective to override the user agent style in Chrome.
use CSS with greater specificity
add style to the element in HTML
use an event in Javascript to change the element's style properties (for example backgroundColor) after data is entered
This has been reported to Chrome as a bug. The developers' response is WontFix, citing a security concern. Chrome devs don't say what the security concern is, but I guess it is that a malicious site could create HTML with hidden input boxes (no border, and background and foreground colours matching the page background) and gather some auto-filled data without the user's knowledge.
This "WontFix" attitude is not a great solution. It annoys designers who want to control the appearance of input boxes. The OP wants a pure white background and Chrome changes it to #E8F0FE which is maybe not a big deal, but it's way worse for designers who want to use a dark background. How hard would it be for Chrome to check programmatically that the page has styled the input box with high enough contrast to be visible to the user? Chrome has also not fully solved the security concern, because a malicious site can hide an input box in some other way: it could be outside the visible screen area, or covered by a different page element.
I had a similar problem attempting to style a select option element's background colour when :checked.
I'm using pseudo elements to add checkboxes to a select element where multiple selections are allowed and didn't want to whole row showing as being selected.
I found that changing to another colour had no effect over the User Agent Stylesheet (Chrome) but using a gradient as the background did.
option:checked {
background: linear-gradient(0, #fff, #fff);
}

Hover effect if button is not disabled?

I have the following CSS rule:
button.medium.fade-btn:hover:not([disabled]) {
color:red;
}
And HTML code:
<button class="medium fade-btn" disabled></button>
I need that hover effect works only when button is not disabled.
You haven't structured your selector properly
button.medium.fade-btn:hover:not([disabled])
In theory selects nothing, but is searching the children of button (which there are none) due to you putting it after the hover.
button.medium.fade-btn:not([disabled]):hover
Is the correct way.
Hover is the event so you want that happening on the not disabled button so it comes after everything else. Select the element and then use the hover as the last part. It may be easier to work with disabled: true/false as well.
Edit: This is either a browser compatibility problem, or your browser isn't liking just using disabled in the type selector. You should try using disabled=true in your selector and checking your browser version against the versions that :not() is supported in.

Differentiate between :focus via tab-key and :focus via click in CSS

Although I am quite certain that the answer to my question will be "Can't be done" I'd like to be sure and ask you guys here.
I have a rather typical scenario in which I want to enable tabbing through my website (i.e. using tab key on keyboard). The item the user has just tabbed upon should be marked visually via CSS. So far, so good. This, obviously, demands the focus-pseudo class:
a {
color: #000;
&:hover {
color: lighten(#000, 10%); // discreet change
}
&:focus {
background-color: green; // extreme change
}
}
But I want to apply this style solely when the user tabs through the page. When the user hovers or clicks an element the style should be something different.
Example: A user hovers or clicks an anchor. Then the visual aid can be discreet because the user already knows which element he has interacted upon. But when he tabs through the page he can not be so sure and thus the styling should be more drastic.
The problem I am having is: An element gets the focus-styles applied on on both tabbing the page and clicking on it.
Is there a CSS-only way to apply styles solely when an element got focused via tabbing?
Again, I am pretty sure that this is not possible, but just to be sure I have asked the question.
There's a new CSS selector :focus-visible that is intended to solve this scenario by targeting only the elements that were focused via keyboard input.
This is only supported natively in Firefox today, however there is a polyfill that makes this possible in all browsers through a .focus-visible class name.
The :focus pseudo-class does not discriminate based on how the element entered focus in the first place. So indeed, this is not possible with just CSS. At the very least you'd need to annotate the element on focus via an event handler.
The :hover and :active pseudo-classes won't be of any help here since the former only applies when the mouse pointer is on the element and the latter only applies when the mouse button is down, i.e. neither state persists the way :focus does, since an element remains in focus even after the mouse pointer has left the element, making it indistinguishable from an element that received focus via tabbing.
Just so to list this as an alternative answer (which I also chose, tbh):
One can also work with javascript to disable the mousedown-event. This event is not really that useful, the click-event still works and it prevents the clicked element from getting the focus-state. This, in turn, makes using the :focus property in CSS useful again as it now only triggers when the user navigates that element via tab key.
I didn't have any luck with pure CSS so I wrote a simple fiddle:
var allowTabFocus = false;
$(window).on('keydown', function(e) {
console.log(e);
$('*').removeClass('tab-focus');
if(e.keyCode === 9) {
allowTabFocus = true;
}
});
$('*').on('focus', function() {
if(allowTabFocus) {
$(this).addClass('tab-focus');
}
});
$(window).on('mousedown', function() {
$('*').removeClass('tab-focus');
allowTabFocus = false;
})

IE8 CSS selector selects, but does not apply the style

Debugging experience http://www.dmhermitage.org/wtfborders.pngThis is making me want to kill myself.
I have some really simple CSS to style my input objects:
input, button
{
border: 1px solid #c66600;
background-color: white;
color: #7d212f;
font-family: "Eras Light ITC", Tahoma, sans;
}
But I don't like the ugly border it puts around radio buttons, so I use a selector to kill the border:
input[type=radio] { border: none; }
You can probably guess what browsers this works in and which ONE it does not work in. What's funny is when I press F12 to launch the excellent developer tools in IE8 it actually tells me that the style of the radio buttons has been overridden to 'none' just like I asked it to do, but the border remains on the radio button objects.
I have tried a variety of semantic things, like setting the border width to 0px or the color to something insane like lime green, but it remains the originally assigned color that it got from the first style.
And finally, I have tried only styling 'text' objects, in which case no style is applied to anything. Again, the browser claims to fulfill the CSS selection, but it visually does not happen.
Thoughts?
By the way, this is a DotNetNuke installation with generated code where I can't explicitly set the style of the radio buttons.
Thanks,
Dan
IE8 appears to be rendering in quirks mode instead of standards mode, which always messes everything up in IE. To switch to standards mode, the easiest way is to replace the doctype on the first line of the document with this:
<!DOCTYPE HTML>
You may also want to look at some of the HTML being output. You have a span with ID dnn_dnnMENU_ctldnnMENU that contains dozens of made-up attributes like BackColor, SysImgPath, MenuItemHeightand so on. These will have no effect in most browsers (maybe IE interprets them specially, I dunno).
problem is...
Being most helpful ever, please notice, that somehow, your page get's rendered in quirks mode, thus in some screwed way nobody should ever use.
solution [edit]
due to: http://dorward.me.uk/www/ie8/
set your html 4 doctype to:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
Just in case, have you tried with:
input[type='radio'] { border: none; }
Notice the addition of the apostrophe (or whatever you call the ' in your funny language :P)
I looked at the site, your CSS is correct and there is nothing I can help you with. Good luck!
You can remove the border by setting an inline style attribute in the developer toolbar to border: none;... So for some reason the style isn't applied to the radio-button although the style is traced correctly. Seems like some sort of bug.. Have you tried jacking up the specificity of the rule (it should already be higher than input, but just to try it out)?
For instance:
#page input[type=radio] {
border: none;
}
It's not possible with CSS anymore (as far as I know), but using this Javascript here it will be possible for you; Styling checkboxes and radio buttons with CSS and Javascript.
Nasty. Try specifying the border colour to white?

Resources