Multiple transition properties not working in Firefox - css

I've had this CSS for some time, and suddenly I noticed it's not working in new versions of Firfox.
-moz-transition: all .3s, top 0s, left 0s;
So the original idea was opacity & scaling transforms would animate while top and left would not animate. I know using "opacity .3s" will work, but I need my scale transform to work also. I'm also aware of the CSS "zoom" property, but that will not work for my needs.
Basically, I just want this to work and I have no idea why this correct CSS is suddenly broken in Firefox. If anyone has an alternative solution, that would be great.

Ssssup doode,
instead of all put transform. Like this:
-moz-transition: -moz-transform .3s, top 0s, left 0s;
example: http://jsfiddle.net/9J5vc/3/

this is a problem with the lastest versions of Firefox and not your code. I have half a dozen sites that are not properly rendering css in firefox at this time. they were all fine not more than a week ago and no change to the code or codebase was made. the styles still work in other browsers.
Firefox is having issues on thier current release of the browser and I am sure they are all aware of it, but really, if it does not get fixed soon, they will loose even more market share. which would be a shame really.

That is a bug in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=835007 (similar question: 14533519 and was recently fixed for the Firefox 21 milestone. Until then, you can't use all as part of multiple transitions and have to specify every property separately.
To be fair though, only the most recent W3C draft explicitly states this behaviour; earlier versions were not very clear how this case should be handled.

This works for me..
-moz-transition: bottom .3s, right .3s, top 0s, left 0s;
Also make sure your element is still positioned.

Related

FireFox css transition 'transition-all' creates flicker on hover and other unexpected occasions

I am wondering why I am seeing a flickering effect on an element when using transition: all 0.5s ease-out; in FireFox (latest as of this writing). It's hard to explain, but see live example here: http://imaginary-material.launchpage.me/ (check out the logo flickering) - this issue does not happen on Safari or Chrome.
update
In my original code I had the transitions applied to the a tag wrapping the img and the img. Removing the translate from the a tag gets rid of the flicker, so that solves my problem. However that is still a mystery to me, if anyone cares to comment on why it would cause flicker, please do so.
Found solution you are using Very big images [1024 resolution] instead of thumbnails!
Use light images for flicker-less transitions!
Try this for images src="http://placekitten.com/120/120" demo it will not flicker! Checked

CSS 3D cube -webkit-transition

I was able to reproduce a rotating 3D cube in css using online examples. Now I am analysing the code so I learn the meaning of the code and understand how it works.
However there is one thing i don't understand, I know that the "transition" property lets me add an effect when changing from one style to another. (for example changing the width of an element) But in the code that can be found here it's used in a way I don't understand.
-webkit-transition: -webkit-transform 2s linear;
If I leave this piece of code out the cube looks and acts exactly the same, I don't understand what it does and if it is necessary.
Thank you for your help!
-webkit- is the prefix used on WebKit browsers for properties which do not necessarily have full support and are in a testing/experimentation phase. There are a couple of other prefixes in the CSS world too. A few of the more popular ones are: -moz- (Firefox), -o- (Opera), and -ms- (Internet Explorer).
Here -webkit-transition: is the WebKit-prefixed transition property, and -webkit-transform is the WebKit-prefixed transform property.
If we look at Can I Use... for browser support, we'll see that the transition property requires the -webkit- prefix on some mobile browsers. We'll also see that the transform property requires the -webkit- prefix to work on quite a lot of WebKit browsers.
In order to give our transform property a transition on Android browsers, for example, we'd need to use:
-webkit-transition: -webkit-transform 2s linear;
On browsers which fully support both transform and transition, we can achieve the same effect by using:
transition: transform 2s linear;
To be on the safe side, we could also cater for browsers which require the WebKit prefix on the transform property, but may have since dropped the prefix on the transition property - although this may be unnecessary:
transition: -webkit-transform 2s linear;
The thing I dont understand is what the "transform 2s linear" adds to the cube.
This adds a two second linear transition (animation) to the transform property assigned to the cube. Without this the transform property would be changed immediately, but with this the change is gradual over two seconds.
Here is a JSFiddle demo I've whipped up of the transition property in action. Here our first figure instantly changes from red to green on hover, but our second one takes 2 seconds to change.
The transition in the code you've linked to doesn't appear to have any effect on the object at all.

CSS: Transition on shadow filter

so I'm trying to cast a shadow onto a non-rectangular object in a png file with transparency. That works so far, but when I try to add a transition effect on hovering over the image, the filter seem to max out their set value and then quickly bounce back to the actual set value when the timer from the transition feature is up. I'm running Chrome 28 Mac but also appears on Safari.
I have demonstrated this effect here:
http://jsfiddle.net/dbananas/3pMS8/
transition: all 0.2s ease-in-out;
-webkit-filter: drop-shadow(0px 0px 13px rgba(0, 0, 0, 0.9));
Recommendations anyone who to fix this and make the transitions smooth?
Thanks,
db
I'd check to see if this works and happens in Firefox. If I had to guess, I'd say it's a bug in Webkit (checking in Firefox can help confirm that it's a browser bug and not a bug in your code). You can file a bug report for it here: https://bugs.webkit.org/
That said, in order to work around it, you might have to reconsider how you're going about solving your problem.
For example, if you're doing it for text, you can use the text-shadow property, which is animatable.
If it's an actual image, you could resort to making a "shadow image" that you could fade the opacity on (if you're using this on a content image), or swap to (if you're swapping background images).
Edit I found this tutorial, which may be of use to you. It's an image cross-fade effect, like what I previously suggested. It has a few different variations (including a pure CSS one), so you can probably adapt it to make it work for you. Basically, you add a background to the img, then fade in/out the img element itself to create the effect. I'd agree that it's not ideal (your -webkit-filter technique is arguably superior, if it worked properly in the browsers).
That does look like a bug. It looks like the shadow radius is being treated differently while the animation is in progress (and accelerated filters are applied). I've logged this for Chrome as http://crbug.com/266957
As a workaround, you can apply -webkit-transform: translateZ(0) to the element with the shadow, which will force it to always be accelerated.

Differences in animation-timing-function between browsers? I just want linear

I'm trying to set up a css animation that will work in Chrome, Firefox, Safari and Opera to animate the width of some coloured bars back and forth while retaining the overall width to fit the page.
I set up a demo at http://codepen.io/marblegravy/pen/rxhym
If you open it in Chrome, it works exactly as I want with it sticking to the edges of the page (whatever the width so it will work in a responsive layout).
In Firefox, Safari and Opera however, it appears that the animation-timing-function: linear; or the linear declaration in animation: bulge4 7s infinite alternate-reverse linear; isn't taking effect and the whole thing scales back and forth.
I am using Prefix-free to shortcut the coding on Codepen, but I don't think that's where the problem is.
Any ideas?
You are animating the width trough CSS Tricks/Hacks. As CSS is interpreted different across browsers it will give different results. Also because this is a trick all browsers will interpret it on their own way.
You could make an simular setup trough jQuery Ui. For example animate can also scale sizes of elements, colors etc. In my opinion this is an better and more solid alternative then using CSS Tricks.
More information can be found at http://jqueryui.com/docs/animate

Poor transitions result from fixing anti-aliasing

In a previous question I figured out how to fix the anti-aliasing caused by rotating an element using CSS3 transitions when the element is hovered. However, that fix has changed the transition. Before the fix, the transition was smooth from start to finish. Since the fix, the transition has become very rigid. (It's worth noting that the transition was never smooth when using Firefox, but using Safari or Chrome it was, prior to the anti-aliasing fix.)
Here is the code I used originally. Note the transition when you hover over the box if you are in Chrome or Safari:
http://jsfiddle.net/CRc9d/
And here is the code with the fix for anti-aliasing:
http://jsfiddle.net/JMgxC/
Is there a way to reconcile the second code so that it preserves the anti-aliasing fix but also provides a cleaner transition?
Background:
Here is a fiddle showing the transition that, when hovered, causes anti-aliasing in the input placeholder: http://jsfiddle.net/EJUhd/
This was answered by Steve Adams in another question. I just had to change my -moz syntax:
From...
-moz-transition-property: rotate;
-moz-transition-duration: .17s;
-moz-transition-timing-function: linear;
To...
-moz-transition: -moz-transform 0.17s linear;
The second jsfiddle is not transitioning at all because the declaration -webkit-transition-duration: .17s, .17s translate3d(0,0,0); isn't valid.
If you want to antialias the first example, just add -webkit-box-shadow: 0 0 1px transparent; to the box and it will antialias with the animation. The latest version of Chrome doesn't need this hack.
http://jsfiddle.net/CWFLN/
Here is another example that illustrates the problem/solution:
http://jsfiddle.net/fKq8y/

Resources