It's weird iOS bug time again. I've got a header that's set to around 70vh, and (for the most part) it works well. It used to be buggy in iOS Safari but they seem to have fixed it. Apart from when you rotate the screen. It seems to double every time you rotate the viewport. 70vh becomes 140vh, then 210vh and so on.
I don't know if there's anything I can change in the CSS or on the meta viewport tag that will stop this? I'll even look entertain Javascript solutions if that's the only way around it.
Here's the site I'm referencing. All the code is on github if that's your thing.
Related
I do not know how it has happened, because it worked properly at some point, but after doing some changes, I think to the main scroll container layer of the page, this started happening.
It is a weird visual glitch, I am not able of reproducing it, all that I can say is that the transition is a CSS transition with transform: translateX() and that while the transition is running both elements (new and old) get an absolute position that its remove once the animation ends. Also, there aren't any text-shadows in place.
I does not happen in firefox nor in chrome mobile, and it does not happen always, depends on if I have or not the developer tools opened, I think it might be because of the change in viewport resolution when those are open.
I have this issue as well;
fiddle
Seems it has to do with multiple layers of nested animations.
Its a bit to complicated to outline here!
I'm trying to work with the nice parallax effect in this template. It seems to work well with all browsers except mobile Safari (unusually)!
http://wrapbootstrap.com/preview/WB002R8U1
Look at the ABOUT and FOURTH sections on an iPad and the background image goes missing (presumably because it's stuck to the top of the page behind the other elements.
Anyone know a workaround for this?
Many thanks.
parallax on mobile iOS is not that easy: safari blocks all rendering while scrolling (for performance boosting), therefore you can't measure the current scrolled distance and apply it to the background position. the picture would only refresh it's position when you've finished scrolling (and without animation, so you wouldn't see anything of it).
There are workarounds but they're not as easy to implement. one of them is http://markdalgleish.com/projects/stellar.js/ with its iOS techdemo.
Best solution: split your css markup and let parallax only be visible to desktop devices. As parallax needs a lot of power (because it's not hardware accelerated), it's not very suitable for mobile devices anyway.
Got a really tricky problem that I've been trying to figure out for a while. Essentially I'm building a large rotating wheel which has multiple elements rotating at different speeds. It's about 5000px square, but the viewport is a percentage of window height. Due to the scaling, the wheel itself is an SVG so that it looks sharp on all devices. The SVG has some pretty complicated paths in places.
It's hard to explain, so I've made a barebones demo of what I'm talking about: http://jsfiddle.net/UsVeZ/3/embedded/result/ (edit it here: http://jsfiddle.net/UsVeZ/13/). Click / tap the document to see it rotate.
Everything looks fine, and it works great on the desktop (Chrome + Safari), but when I rotate the wheel on an iPad, mobile safari lags with the rendering. The rotating animation itself is pretty smooth, but it's just the rendering that can't keep up. It's way worse with my complex SVG (which unfortunately I'm not permitted to share, but the demo gives an idea). Check it out on an iPad to see what I mean.
I'm not quite sure how to solve this problem - ideally it would be great if there was some way to keep the entire SVG in memory (not sure exactly how the rendering works or why it's doing what it's doing). If anyone has any ideas, or even a different way to approach, that would be amazing.
This is not a full answer, just a couple of strategies you could follow.
If you apply...
body {
-webkit-transform: scale(0.3);
}
You will see how Mobile Safari caches your svg, it gets pixelated and then renders correctly. If you tap and wait, it will re-cache the image when you tap again. But if you tap continously, you will notice you don't give it a chance to recache the image.
This happens in your jsfiddle too, if you tap continously eventually you don't get any choppy blocks.
So if you don't let Safari recache the image by creating an endless transition like...
$("svg").on("webkitTransitionEnd", function(){
rotation -= .01;
$("#large").css('-webkit-transform', "translate3d(0, 0, 0) rotate(" + rotation + "deg)");
$("#small").css('-webkit-transform', "translate3d(0, 0, 0) rotate(" + ( rotation * 1.5 ) + "deg)");
});
Then the cache will never go stale.
However, once you remove the scale on the body, it seems that Safari won't cache any graphics outside of the viewport. So, perhaps if you make the wheel have a full spin on load it will cache the image.
So I couldn't end up solving this issue properly on my real example. I ended up reverting to images (I split up my large image into 9 smaller images and tiled them to get around iOS' 5mp limit), and on each image I applied the following property which seems to cache the image:
-webkit-transform-style: preserve-3d;
It doesn't scale as nicely, but it works smoothly which is more important.
I actually took several different SVG's and applied a rotation to them in iOS and it ends up adding this box the instant I rotate it. I can't duplicate it in Safari or Chrome (desktop). Tried a bunch of different things to get it to stop, but no luck. I haven't been able to find much feedback online about if its a bug or not.
Just applying -webkit-transform: rotate(122deg);
Example at - http://bit.ly/QnAgFK
I found that certain [object] tags have there #documents add [html][body] tags around the svg in Safari 6. Others don't. So my assumption is this is a mime type host issue, but I've got the image/svg+xml mime-type added for .svg.
I have a dirty fix for this one.
#topParentId *{
-webkit-transform-style: preserve-3d !important;
}
I have applied css to every child of topParentId Id, and this works fine for me. It changes a little css in output but it works fine for me.
I've been working on a website for a little while now, doing most of my testing in Chrome, Firefox, and IE. As I'm wrapping things up, I've tried viewing it in Safari (on Mac, iPad, and iPhone). I've noticed that certain elements are misplaced in Safari. I've tried playing with the CSS, but I've had no luck.
The page can be viewed here - http://staging.princewebdesigns.com/gallais/
See specifically the logo (being pushed down into the banner), the font of the tagline in the banner (wrapping beyond the banner and extending too far to the left), the 'Featured Work' title wrapping, the project names wrapping, and the footer wrapping.
Here is how the page should look - http://staging.princewebdesigns.com/gallais/images/chrome.png
To see how it looks on my iPhone, change the link above to .../iphone.png
Any help is appreciated.
The issue is (I think) that you have your browser's text zoomed in.
I loaded the page in Safari 5.1 on Mac OS 10.7.3, and it loaded fine initially. When I zoomed normally, the layout stayed intact. As soon as I tried zooming just the text, the layout broke per your description.
That being said, you may want to think hard about how to make the layout more 'flexible' in the event a user does have their text size increased. In IE, for example, the default zoom is full page zoom, but a user can still increase their text size apart from zooming. It's worth testing your layout in those situations to make sure it doesn't completely derail. I'm not saying it has to be perfect, but still legible.
One idea is to try out different units. I've found that when declaring horizontal lengths (e.g. margin-left) using relative measurements works, but when declaring vertical lengths, (e.g. margin-top) using pixel measurements works better. For super critical items, like the site logo, positon:absolute may be a good route to try.
I have a web site page that doesn't seem to be rendering properly for chrome in safari.
It appears it is rendering the width of the screen with twice as many pixels as other browsers. I suspect it may be the initial viewport settings, which work in all other browsers for windows and apple, except for the version of chrome on mac.
I tried removing the viewport setting but that doesn't seem to work. I am using the latest version of Chrome, and if I have a window open in safari beside chrome you can see that chrome is rendering the screen as twice as wide, even though it takes up the same width.
Oops. I can't post an image, but you can see it here: http://straathof.acadnet.ca/test_chrome.jpg
If you would like to test it, you can visit the page here: http://straathof.acadnet.ca/reblend55
Any help for tracking down this problem would be appreciated. I have no idea where to look.
control-0 removed any zooms that had been added to the web page, which allowed it to render properly at the correct width. Apparently some months ago I zoomed in on something and, even though Chrome was removed reinstalled and reset, not to mention quit and restarted a whole lot of times, it still remembered that errant zoom value.
annoying, but answered with someone elses suggestion.