I try to make a flip-page effect in IE10.
Because IE10 doesn't support transform-style: preserve-3d;
i have to flip each side seperately. It works well in recent browsers but there is no perspective in IE10.
If i write perspective: 1000px; in the container(.flipper), backface-visibility/z-index is not working correctly.
Have a look at tis jsfiddle:
http://jsfiddle.net/wG6gk/2/
I have no clue why you have xpersepective in your CSS, IE10 is unprefixed in CSS, however the perspective property must have some kind of unit for the depth, perspective: 1000 won't be applied because the browser doesn't know what unit it is in, similarly like width and height, etc, you have to apply px, em, etc. The only browsers that assume units (and in pixels) on the perspective property are Webkit browsers, and only when it is inside the transform property.
If you do a little research you, Microsoft states:
The W3C specification defines a keyword value of preserve-3d for this property, which indicates that flattening is not performed. At this time, Internet Explorer 10 does not support the preserve-3d keyword. You can work around this by manually applying the parent element's transform to each of the child elements in addition to the child element's normal transform.
So for now, you'll just have to implement the advised fix, if you want to go down that road.
If not, you're lucky. I spent time trying to make it transition smoothly over. Originally in your fiddle, you were transforming it very awkwardly and had too many styles, in my opinion, so the techniques in this JSfiddle should help: http://jsfiddle.net/NAy2r
Explained fiddle
So basically the front content exists in the container div, while the back content exists in the back div, which exists inside the container div. This is very similar to Apple's HTML5 Card flip demo, however there is a twist when it comes to backface-visibility.
At the time that Apple relased that demo, backface-visibiity didn't work on Chrome or Firefox. Chrome had some concept of perspective, but none of backface-visibility, so when you flipped an element, you'd still see through to the back and the content of the back would show through both sides as well; However on Safari, it'd be perfect because it initially understood these concepts.
In further updates of Chrome in the months afterwards, Chrome understood the property, however it was applied literally and the back was hidden completely, regardless if you flipped it or not! What would be the point of having this property if it was going to hide the back completely no matter what? You could just apply display:none, etc, to show the back if you wanted!!
And that is where IE stands as of today, it as well doesn't recognize the 'back' of the element (an element with transform:rotateY(180deg) is considered to be the backside) like other modern browsers do. So when the element is flipped, backface-visibilty: hidden is taken literally as it was in Chrome!
So this fiddle listens on an AnimationStart event on the container div, and on the animation start, it finds the duration of the animation and it uses that to calculate halfway though the animation, so when the animation is halfway, it changes backface-visibility to visible, that way the animation smoothly transitions like it's supposed to.
This was a pain to develop, IE10 is somewhat inconsistent, as it needs time to process it the first time (probably the jQuery). Notice the relief, lack of headache and fiery red eyes. The air around you has become cooler and you can finally breathe, because now you're not alone.
Edit: I forgot to add, that if your animation or transition has a different timing, the timing in this script will have to be adjusted, as it only works with linear transitions, as of now...
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!
so I've read a lot about the current state of rotating text and not being able to perfectly get real antialiasing to happen in all browsers. It looks like the first box in the pic in chrome, but the second, jaggedy box in firefox. I've tried the most popular fixes including -webkit-backface-visibility:hidden; -webkit-font-smoothing:antialiased; and maybe one other I can't remember.
However this is not asking the same question, but a new one I havent found anywhere. These two screenshots of the same box are both taken from Firefox. The jaggedy box on the bottom is what it looks like normally, however, when I mess with the rotation attributes with another(completely different) element on the page with the css edit console, it renders the box perfect / smoothly...
I do, however, have to continue to press up or down to change the rotation value on another element for the entire box to render antialiased perfectly, then it returns to its jaggedy normal self. I rotated the div that the content is in and put the css fixes on the same div(although I did try putting the css fixes on every element) and I didn't ever seem to get any smoothness or antialising like you see in the box above...only when I rotate another element on the page in the browser. WTF?!!?!? is there a way to do this in css or is it only something the browser is doing in realtime and cannot reproduce that smoothness in CSS yet?
EDIT: PIC for comments section
For whatever reason, it seems under some circumstances browsers "forget" to antialias text while doing complex transforms.
The fix:
Using CSS to force the browser to render the transformed element in a separately-composited "layer" is one solution:
transform: rotate(…) translate3d(0px,0px,1px);
The explanation:
Many rendering engine implementations create a GPU layer for the 3d-transformed element, and composite it onto the rest of the page when painting. This alternate rendering path can force a different text-rendering strategy, resulting in better antialiasing.
The caveat:
However, this is a bit of a hack: first, we're asking for a 3-dimensional transform we don't really want; second, forcing many unnecessary GPU layers can degrade performance, especially on mobile platforms with limited RAM.
dev.opera.com hosts a good discussion of compositing, hacks using transform3d, and the CSS3 will-change property.
Jeremy if you come back and answer this I can give the answer to you. just realized I hadn't had an answer to this so I needed to put something here.
This solution worked as in the comments above:
Jeremy:
I had another thought: it could be related to creating an opengl/webgl layer behind the scenes. If you add translate3d(0px,0px,1px) after the rotate transform, does it "fuzz out" a bit more?
Answer - Yes this works to perfectly anti-alias any text in all browsers!
I'm experiencing an issue on Internet Explorer 10 when using CSS transform property to change the 3D perspective.
Random artifacts appear on the edge of some elements contained in the element with the perspective applied.
I've created a simple fiddle to demonstrate the issue:
http://jsfiddle.net/b9ztC/
To reproduce, just open the fiddle and try to select, click or play around with the text, this results in the following artifacts appearing/disappearing around the paragraph element:
More lines and artifacts appear in more complex scenarios, and the cause seems to be the following line of css:
transform: perspective(800px);
The only ways to solve the issue seem to be:
not to have the perspective applied to the element
setting the transform perspective to 0px
use perspective: 800px, instead of transform: perspective(800px)
The last one seems an easy solution but it doesn't work well in some scenarios, the following 3D flipping card demo for example (which has the same artifacts problem on the back of the card using IE10) doesn't play well when applying the perspective property separately from the rotation transform: http://www.cssplay.co.uk/menu/css3-3d-card.html
Have anyone experienced this issue? Is there any way to prevent this from happening?
I'd also like to know if this happens on every machine or it can be an hardware-related issue.
I'm seeing more or less the same issue, though only on the left side of the div, it changes depending on the transform. It seems to be the background bleeding through at the edges of the line.
I'm on Windows 7 x64 with an Radeon HD 4670 (Catalyst 13.1), using IE 10.0.9200.16686 (KB2870699).
The only practical workaround I've found so far is to apply the padding on the inner element, ie on the p instead of on the div. However I'm not sure whether the padding is actually the trigger, so this might not be applicable in other situations.
I have the following code:
http://jsfiddle.net/RFMxG/1/
When the transition runs, you can see a padding of about 20-30 pixels on the left hand side. Despite the fact I have set the transform-origin to be 0,0,0, it is still not correctly rotating about the y-axis. The left edge of the blue box should be flush against the left hand edge at all times during the animation.
Can anyone tell me what I've done incorrectly?
Okay, there are whole bunch of issues here:
1) CSS transforms aren't animatable using transitions. If you look at the W3C list of transitionable properties, you'll notice that transform isn't there.
2) -webkit-perspective only affects the children of the element it is applied to, not the element itself. Read the Safari blog on this:
The interesting thing about -webkit-perspective is that it does not
affect the element directly. Instead, it affects the appearance of the
3D transforms on the transformed descendants of that element; you can
think of it as adding a transform that gets multiplied into the
descendant transforms. This allows those descendants to all share the
same perspective as they move around.
3) It's awesome that you posted a fiddle, but since this is a CSS problem, for future reference it would have been a lot easier if you cleaned out all the javascript, and used one set of browser prefixes only. Help us help you!
4) What you probably want to use is an animation. Here's a highly modified version of your fiddle that works on hover:
http://jsfiddle.net/RFMxG/4/
5) If javascript is your skill set, and you're at all concerned about browser compatibility (which of course you are!), I highly recommend doing these kinds of animations with jstween.
Right, so the solution was actually due to the fact the transform origin needs to be set prior to the animation starting (it cannot be set at the same time the -webkit-transform property is set).
I've updated the fiddle to demonstrate this now works correctly.
http://jsfiddle.net/RFMxG/5/
A live example can be seen here.
A red square (showing) is directly above a green square (hidden as overflow). Click on the square, and both colored squares are instantly made fully transparent. Additionally, the height of the red square is set to 0; this fires a transition, but the transition goes unseen because the red square is now transparent.
Before clicking the square again, examine the toggle function. Looking at the JavaScript, I would expect the height of the red square to be reset to its original value without firing a transition. The transition should be suppressed, because the transition property is temporarily set to none while the height is changed.
Now click on the square again. Both colored squares are instantly made fully opaque, but the red square slides down as its height transitions from 0 to the original value. It's as though the height set by the inline style wasn't removed by the toggle function until the element was visible, and by then the transition property had also been reset.
Triggering a reflow seems to force the change in height to be applied. (Uncomment the line containing offsetParent to test.) This behavior occurs across browsers (at least Chrome and Safari, Firefox, and Opera), so I'm wondering if it isn't part of some spec. I've checked the CSS Transitions Module without success. Any ideas why this behavior occurs, and why it's so consistent across implementations?
This really is a bizarre problem. I don't think you're doing anything wrong in your code—the current browser implementations are just buggy.
I've run into these kind of seemingly-obvious bugs before with CSS transitions, and they're a huge pain to deal with without resorting to byzantine hacks that are sure to break once the bug they're working around is fixed (in this case, my WebKit fix).
I really dug into this, but couldn't come up with a clean solution that worked in the three main transitions-supporting layout engines (WebKit, Gecko, and Presto). That said, here's what I did figure out—hopefully someone smarter than me (or just coming at this with fresh eyes) can take this answer and turn it into true solution.
Gecko and Presto (but not WebKit!)
It looks like (and I am not a browser engineer or familiar with the spec) that any current or previous value of a transition-property will continue to be rendered regardless of whether or not it needs to be. So even though you've changed the value of transition-property, the browser is still rendering the height transition in the background, and when you change the height back, you get the trailing end of that.
There is a solution though: create the transition in JavaScript (don't put it anywhere in the style sheet), remove it (after which there are no transition rules applied to #upper anywhere in the DOM), change the height, and then re-add it. Not perfect, but not a bug-reliant hack either.
http://jsfiddle.net/grantheaslip/e3quW/
JavaScript
upper.style.removeProperty('transition');
upper.style.removeProperty('-o-transition');
upper.style.removeProperty('-moz-transition');
upper.style.removeProperty('-webkit-transition');
upper.style.removeProperty('height');
// force a reflow
// if (upper.offsetParent) { /* empty */ }
upper.style['transition'] = 'height 1000ms';
upper.style['-o-transition'] = 'height 1000ms';
upper.style['-moz-transition'] = 'height 1000ms';
upper.style['-webkit-transition'] = 'height 1000ms';
Style sheet
#upper {
background-color: red;
}
WebKit (but not Gecko or Presto!)
Anything that only works because of a 1ms timeout probably should never go anywhere near production, but I think this is worth pointing out in case it helps someone get to the bottom of this problem.
My guess is that WebKit doesn't have the same issue as Presto or Gecko, but instead includes an optimization that gathers style changes applied in the same function and applies them all at once. Again, pure speculation from someone who's never gone near the WebKit source or CSS3 spec.
http://jsfiddle.net/grantheaslip/DFcg9/
JavaScript
window.setTimeout(function() {
upper.style.removeProperty('transition-property');
upper.style.removeProperty('-o-transition-property');
upper.style.removeProperty('-moz-transition-property');
upper.style.removeProperty('-webkit-transition-property');
upper.style.removeProperty('opacity');
lower.style.removeProperty('opacity');
}, 1);
Gecko, Presto, and WebKit
Here's both solutions combined. Again, because of the timeout hack, this really shouldn't be used.
http://jsfiddle.net/grantheaslip/N3NrB/