On a website I'm developing, I'm using mix-blend-mode:difference to give an interesting effect when some elements are positioned over other elements. I noticed recently that in webkit browsers, on my Macbook Pro display, the color of the div with mix-blend-mode:difference on it is much darker than it should be, in some specific scenarios.
See my codepen: https://codepen.io/matt_o_tron_5000/pen/LYxPaLm
HTML:
<div class="background">
<div class="plain-color"></div>
<div class="blend-color"></div>
</div>
CSS:
.background {
background-color: #fff;
}
.plain-color,
.blend-color {
width: 200px;
height: 200px;
}
.plain-color {
background-color: #04f;
}
.blend-color {
background-color: #fb0;
mix-blend-mode: difference;
}
In the codepen, one div is using a normal hex color code as the background color, and the other div is using the exact opposite hex code as the background color, with mix-blend-mode:difference applied.
On my external monitor, these two divs are the exact same color (and yes this monitor is reliably color-accurate). But if I move the window to my Macbook Pro display, suddenly the mix-blend-mode div is much darker than the other.
Additionally, when testing in Firefox, the color of the 2 divs match exactly no matter which display I view them on. Only in Safari and Chrome does the div look unexpectedly dark on my Macbook monitor.
I assume this has something to do with the fact that Safari and Chrome use webkit while Firefox uses a different engine (gecko), but... Why the difference between monitors? I am confusion.
Photo examples:
2 divs in Chrome on external display:
2 divs in Chrome on Macbook display:
Related
In the code below, I would prefer to never see any of the red background. But sometimes, in some browsers, and at some zoom levels, the red background gives the appearance of an inner 'border' along the bottom, and in some variations right, sides of the parent div.
The real-world situation I started from is of course more complicated, but this simple example illustrates the problem.
I've fiddled with CSS flex and grid, and many of the various settings which sound like they might address this problem, but I haven't found any reliable solution.
I can reproduce in Chrome on Mac and Windows, and on Edge on Windows. But I can't reproduce at all on Safari on Mac. I haven't tried on Firefox yet. Remember to experiment with many zoom levels. The problem is not reproducible at all zoom levels.
.outer {
background-color: red;
border: solid 1px black;
display: grid;
grid-auto-flow: column;
}
.inner {
background-color: grey;
}
<div class="outer">
<div class="inner">seeing</div>
<div class="inner">red</div>
</div>
View on CodePen
The design of the site I'm working on calls for underlines squished right along the bottom of the text, literally touching the baseline. I'm absolute positioning an after pseudo element with a border-bottom to accomplish this, and I'm seeing a strange inconsistency between the box height in Mac Chrome and PC Chrome.
Notice the "Visit" link in the top right corner. This screenshot is Mac Chrome and it's how it is supposed to look. The dev tools claim the box height of the <a> tag is 30px.
Look what's happening for the same site in PC Chrome. As you can see, there's a small gap below the text and the underline because PC Chrome thinks that same exact element has a box height of 22px.
The CSS for the underline:
a {
position: relative;
&::after {
content: '';
position: absolute;
top: 1em;
width: 100%;
left: 0;
border-bottom: 4px solid;
}
}
As you can see, the 1em that positions the underline lands in a different place on the two different OS's.
What's going on here!?
Here's a round-up of things I've checked:
I exported the woff/woff2 files using FontSquirrel with the "Match X-Height" option turned on to "100%"
Both browsers have the zoom set to 100%
The calculated font-size of the element is 22px on both.
The calculated line-height of the element is 22px on both.
Both elements have box-sizing: content-box.
If the box model is truly the issue, you can set the box-sizing attribute on your a tag and ::after element to force consistent rendering of the box-model, then adjust your variables as necessary.
box-sizing: border-box
Goal: static images with animations shown on :hover that do not exceed container width.
Fixed code:
/* wrapper paragraph*/
.rimg {
text-align: center;
overflow: hidden;
}
/* rely on contents for vertical size, show backgrund centered */
.rimg-gif, .rimg-png {
display: block;
position: relative;
background-size: auto 100%;
background-position: center;
background-repeat: no-repeat;
line-height: 0;
}
/* containers need max-width in IE */
.rimg img, .rimg-gif, .rimg-png {
margin: 0;
max-width: 99.99999%; /* Opera Mini ignores anything above this % */
max-width: calc(100% - 0px); /* for proper browsers */
}
/* hide the GIF background unless hovered */
.rimg-gif:not(:hover) {
background-image: none !important;
}
/* hide the static image when hovered */
.rimg-gif:hover img {
opacity: 0;
}
<p class="rimg">
<span class="rimg-png" style="background-image:url(https://i.imgur.com/iwczbln.png)">
<a class="rimg-gif" target="_blank" href="https://i.imgur.com/TLxp2di.gif" style="background-image:url(https://i.imgur.com/TLxp2di.gif)">
<img src="https://i.imgur.com/iwczbln.png">
</a>
</span>
Description
</p>
Final structure:
.rimg is just a container element for center-aligning things.
img is the static image (for semantics, printing, and default display). It is hidden via opacity when hovering, which allows to use the context menu to both get URL of GIF ("link") and static PNG ("image address").
.rimg-gif is the animated background GIF that is displayed when hovering (while hiding the static image). It is not loaded until hover. Doubles as a link to the actual GIF (for mobile users)
.rimg-png has a static background and is there solely so that the reader doesn't see the image briefly flashing before the GIF finishes loading the first frame.
There were a few issues with this:
In IE<=11 (non-Edge) sizing to fit width just outright doesn't work - the elements overflow the container instead.
Adding "max-width: 100%" to nested blocks fixed this (by this explanation).
Opera Mini similarly doesn't resize the images to fit container width, but aforementioned fixes for IE have no effect.
I was not able to find any explanations of this, but turns out that Opera Mini simply ignores max-width values roughly equal to 100% (>99.99999%). So I added that for Opera, and max-width: calc(100% - 0px) for modern browsers.
On StackOverflow's snippet preview, calculated height is slightly higher than that of image, which can be seen by it briefly starting to repeat on the bottom. The issue disappears by giving line-height: 0 to .rgif-alt but I'm not sure if that's a hack or not.
Edit: apparently so? Other options include float'ing the elements and using position: absolute, so I guess line-height is pretty alright for elements
Additional details:
HTML is generated from a markdown[-ish] extension so it does not strictly matter if it looks nasty or not. I would like to avoid having image dimensions / aspect ratio hardcoded into generated HTML if possible, though.
Trying to not have the animated GIF load until requested (mouseover), therefore a two-image trick is not preferable.
The intent to avoid JS is due to fact that pages with such elements can be shown inside an embedded browser with JS disabled completely. As you can imagine, having a popup window (or a default browser' tab) open for each animation is undesirable.
If anything is unclear, do tell.
After a bit of trial and error I managed to resolve the issues by myself, so I added notes on solutions and the final (working) code to the question.
I'm not 100% happy with opening a new tab on Android (ideally should play when single-tapping), but all tested browsers close such popup-tabs when pressing Back so maybe it's not too bad. I added a "play" button, which also doubles as a first touch event absorber for mobile (initially covers the link completely, resized to 0% width after a short delay to allow clicking the link). This works both for modern browsers (which trigger :hover and animation playback on first tap and can open link on second tap) and for Opera Mini (which simply opens a popup tab with the GIF). You can see this in action here, for example.
So this morning I got an automatic update to IE 11, after checking my eyes it appears that some of my background images are blurry.
I had to check that it was not my image causing the problem, so after firing up Chrome, they were nice and crisp again...
I am completely baffled.
I've now uninstalled the IE11 update and they are once again nice and crisp in IE10... Has anyone else encountered this?
I've included a screen shot showing the images in the different browsers.
Here is a link to a jsfiddle, I don't have IE11 any longer to test but its the same markup and CSS that I am using: http://jsfiddle.net/3g52E/
Well i can see what is causing this problem. It's the border-radius of your ._ui.
Now i can't tell you why this happens. However if you want to fix this you can or don't use border-radius or, which is a better solution i my opinion, use the <img> tag to generate the background.
Use image element
<img src="http://i.imgur.com/DauuVHW.png" />
Now to cut-off your image you can just use position: relative;, position: absolute; and a overflow: hidden;:
.block1 > div
{
position: relative;
overflow: hidden;
}
This will add the properties on ._ui _bre and ._ui _com.
Where the basic image properties are:
img
{
position: absolute;
left: 2px;
}
Now you can just use the top and bottom offset for the the image positioning. Where as you used background-position before:
._bre._ui img
{
top: -68px;
}
._com._ui img
{
top: -24px;
}
This way your image is not a part of the element which has border-radius anymore, which caused this problem. They have a more clear seperation now; 2 different elements.
jsFiddle
There is probably more elegant way to fix blurry images in IE 11.
In our app we have icons on buttons with round corners. Removing round corners or using <img> for icons were not options.
However, what worked for us was "classic" images optimization for retina displays, i.e. saving button background images with twice larger resolution and then specifying original size in background-size.
Looks great in IE 11 and on retina displays.
According to this:How to write a CSS hack for IE 11?
I added this code to my CSS:
#media all and (-ms-high-contrast:none){
*::-ms-backdrop, .my_elements_with_border_radius { border-radius: 0 }
}
With this browser hack the borders are not round anymore in IE11 but at least the background images are not blurry anymore. In any other browsers they are still round.
I'm developing a website. Everything looks great on 100% zoom but when I'm zooming in or out in chrome and IE (not Firefox) the style changes and div blocks move! I have a container div with a background and some div blocks on it. Everything should be in exact position and it is important in my site.
You can see in picture how it makes my style look so bad.
I tried to use percentage instead of pixel for sizing and positioning of all elements in the page but its not working.
My CSS:
.container{
width: 880px;
background-image: url('b80.png');
}
.picture{
margin-left:13px;
margin-top:11px;
}
I too faced the same problem, when I tested in a different screen size.
Try position: relative or display: inline-block for .picture. This may solve the issue.