So I have a simple flash message on our site, which should have fixed positioning in the bottom left. On mobile, I've also added a width of 100% to make it look a little nicer, with a small amount of padding to offset it from the edges.
The container for these flash messages is in the root of the body:
#FlashMessages-Container {
position: fixed;
bottom: 0;
left: 0;
max-width: 550px;
padding: 32px;
z-index: 11;
#include media-down(large) {
max-width: 57%;
}
#include media-down(medium) {
max-width: 100%;
padding: 16px;
}
}
This works great on desktop on all browsers, and also works great on mobile Android/Firefox, iOS/Safari and even iOS/Chrome. However, it doesn't work on Android Chrome, which doesn't calculate the width correctly. You can see from this DevTools screenshot, it's making the flash messages 376px wide when the screen "width" is only 360px (device pixels, that is), so there is no gap on the right side.
If I make the position absolute, the width is correct but then it's not fixed.
Here is the offending Android/Chrome view:
The related dev tools styles:
And here is Android/Firefox which looks fine:
Here's iOS/Firefox too:
And finally, even iOS/Chrome which strangely works fine unlike its Android cousin.
Related
I'm trying to debug a CSS-only slideshow on my Android phone. The slideshow works fine in Firefox for Android but doesn't work properly in Chrome, Brave or Samsung Internet. My phone is a Samsung A5 (2017) and my laptop is running Windows 10.
When I connect my phone to my laptop and look at the Chrome browser from my phone in Chrome Devtools via USB Debugging, I'm noticing some odd things in the CSS as rendered on the phone. The source code of the SaSS has the max-width of an element called #slideshow hard-coded as 410px:
#slideshow {
max-width: 410px;
display: block;
margin-left: auto;
margin-right: auto;
}
The precompiled CSS file is identical. However, when I look at the same block of code in Chrome on the phone, max-width is 407px, even though I uploaded it and was careful to ensure that it did upload successfully. I was also careful to reload the page in Chrome (for Android).
#slideshow {
max-width: 407px;
display: block;
margin-left: auto;
margin-right: auto; }
I even deleted the css file on the server and re-uploaded it from my laptop but the max-width still shows up as 407px. This is part of the problem because each of the images in the slideshow has a width of 408px; the max-width of #slideshow has to be greater than or equal to 408px.
But that's not the end of the weirdness. Now we get to the SaSS (mis-)calculations. I have a variable called $number_of_slides which I set to 12. Then I calculate two things. For #slides .inner, I calculate a width as 100% times the number of slides:
#slides .inner {
#debug 100 * $number_of_slides;
width: 100% * $number_of_slides;
line-height: 0
}
With $number_of_slides set to 12, the width for #slides .inner should obviously be 1200% and that's exactly what the css file shows:
#slides .inner {
width: 1200%;
line-height: 0; }
The precompiler also shows a value of 1200% from the #debug statement.
But when I look at the CSS that's been rendered on the phone via Chrome DevTools, the width for #slides .inner shows a width of 1100%!
#slides .inner {
width: 1100%;
line-height: 0; }
The other calculation that uses $number_of_slides is this one:
#slides article {
#debug 100 / $number_of_slides;
width: 100% / $number_of_slides;
float: left
}
The CSS file shows that the precompiler has done the right thing:
#slides article {
width: 8.3333333333%;
float: left; }
The #debug statement confirms that the width is being correctly calculated as 8.333333333% by the precompiler.
However, when I look at that same selector in the CSS on the phone, I get this:
#slides article {
width: 9.0909090909%;
float: left; }
I am completely baffled. I can't think of any mechanism that would explain this odd behaviour. A hard-coded value and two calculated values are DIFFERENT between Chrome on my phone and Chrome on my laptop for no obvious reason even though there is just a single version of the file being used by both browsers.
When I manually edit the CSS file on my phone, the slideshow renders much better in Chrome although not yet perfectly, so there are probably additional alterations to the CSS file that I haven't noticed yet.
Can anyone suggest WHY the CSS file on my phone is different from the CSS file on my laptop? If I can keep it from changing, perhaps I can solve the whole problem in one go.
I'm using a current version of FileZilla to do my uploads.
It's some kind of magic, really. I didn't see anything similar before. So only on Opera Mobile (the latest ver) on the Android device (any), I get a strange white offset while some of the nodes cross the body content width (i.e. became beyond the visible layout). Of course, I don't need any such content, as well as such a white offset.
So I tried to set overflow: hidden as a solution on the parent node(body). Unfortunately, it exactly doesn't work with Opera Mobile (again, the white offset around the page became visible and scrollable).
Exampe of the real code:
#parent_body {
overflow-x: hidden;
overflow-y: scroll;
position: relative;
}
#child_tooltip {
z-index: 99999;
display: table;
}
#tooltip_content {
position: absolute;
z-index: 50;
left: 430px;
top: 175px;
}
Does anyone face such an issue previously? I'll appreciate a lot any help!
Thanks in advance.
Example of such "white offset" around the page:
I have a website that requires a 'bottom right' background image alignment, along with a background colour of #000.
My css tests okay on all OS and browsers I've tried so far (chrome, ie, moz, safari) except for chrome on android, which renders the background image outside the browser window.
Other image alignments work fine - the problem seems to be only with bottom right alignment, and only with chrome on android.
Problem page url: Features a background-image: bottom right alignment
CSS as follows:
body {
box-sizing: border-box;
margin: 0;
padding: 0;
font-size: 1em;
background: url("../images/bg_prices_XL.jpg");
background-size: contain;
background-color: #000;
background-repeat: no-repeat;
background-position: bottom right;
background-attachment: fixed;
}
If I change alignment to background-image: top right; then the problem goes away.
Page renders properly on android moz. Do I therefore need to include a -webkit specific alignment?
Havd tried adding:
html,body {
height 100%;
width 100%;
}
...but no luck. Viewport size already set to device size, Chrome seemingly is rendering oitside the viewport anyway, below the footer.
Tried styling the background-image under html section of css, but didn't work.
All thoughts welcome.
I have inspected the page throught chrome dev tools. I think if you remove background-attachment: fixed; propery it will work.
...never mind folks. I made the background a fixed, 100% height and width div, with a negative z-index. It feels like a clunky workaround to me, but it seems to work. Any better suggestions though would be appreciated thank you.
I'm trying to create a scrolling effect for a background using CSS3 animations, such as:
body {
background: url("bg.jpg") repeat-y 0 0;
animation: animatedBackground 50s linear infinite;
}
#keyframes animatedBackground {
from { background-position: 0 0; }
to { background-position: 0 100%; }
}
(JSFiddle)
This works great, except that it's very laggy on mobile devices (e.g. Android Chrome 43.0)). I've tried various hacks that are suppose to force the browser to use the GPU, which sadly didn't help.
One solution is to use translateY and duplicate the image, like shown here. That doesn't feel very good however, since the image is pretty big to start with. It does run smooth, though.
I'm looking for alternate solutions on how to make this run smooth.
The reason that transform runs smoothly while background-position does not is that transform can utilize the phone's hardware acceleration while background-position must rely on the browser software's re-rendering of the element. Even if it's a large image, using hardware acceleration is always better for mobile.
If it's the same image, any browser worth it's salt isn't going to incur any extra impact by using it twice, as it's cached after the first pull.
So use the transform solution, and feel confident it's the right one.
Inspired by the link in the OP, I found a way to achieve this without having multiple references to the same image. It does, however, require you to know the image's height.
The general idea is to have a relative wrapper which hides all overflow, and force the image to be 200% its height, and make it repeat and finally animate the y-axis -100%. Example:
#parallax-wrapper {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
overflow: hidden;
}
#parallax-background {
position: relative;
width: 100%;
height: #parallax-image-height * 2;
background: url("/bundles/sunnerbergsimilarseries/images/tv-show-wall.jpg") repeat 0 0;
animation: animatedBackground 50s linear infinite;
transform: translate3d(0, 0, 0);
}
#keyframes animatedBackground {
0% { transform: translateY(0) }
100% { transform: translateY(-#parallax-image-height) }
}
(JSFiddle)
The above runs as smooth on a 2015 Android-phone as on a computer with a dedicated graphics card.
In the default Android Browser for older Android versions (4.1, maybe 4.2/4.3 [It is on the Android device of a customer, i'm not exactly sure which version he uses]) SVG sprites are not rendered correctly.
Instead of showing the correct clipping with the correct size, the browser shows a smaller version of the image, showing the whole sprite, like in the screenshot below (Android Browser 4.1):
Android screenshot (false rendering)
it should look like this:
Android screenshot (correct rendering)
Here's the CSS for the sprites:
.sprite {
display: inline-block;
background-image: url('img/sprite.svg');
background-repeat: no-repeat;
background-size: 1000px 1000px;
overflow: hidden;
color: transparent !important;
}
.sprite.logo {
width: 270px;
height: 55px;
background-position: 0 0;
display: block;
}
[...]
Every other Browser (including Android Browser 4.4) shows everything correctly.
This issue exists on Android 4.3- and IE9. To solve this, simply specify width and height attributes for svg tag in you file.