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?
Related
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.
I'm working on generating report that contains a map. I use Mapbox for this purpose. I came across an issue with one of the tiles leaking out to the second page in print preview (tested in Chrome). I've spent most part of the day trying to tackle the issue. I seem to have figured out the root cause. Map tiles are placed on the element that is positioned using transform: translate3d. I've put together a simple example that demonstrates the issue.
html {
-webkit-print-color-adjust: exact;
}
.container {
width: 500px;
height: 800px;
border: 1px solid blue;
position: relative;
overflow: hidden;
}
.tile {
width: 500px;
height: 800px;
transform: translate3d(-100px, 300px, 0px);
background-color: green;
}
.another-block {
width: 500px;
height: 400px;
border: 1px solid red;
}
<div class="container">
<div class="tile"></div>
</div>
<div class="another-block"></div>
If you load it in Chrome (or PhantomJS) and open Print Preview (in Chrome of course) you will notice that green rectangle leaks into the second page.
However, if you change negative left offset (-100px) to positive, the problem goes away.
Any idea on how to fix this? There is an option to fetch the exact map region as an image which will require rebuilding a big part of the system as opposed to using Mapbox out of the box. So before going there I'd like to ask if anybody has solved similar issues before.
UPDATE:
#page {margin: 0} (suggested in the answer) didn't help. Here're the screenshots:
Without margin: 0
With margin: 0
You may be looking for #page { margin: 0 }
Before:
After:
However, for finer control, you could play with #media: print to get those reports nice and polished :)
Good luck!
Edit:
As you mentioned, the layout is Landscape. Portrait does "bleed" over the pages, like:
However, you can control the elements and when they break by using CSS like page-break-before or page-break-after. You then get something like this:
Portrait
Landscape
These have page-break-after applied to .another-block, with #page { margin: 0}
When you scroll with the mouse wheel in Windows 8 the fixed background image bounces around like crazy. This only affects IE 10 and IE 11. This affects elements with position:fixed as well.
Here is an example with a fixed background-image:
http://www.catcubed.com/test/bg-img-fixed.html
Here is example code:
#section{
position: fixed;
top:0;
left:0;
background-color:#eee;
background-position: top left;
background-image: url("images/7.png");
background-size: auto;
background-repeat: no-repeat;
z-index: 10;
}
Is there a solution to keep the background still in IE 10 and 11?
I know it is a bit late for an answer but I've had the same problem and was able to fix it by adding these attributes to my css file
html{
overflow: hidden;
height: 100%;
}
body{
overflow: auto;
height: 100%;
}
From the comments:
This solution stops scroll events from firing on the window, so do be careful if you're using anything that relies on such events firing. codepen.io/anon/pen/VawZEV?editors=1111 ( overflow: hidden, scroll events don't work) codepen.io/anon/pen/PNoYXY?editors=1111 ( overflow: auto, scroll events fire) - Dan Abrey
So this might cause some problems in your projects. But I don't see another way to workaround this bug in IE.
This looks like a z-index bug, try adding z-index: 1.
Looking into this, I've found the best way to debug is to:
Create a simple element at the top of the page, e.g.
<style>#test {position: fixed; background: red; top: 0; left: 0; width: 4em}</style>
<div id="test">Test</div>
In all the above cases, this works correctly, and the scroll is smooth. So this proves it can be done! Now slowly add your properties back in, until you are able to get the element with position fixed to work in the context of your site.
I then found that adding a z-index to the fixed items resolved the issue. (e.g. z-index: 1)
I also discovered that once a position is set on a child element, the bug presents it's self from that point down/onwards.
So you need to ensure none of the child elements have a position set,
or if they do, you explicitly set a position on each child.
E.g.
<!-- Works -->
<div style="position: fixed;">
<div>Nice</div>
<div>Wicked</div>
<div>Cool</div>
</div>
<!-- Element with position: relative, experiences the bug -->
<div style="position: fixed;">
<div style="position: relative;">sad</div>
<div>sad</div>
<div style="position: fixed;">happy</div>
</div>
It's fixable, but will require some tweaking!
Here is a workaround (tested on Windows 8.1):
Move the "background" CSS property to the BODY element. Currently it is on the DIV element with id="filler". Here is the resulting CSS:
body {
font-family: Helvetica, Arial, sans-serif;
background: #fff url(blue-kitty.jpg) no-repeat fixed center 100px;
}
#filler {
text-align: center;
}
.big-margin {
margin-top: 500px;
}
try to turn off smooth scrolling option.
Internet Options - Advenced Tab - Use Smooth Scrolling
it's like rendering bug.... MS IE team is investigating....
just simply define body container to relative.
<style>
body
{
position: relative;
}
</style>
The fix in my case was to simply remove the z-index property from the element that has position:fixed, IE then stopped the strange flickering.
(disabling smooth scrolling on IE options worked while having he z-index property but that's not a solution since users would most likely have it on by default).
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.
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>