something very, very strange has happened.
Since a few hours, my Chrome (also IE) shows a different default outline on input.
Inspecting the code I saw that the outline set is as follows:
outline: -webkit-focus-ring-color auto 1px
and result is like this:
happens both incognito and in navigation with or without extensions.
how can I restore it ?
I think you can achieve it with something like this
*:focus {
outline: 1px solid aliceblue
}
so you can define for all of your elements which outline to render on focus.
a similar question can be found here
Chrome default focus outline
ps: although I think the new chrome outline is ugly as hell, don't forget that disabling it at all is a bad practice
http://www.outlinenone.com/
cheers
it's a new "feature" of chrome 83....(that afflict all S.O.) I hope will be removed soon.
https://support.google.com/chrome/thread/48974735?hl=en
The teams at Microsoft Edge and Google Chrome spent the last year
collaborating to retheme and improve the functionality of the built-in
form controls on Chromium browsers. ... The new focus indicator uses a
thick dark ring with a thin white outline, which should improve
visibility on both light and dark backgrounds. This is an easy
accessibility win that automatically improves the keyboarding
experience on a number of sites without developers needing to write
any new code. What's New in Chrome 83
You could easily totally remove or customize the focus outline for all or any element that you want like below:
*:focus {
outline: none; /* or customize it */
}
*:focus {
outline: none !important; /* or customize it */
}
You have to add "!important".
Related
I have an HTML element textarea with defined CSS rule { resize: both }. In FF when the user mouse over the right bottom corner of textarea the cursor changed according to value of property resize, but in Chrome cursor doesn't change.
Please open this example in FF and Chrome to check the difference.
Is it a bug of Google Chrome and can I fix it with CSS on my side?
Update
I reported bug to Chromium:
https://bugs.chromium.org/p/chromium/issues/detail?id=942017
Update 2
The bug was fixed in Chrome 80.
Actually, there are, or at least were ways in which you could style the resizer and add cursor: se-resize; on hover. Check out this post: Can I style the resize grabber of textarea?
It describes how you can use ::-webkit-resizer to style the resizer:
::-webkit-resizer {
border: 2px solid black;
background: red;
box-shadow: 0 0 5px 5px blue;
outline: 2px solid yellow;
}
Unfortunately it stopped working in Chrome and I couldn't anything similar. (I think it still works in Safari).
But fear not, it's not hard to make a custom handle. Actually, I would encourage you to use a custom one as the default one is too small and hard to hit. Especially with touch. There are actually a lot of sites that use custom handles (or at least automatic resizers based which grows based on the content. Works great on touch too!).
Ie. Stackoverflow uses a custom handle (TextAreaResizer):
GIF of Stackoverflows resize handle
There are also lots of libraries for exactly that purpose, just do a Google search, and you'll find something that works for you :)
This is rendered by browser itself cant be designed using css
I'm creating a form, that is following some WCAG guidelines. One of those is:
G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over.
The summary of this rule is:
Operating systems have a native indication of focus, which is available in many user agents. The default rendering of the focus indicator isn't always highly visible and may even be difficult to see against certain backgrounds. However, many platforms allow the user to customize the rendering of this focus indicator. Assistive technology can also change the appearance of the native focus indicator. If you use the native focus indicator, any system-wide settings for its visibility will carry over to the Web page. If you draw your own focus indicator, for example by coloring sections of the page in response to user action, these settings will not carry over, and AT will not usually be able to find your focus indicator.
(emphasis mine)
In order to comply with this rule, I want to keep the OS' default focus indicator for form elements.
However, I'm facing different problems here.
In Firefox on macOS:
As soon as the I change the style of the element (e.g. by changing the border settings), the default focus gets lost1.
This is strange as border and outline are different style attributes.
In Firefox and Edge on Windows:
The browsers show a focus indicator that is only a differently colored border, when entering a form element – as long as it's unstyled. Chrome on the other hand does have an indicator as an outline – like on macOS2.
Here's a snippet to demonstrate the behaviour (alternatively try this fiddle):
.b {
border: 1px solid red;
}
<form>
<input class="a" type="text">
<input class="b" type="text">
</form>
As a sidenote: There is no difference in the behaviour if label-elements are present or not.
My questions are:
Why does Firefox and Edge react like that on macOS and Widnows? Why do they use the border instead of the outline of the document?
How can I force these browsers to show the OS's default focus indicators even when custom styles are applied?
When somebody has created a customized indicator, will it still be shown in Firefox and Edge, even though the default one isn't anymore?
With these issues, I wonder whether this rule is even possible to achieve. In the end maybe I must manually set outline on focus to get the same behaviour in all browsers and skip this rule.
1 Here's a screenshot showing the problem on macOS:
2 Here's a screenshot showing the problem on Windows:
This is not a programmatic answer, but how to comply with the guidelines. The key here is that G165 is a "technique", not a guideline.
The relevant guideline is actually WCAG 2.4.7 (Focus Visible). There are several different techniques that you could use to meet this guideline. In this case G149, G165 and G195 are the most relevant techniques for a web page.
So where am I getting this information? Starting from the given link:
G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over.
Under "Applicability" there's a link to "How to Meet 2.4.7" and you can see several "Sufficient techniques" that you can choose from that will meet the guideline. In this case since G165 and G149 don't work consistently across browsers, you probably want "G195: Using an author-supplied, highly visible focus indicator".
The WCAG documents are confusing at first, but it gets a lot easier when you step back and look how they're arranged. They set it up so there's a quick reference you start on, and it links to the other documents when you need to read more.
Diagram from WCAG 2 Documents
I spend all day looking at How to Meet WCAG 2.1 - it is intended as a customizable quick-reference, so you can filter which guidelines it shows (e.g. compliance level A+AA or whatever), which techniques to show based on technologies you're using, and a lot of other stuff. Open the sidebar and switch to the filter tab there and you'll see what I mean. Bookmark it once you've got it customized.
From that document, I can look at the available techniques and click to read up on them, and there's a link to the relevant section of the "Understanding" document that I can read to get a better understanding of what the guideline is all about.
Also for techniques, you'll probably notice they all start with a letter or a few letters. G is "general" (use on any technology), and the rest correspond to the "Technologies" in the Filter section. I turn off or ignore any SL (Silverlight), FLASH (Flash), SMIL (Smil) and PDF techniques since they're not relevant.
As you've notced already, appearance and behaviour of form elements are implementation-based and differs from browser to browser.
Every form element has its browser-default appearance -- a set of styles such as border, background etc.
When you're trying to change default styles, browser may override them rule-by-rule (as Chrome does) or discard the default appearance at all (as Firefox does).
So if you want to have the same appearance in "all" browsers you have to set it explicitly.
E.g.:
.b {
border: 1px solid red;
-moz-appearance: none;
-webkit-appearance: none;
}
.b:focus {
outline: none;
box-shadow: 0 0 2px 2px lime
}
<input class="a" type="text">
<input class="b" type="text">
Read more here.
The CSS outline property does exist and you can use it like this:
.b {
border: 1px solid red;
-moz-appearance: none;
-webkit-appearance: none;
}
input:focus {
outline: 2px solid #2772DB;
}
<input class="a" type="text">
<input class="b" type="text">
If its not working or showing up, that may mean there is another style overlapping it so you can override it by adding !important
Each browser has its own properties. As I searched you should code like below:
input.b {
border: 1px solid #f00;
-webkit-appearance: none;
-moz-appearance: none;
}
input.b:focus {
outline: none;
box-shadow: 0 0 1px 1px #0a0;
}
If you wanna read more about this concept, See MDN Docs to understand.
Hope, my answer helps you.
This is a learning exercise for me, so thanks in advance for not telling me why I don't want to do to the following. I don't want to do, I want to understand.
Given the following CSS:
input[type="file"]:focus,
input[type="radio"]:focus,
input[type="checkbox"]:focus {
outline: thin dotted;
outline: 5px auto -webkit-focus-ring-color;
outline-offset: -2px;
}
input[type="checkbox"]:focus {
outline: none;
}
The specificity for both shows as 0,2,1, and everything I read about CSS says the second style should override the first as it comes last. If I get more specific about the second style, it wins. But as posted, Chrome doesn't display the outline, but IE11 and FF28 do. This seems to me to be such a fundamentally simple application of CSS. Does anyone have any insight into what the underlying issue is, so that I can pull it into my thinking as I'm developing stylesheets?
EDIT: Chrome also doesn't display the outline if I delete the second style. In Chrome, the outline: thin dotted are overridden by the following outline line. So it appears that per the spec, Chrome is playing by the book and FF and IE don't? Could it be a union vs. override difference in how browsers interpret CSS?
With apologies, the error was mine. When I switched from bootstrap.min.css to bootstrap.less, I didn't remove the former from loading so it was loaded last and overrode my Site.less -> site.css. I figured it out after I tried to create a fiddle, which I should have done in the first place. Feel free to down-mod this post to hell in the way that it deserves.
I have a list of checkboxes with labels and I am noticing that the spacing looks different in Firefox in comparison to IE.
I have applied the CSS below to try and remove all spacing.
border: 0 none;
margin: 0;
outline: medium none;
padding: 0;
Unfortunately, as you can see from the screen shots below, there still seems to be some extra space between the Firefox checkbox and label.
Firefox:
Internet Explorer
Why does Firefox still show space between the checkbox and label but Internet Explorer has none using the same CSS?
In short, the reason as to why you're seeing this is that such details aren't defined as a standard anywhere, and come down to the 'user-agent stylesheet' - a set of default styles that are applied by the specific browser.
It's something that frustrates plenty of designers/developers, and has led to the development of some kinds of CSS Reset stylesheets. One of the best (in my opinion) is normalize.css, which aims to provide consistent and sensible defaults, smoothing over cross-browser inconsistencies like the one you've described.
Does anybody know how to remove the dotted outline on buttons in Opera?
I have done it.
Here you go: http://jsbin.com/oniva4. [tested on Opera 10.5/11]
The secret is using outline-offset:-2px; (effectively covering the dots) and the background's color for the outline. outline-offset is supported since version 9.5.
The introduction of the article Do not lose your focus
For many web designers, accessibility conjures up images of blind users with screenreaders, and the difficulties in making sites accessible to this particular audience. Of course, accessibility covers a wide range of situations that go beyond the extreme example of screenreader users. And while it’s true that making a complex site accessible can often be a daunting prospect, there are also many small things that don’t take anything more than a bit of judicious planning, are very easy to test (without having to buy expensive assistive technology), and can make all the difference to certain user groups.
In this short article we’ll focus on keyboard accessibility and how careless use of CSS can potentially make your sites completely unusable.
And the list of test given by the article on outline management.
Update 2011-02-08
I can confirm that it is not possible for now. There is an open bug for it.
I say this with the clear proviso that you shouldn't remove the outline unless you replace it with something else that indicates focus state ...
If you apply a transform to the element, it kills the outline in opera; it doesn't even need to do a visible transform, merely applying the property is enough. So this will do the job:
#myButton:focus
{
-o-transform:rotate(0);
}
But I can't promise that wouldn't be considered a rendering bug, and consequently something that may change in the future.
I believe the problem lies in where you specify the outline properties. Try this:
*:focus, *:active {
outline: none; (or possibly outline: 0)
}
I researched this more and it looks like on input fields and buttons it will not work unless you edit the browser's config, like Firefox's about:config page. It seems to be done for accessibility reasons so that a keyboard can be used to fill out and send a form without using a mouse.
I used that trick above for my text area and worked fine! Using a Text Area with an id "itens", here it goes!
#itens:focus, #itens:active{
outline: 1px solid white;
outline-offset: -2px;
}
So, you can play with that:
#itens:focus, #itens:active{
outline: 1px solid lime;
outline-offset: -2px;
}
Are you looking for:
button{
outline:none;
}
or if your button is an input...
input[type=button]{
outline:none;
}
Just read this forum post on the opera website
http://my-beta.opera.com/community/forums/topic.dml?id=712402
There seems to be no fix for it
Further to my tip above -- with experience I've found that it doesn't always work, and isn't always appropriate anyway, since it can change the way the element is rendered in subtle and sometimes unpleasant ways.
So, if that doesn't work, another thing you can do which often does, is to specify the outline color as "rgba(0,0,0,0)"
if you attached css-reset in your stylesheet should solve the issue.
Remove outline for anchor tag
a {outline : none;}
Remove outline from image link
a img {outline : none;}
Remove border from image link
img {border : 0;}
This is less of an answer, and more of an explanation as to what seems to be going on:
The story
My reason for removing opera's outline was to add an outline of my own. To add an outline I used:
:focus{
outline:1px dotted #999;
outline-offset:-3px;
}
This works perfectly fine in every other browser... except Opera. Opera instead gives you this weird interference pattern, which looks like a dotted-dashed outline:
now if you remove your outline, you still have the standard outline that Opera provides, a nice simple 1px spaced dotted line:
Since I have no way of adding a style to every browser except Opera, I instead decided on removing Opera's outline before adding my own. Using brothercake's solution, -o-transform:rotate(0); to do this and then applying my own outline:
Voila!
An Explanation?
From what I can tell, Opera adds it's own secondary outline on top of any outline defined by CSS.
This secondary outline seems to have an independent color, width, style, and offset.
Color is the opposite of the background,
Width is 1px,
Style is dotted,
and the offset is 2px smaller than the border.
sorry there is no style image, the upload didn't work correctly
one interesting thing is that the dotted style of the Opera outline is not the same as the CSS outline's dotted, otherwise there would be no interference pattern with both:
Conclusion:
As I stated above, I am using brothercake's solution which is to nullify the opera border with:
-o-transform:rotate(0);
As he mentioned in his later comment this 'fix' does have some issues as it is a rendering bug:
I have noticed that when returning window or tab focus to the page containing the button, if the button previously had focus, the Opera outline will reappears until the button loses focus or is hovered over.
better:
outline: solid 0;
for all web browsers