What determines the pixel depth of Chrome/Mac outline focus ring style? - css

I have a bit of a bug where some members in my team see focus styles differently on the same element. They are running Chrome 86 on Mac. I am running Chrome 79.
When this specific element is focused, I see the basic focus ring I am used to, the blue glow at a depth of 5px
My colleagues however see a very narrow 2px border around the focused element.
The code for the element is:
<button>
<img ... />
</button>
The image inside the button has overflow:hidden applied in order to give the appearance of a centre crop.
Here is a snippet
button {
display: inline-flex;
width: 100px;
height: 100px;
align-items: center;
overflow: hidden;
position: relative;
margin-right: 8px;
margin-top: 8px;
border: 0;
cursor: pointer;
}
img {
margin: 0 auto;
width: auto;
height: auto;
min-width: 100%;
min-height: 100%;
position: absolute;
right: 50%;
top: 50%;
transform: translate(50%, -50%);
}
<button>
<img src="https://picsum.photos/id/1062/100/50">
</button>
I'm trying to understand what the cause of the change in user agent stylesheet settings is and why it would cause this difference.
The focus style I see:
outline: -webkit-focus-ring-color auto 5px;
My colleagues see:
outline: -webkit-focus-ring-color auto 2px;
However, this isn't universal on their browsers. They see the 5px on other elements.
I don't really want to start adding new focus styles as I'd prefer to honour the browser's own settings in case the user has specified a focus style that works for them.
My main questions
What causes the browser to choose the thickness of the focus ring?
Could the overflow:hidden on the image inside be the cause of this bug?
Why don't I see the issue on Chrome 79?

What causes the browser to choose the thickness of the focus ring?
The browser's built-in stylesheet ("user-agent styles"). This is liable to change with every major browser update - it's also platform-specific (e.g. Chrome 86 on Mac will render things differently to Chrome 86 on Windows 10) - so you must not depend on any particular user-agent stylesheet rules for your webpage to render correctly.
Could the overflow:hidden on the image inside be the cause of this bug?
I doubt it.
Why don't I see the issue on Chrome 79?
Because Chrome changed their user-agent styles for :focus and :focus-visible in Chrome 86.

Chromium was updated earlier this year with a fresh look.
You can read about the design updates here. This is one (of many factors) that can account for different user agent stylesheets.
However be aware that just because you see one thing, your colleagues see another that those are the only options.
My focus ring is only 1px and black, so that gives you an idea of how varied styles are (Chrome 86.0.4240.111 on Windows).
Accessibility
The more important part of your question is the part where you don't want to "interfere" with the browser default styles.
I don't really want to start adding new focus styles as I'd prefer to honour the browser's own settings in case the user has specified a focus style that works for them.
This just doesn't work in the real world. What if your website has a blue background? (Yes I am aware browsers are becoming smarter at accounting for this but in accessibility we need to support all the way back to IE8!). Also what if you have a complex widget that changes colour?
Style focus so that it is appropriate for the website, you want a contrast ratio of at least 3:1 on surrounding items. For really complex sites you may need a different focus ring colour depending on the background location to maintain this contrast ratio.
Style your focus rings!
#Dai made a valid point that this section was not very clear initially.
When I say to "style your focus rings" I mean to make them more usable and prominent than browser defaults.
Consider where they are placed on the page (their surroundings) to ensure sufficient colour contrast (as mentioned earlier 3:1 minimum with surroundings) and make sure they are clearly visible (they are called visible focus indicators for a reason).
As #Dai said, don't use this as an opportunity to try and flex your creative muscles, 20px wide magenta focus rings are not needed (and possibly might not be accessible). Keep them simple and consistent across the site.
Above all remember that focus indicators are there for accessibility.
I tend to advocate for an outline of 2px and an outline offset of 2px to ensure it is visible as the slight bit of white space around the item makes it easier to see.
button {
display: inline-flex;
width: 100px;
height: 100px;
align-items: center;
overflow: hidden;
position: relative;
margin-right: 8px;
margin-top: 8px;
border: 0;
cursor: pointer;
}
img {
margin: 0 auto;
width: auto;
height: auto;
min-width: 100%;
min-height: 100%;
position: absolute;
right: 50%;
top: 50%;
transform: translate(50%, -50%);
}
.better:focus{
outline: 2px solid #333;
outline-offset: 2px;
}
<h2>no image standard button</h2>
<button>
button with text
</button>
<h2>standard</h2>
<button>
<img src="https://picsum.photos/id/1062/100/50">
</button>
<h2>better</h2>
<button class="better">
<img src="https://picsum.photos/id/1062/100/50">
</button>
Oh and :focus-visible will be great when it gets traction but at the moment it doesn't have very good support so make sure you polyfill it if you use it.

The outline on focus if it is not set in CSS is actualy decided by the browser settings.
Here you can see already differents behave from a browser to another on windows and Mac. So I would not be surprise that this settings are changing from a version to another.

Related

Mix-blend-mode ignored after zoom [Safari]

Setup & Goal
I am trying to apply a texture to all the content on my page. The aim is to make the site look like a piece of printed paper.
In order to achieve that, I am using an absolutely positioned div with the same dimensions as my content. It has an image as background and user-interaction is disabled. I use the mix-blend-mode: multiply to apply the texture to everything behind.
The set up looks something like this; however I was unable to reproduce the issue in the snippet editor:
.main-content {
position:relative;
width: 500px;
height: 500px;
background-color:lightblue;
border: solid 10px red;
}
.texture {
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
margin: -10px;
mix-blend-mode: multiply;
user-select: none;
pointer-events: none;
background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABkAAAAZCAYAAADE6YVjAAAABGdBTUEAALGPC/xhBQAAACBjSFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAaGVYSWZNTQAqAAAACAAEAQYAAwAAAAEAAgAAARIAAwAAAAEAAQAAASgAAwAAAAEAAgAAh2kABAAAAAEAAAA+AAAAAAADoAEAAwAAAAEAAQAAoAIABAAAAAEAAAAZoAMABAAAAAEAAAAZAAAAANoMEmUAAALiaVRYdFhNTDpjb20uYWRvYmUueG1wAAAAAAA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA2LjAuMCI+CiAgIDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnRpZmY9Imh0dHA6Ly9ucy5hZG9iZS5jb20vdGlmZi8xLjAvIgogICAgICAgICAgICB4bWxuczpleGlmPSJodHRwOi8vbnMuYWRvYmUuY29tL2V4aWYvMS4wLyI+CiAgICAgICAgIDx0aWZmOkNvbXByZXNzaW9uPjE8L3RpZmY6Q29tcHJlc3Npb24+CiAgICAgICAgIDx0aWZmOlJlc29sdXRpb25Vbml0PjI8L3RpZmY6UmVzb2x1dGlvblVuaXQ+CiAgICAgICAgIDx0aWZmOk9yaWVudGF0aW9uPjE8L3RpZmY6T3JpZW50YXRpb24+CiAgICAgICAgIDx0aWZmOlBob3RvbWV0cmljSW50ZXJwcmV0YXRpb24+MjwvdGlmZjpQaG90b21ldHJpY0ludGVycHJldGF0aW9uPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MjU8L2V4aWY6UGl4ZWxYRGltZW5zaW9uPgogICAgICAgICA8ZXhpZjpDb2xvclNwYWNlPjE8L2V4aWY6Q29sb3JTcGFjZT4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjI1PC9leGlmOlBpeGVsWURpbWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+Ch9KojkAAAN+SURBVEgNTdVpctswDAVgipGX2E6cNLn/ofqnPUXGS7wvKj626JgzNEXg4eEBpOTu18/fQ9d15fv7u1ifnp7KZDJpczwel+PxWC6XS+n7vtRayzAMZRtYvtVmXebzedntdg2zWCwa5nw+F+Pj46PF19vtVvb7feGQYDQaNSLPyK1fX19ls9mU6XTacBJJfr1eW/KXl5cigVhCcBr3+72cTqfSU/E4gKhUFTLDKgApMfaESWSqJquW4Pn5uSXjg++RIM42IZcdqRZ5RkIlQRJJDZdkh8PhfzvFGMglxF0ZBZgSIRf0qDTBKjARwOfZeU4MPm1mw9XsTVkE2iAHoBqRRCpZrVatLbPZ7G/bAuMMLqdzOe4PpYvSrudLOez2pZauLGbzMtzuzQdTJTGQy6w1EugxW6rKnsNowT1EaZ+WfX5+NpHi8KkC3lRZZdAm6pVv5XSlDYrf398biT2/6VB/hH0Cu92WG/LwX0OYdRTk0+DbBU8vgBoKXVGZJdM6NiJyr4LcexZnL6FBrErstXYbydvBZxLqnQsAcqDWlng2kOVlgH17e2v4fAUIZHcxnCEu3K+vr6WXHQGjnhoteygVpIoMkMSzGKvzYkuhbNRLzO4llbQCZACDhGzaJomqBPHZs7tx6/W6CbA3+PDAijHh8PVU59XVIioNK5DqMkhLEGVF8HkuYvIcVS+5tnluV1h2ZBySakNWR8lyuWz2x7bC+1B2gZ/Ftb/EgZ/CNg7STEyoM65+BMuoTalcIsoFaJVnSvmNUbQHSd4iHK47nmtU2zDBpwvVBomNICQC7A2rtpmeW7WBU+l4GpdiiE9HzHjjyj2+akO8JHg2cQGIxl0ZTMoRZUIHSZkvQPr5KDUlMXVCrOSqtsJJwGdUBiRWRk7/HarJM+JDaDWyWqszhG2V/WthcqbolgRQzyXwLFhrKExCvkzKrsI8Bz5X2tsuXqWEZrU1774knIa3WRKKEDhcayqElQRh4ogx8MGyZ6L2MgJTmV9kJFkJm3bCPCpNbH5IxajMdAvhVSxpRWZyphoKOO19JpStSuodLh9MElEuCbxzkNi75+vt8rRKgCRBAogEiFq+rFTb0g5LsQ6wmRLAaivh/HgrRdRR6nZxegagDolKBOdgg2FDLkZrrLDOlN/np7U4b0C2ipMj9wJzOhtfVpXC5PuTAqhGDM+X5/wHWO18ZrEZ4QIAAAAASUVORK5CYII=')
}
<div class="main-content">
Lorem Ipsum
<div class="texture"></div>
</div>
Issues
This works fine on initial load in all browsers where mix-blend-mode is enabled. https://caniuse.com/mdn-css_properties_mix-blend-mode
Issues arise however in:
Safari (OSX)
Safari (iOS)
Whenever the zoom functionality of the browser is used, either through pinch or automatically through activation of an input field, the Browser seems to "forget" that the mix-blend-mode property is set on the element and shows it fully opaque in front of all content.
Zooming back out does not solve the issue.
Disabling and re-enabling the mix-blend-mode property manually through the developer tools does solve the issue.
Is this a known bug in Safari? Are there any known workarounds for this issue?

Why does this website show a menu of different width in different browsers?

Link
The problem is in the jQuery Mega menu. It somehow displays correctly on Google Chrome Linux and Internet Explorer (Windows 8), but incorrectly on Opera (Linux), Google Chrome (Windows), Firefox (windows), etc. If it is displayed incorrectly, last menu when hovered overlays with search input. What could be the issue here? I do not want to change the paddings.
The difference is most likely due to browsers interpreting decimal pixel numbers differently. Each menu item doesn't have explicit width set via CSS so it gets fraction of pixels that are respected in some and gets rounded in some. Now, that only makes 1px difference per element but that eventually add up to 10px, 20px, and more.
So the solution would be to give enough room between menu item and the search bar, maybe make it narrower.
This might help you understand the issue in detail:
Are the decimal places in a CSS width respected?
Dont Know is it right method or not
You have some code in your CSS file on line no 2025
#searchform {
position: absolute;
top: 79px;
left: 744px;
width: auto;
height: auto;
margin: 0px;
display: table-cell;
}
edit the left property value to 764px from 744px;
and on line no 3416
#searchform .text_input {
width:149px;
height: 9px;
padding: 10px;
position: relative;
top: -1px;
vertical-align: middle;
font: 11px Arial,sans-serif;
}
Remove the width property from this chunk of code

Rounded Corners on jQuery Slider Only Working in Firefox

Rounded corners on my jQuery sliders only work in Firefox.
Renders correctly in Firefox 17.0.1 (see image below)
Not rendering correctly in Safari Version 6.0.2 (8536.26.17) (see image below)
Not rendering correctly in Chrome Version 23.0.1271.101 (see image below)
Here is the jsfiddle build: http://jsfiddle.net/plasticmonument/TCVH5/1/ (note, I only gave full path url's to the slider images, everything else will be missing)
My HTML:
enter code here
My CSS:
.hero-wrapper {
position: relative;
z-index: 2;
float: left;
width: 100%;
height: 429px;
border-radius: 10px;
border-top-left-radius: 0;
-webkit-border-radius: 10px;
-webkit-border-top-left-radius: 0;
-webkit-border-bottom-right-radius: 10px;
-moz-border-radius: 10px;
-moz-border-top-left-radius: 0;
-o-border-radius: 10px;
-o-border-top-left-radius: 0;
-ms-border-radius: 10px;
-ms-border-top-left-radius: 0;
overflow: hidden
}
#feature-slider ul.slider {
position: absolute;
top: 0;
left: 0;
width: 900000px
}
My guess is that it's the old "foreground images aren't clipped" bug.
In some browsers, a border radius may be applied, but foreground images of the elements with border-radius aren't restrained by the radius.
I was under the impression that this was something that had been dealt with by the major browsers, but it's not something I've looked into for a while, so I may be mistaken in that. It certainly looks like it's what you're seeing. I remember it was quite a big issue back in the days of Firefox 3.x, but if I recall correctly, the FF team sorted it out somewhere between v4 and v8.
To prove it, add an actual border (eg border:solid black 2px;) to the element, and see what happens. If the border disappears under the image at the corners as it follows the radius, then this is the bug you're seeing.
If this is the problem, then the solutions are:
Use a background image instead; this won't be clipped.
Add an additional layer of markup -- eg a <div> with the existing <img> inside it, and put the border radius on the <div> instead of the <img>.
Ignore it, and wait for browser vendors to fix the issue.

Why is Chrome suddenly having an issue with background-image on hyperlink tags?

OK, so I have this website I maintain, uses WordPress, etc. One of the things the blog has is a little flag/ribbon thing in the upper-right corner that has three logos for the site's associated Twitter, Facebook and RSS feeds.
I want it to be an all-CSS hyperlink so I'm doing the HTML this way:
<div id="headerflag">
<a class="headerflagfacebook" href="http://www.facebook.com/(client's facebook link)"></a>
<a class="headerflagtwitter" href="http://twitter.com/(client's twitter link)"></a>
<a class="headerflagrss" href="http://feeds2.feedburner.com/(client's rss link)"></a>
</div>
and the CSS looks something like this
#headerflag
{
width: 151px;
height: 40px;
position: relative;
left: 708px;
top: 20px;
z-index: 3;
background-image:url('images/flag.png');
}
a.headerflagfacebook, a.headerflagfacebook:hover
{
width: 13px;
height: 26px;
position: absolute;
left: 36px;
top: 7px;
z-index: 4;
background-image:url('images/flag-facebook.png');
display: block;
}
(repeat for the other two with slightly different positioning offsets, image names, etc.)
And until very recently, it worked everywhere just fine, even in the WebKit-based Safari.
But now it's broken in Chrome:
The hovering works:
But the non-hover state is broken. I'm not completely sure, but I think the background image is being used again (that might explain the little triangles that disappear on hover - they're from the triangular notch on the right?).
I'd say this is a bug but I'm not sure and it still renders this way even in the Canary build.
Does anyone know why this suddenly broke in Chrome? Is it a bug? Or am I doing something wrong?
You should be using sprites.
Take a look at this tutorial. http://iamchristill.com/html/the-right-way-to-make-rollover-buttons/
Works across browsers.

Scrolling element contents without javascript

Dear all, is there a way to scroll, as in relatively shift the contents of, an element without using javascript, and only using CSS?
If that matters, the element in question has overflow:hidden and white-space: nowrap to make it 'hide' some parts of its content. The element is normally scrollable with javascript, but needs to be properly shifted upon initial rendering (and without further interactive scrolling, of course) in case javascript is disabled.
No, there is no way to scroll items on a page (unless it's an iframe with the hash portion of the url included, in which case the browser will control the initial positioning of the scroll, not css or html) using only CSS and HTML.
No. Not with CSS directly.
You could simulate it, by wrapping the contents with a div and giving it a margin-top value for the amount of scrolling you want.
(remember to remove it/set it to 0 with javascript when it is enabled)
update
A cool idea is what Jamie, mentions in his answer, if it fits your requirements.
update 2
Here is another solution i created out of Jamie's idea, that needs no frames.
Put an anchor <a name="anchor_name">..</a> at the place you want the scrolling to be and use a
<meta http-equiv="refresh" content="2;url=#anchor_name_here">
to auto-scroll there. (the meta element should go in the head though for (x)html conformance)
example at http://www.jsfiddle.net/gaby/f3CVY/5/
works great in all browsers i tested it (IE, Chrome, FF, Opera, Safari)
There is also another method - which is quite hacky - but it works without a reload.
The solution I've created works in the following browsers:
Firefox 4+
Safari 5+
Chrome 6+
Opera 11+
IE 10+
Android 2.3+
It's really a bit hacky, so see whether you would use it or not. :)
A little explanation
I used the HTML5 attribute autofocs on an <input>-field. As this will focus the input, it has to get it into the viewport. Therefor it will scroll to the given position. To get rid of the highlighted outline and to not see the input at all, you have to set some styles. But this still forced Safari to have one blinking pixel, so I did the trick with the span, that acts like an overlay. Note that you can't simply use display: none as this won't trigger the autofocus (only tested this in Safari).
Demo
Try before buy
The demo will run in Safari and Chrome only. IE and Firefox seem to not fire autofocus in an <iframe>.
CSS
div.outer {
height: 100px;
width: 100px;
overflow: auto;
}
div.inner {
position: relative;
height: 500px;
width: 500px;
}
div.inner > input {
width: 1px;
height:1px;
position: absolute;
z-index: 0;
top: 300px;
left: 200px;
border:0;
outline:0;
}
div.inner > span {
width: 1px;
height:1px;
position: absolute;
z-index: 1;
top: 300px;
left: 200px;
background: white;
}
HTML
<div class="outer">
<div class="inner">
<input type="text" autofocus></input>
<span></span>
</div>
</div>

Resources