Can anyone help me make this Chrome CSS code cross platform? It doesn't work properly in Firefox or at all in IE8. I really appreciate the help, thanks for reading.
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-webkit-transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
EDIT - Here is the page with the code suggested below, where the issue persists in Firefox. All text on the page should fade in at intervals, but sometimes random parts are appearing without the fade. If it works fine the first time, try refreshing and you'll see what I mean. The page is an output from Twine, and the modified CSS is right at the bottom. Thanks again.
Example HTML page with inconsistent fade ins in Firefox
You just need to throw some browser vendor-prefixes in there.
Based on the current support of transition, you just need -webkit, -moz, and -o:
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-webkit-transition: 1s;
-moz-transition: 1s;
-o-transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
You won't have support in IE9 and lower.
Usually for these experimental features (so in general, if you're not sure about it, look it up) it's best to look up if it's supported by the browser. Since transitions are not completely supported by all major browsers, you need to add the prefix for all browsers that don't fully support it yet. So, according to MDN's Browser support list, and Statcounter's browser usage stats, you should have the following:
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-o-transition: 1s;
-webkit-transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
Since both webkit browsers don't have a generally used version that doesn't fully support it without prefix, and firefox doesn't need a prefix, this should work. The problem you're having shows that you've not updated your firefox in a while, and if you're going to test how your site looks in other browsers, I strongly suggest making sure you've got the up-to-date version. Firefox already supports the syntax without -moz- prefix since version 16, and it's at version 26 now (with 25 being the most commonly used at the moment).
Of course if you really want to support even the browsers that almost nobody even uses anymore due to automatic updating (such as Firefox <16), you should indeed like Zach Saucier (deleted his answer) JoshC says also include the -moz- prefix. The -ms- prefix is not needed at all though, since every version of IE that does support transitions also supports it without needing that prefix.
EDIT: added -webkit- for Android/Blackberry default browser.
Extra bit (after seeing added dropbox link)
Considering the dropbox link, what I think is causing it is this: Firefox is still animating the first element when the second shows up, so it doesn't restart the animation.
This could explain why it happens randomly: it only happens when Firefox has a few milliseconds of lag, and firefox continues playing the animation for the second item from the starting point of the second animation. This is likely caused by the fact that your items are nested, so the animation of the first row would be inherited by the animation of the second row, and so forth.
Since your animation length is 0.5 seconds exactly, and the interval between showing elements is also 0.5 seconds exactly, if there is the slightest bit of lag this cause these problems. I suggest putting a tiny extra space between showing each element (perhaps 10 or 50ms or so), or changing the items from a nested method to a sibling method. So, instead of this:
<div class="body content">
<span class="first">500ms
<span class="second">500ms
<span class="third">500ms
<span class="fourth">500ms</span>
</span>
</span>
</span>
</div>
Use this:
<div class="body content">
<span class="first">500ms</span>
<span class="second">500ms</span>
<span class="third">500ms</span>
<span class="fourth">500ms</span>
</div>
So, instead of appending the spans to the current span, append it to the parent element .body.content. I would give you a demo, but your script looks really quite complicated (probably because it's generated by something), so you'll have to try doing that yourself. You could also try putting a tiny bit of extra space between each item's animation starts and see if that fixes it.
Once again I am going to tell you that css3 is still work in progress.So if you want to invoke the css rules then use the vendor prefix provided by their browsers.Note that Internet Explorer 9, and earlier versions, does not support the transition property.
-moz- for firefox use
-webkit- for safari and chrome because both uses the same browser engines
-ms- for microsoft
-o- for opera
.revision-span-in {
opacity: 0;
}
.revision-span:not(.revision-span-out) {
transition: 1s;
-webkit-transition: 1s;/*for chrome and safari*/
-moz-transition: 1s;/*for firefox*/
-ms-transition: 1s;/*for ie*/
-o-transition: 1s;/*for opera*/
transition: 1s;
}
.revision-span-out {
position:absolute;
opacity: 0;
}
Related
I have the following CSS classes:
.genre_element {
background-color: none;
}
div.genre_element:has(input[type="checkbox"])::before {
content: "\002B";
transition: transform .3s ease-in-out;
}
div.genre_element:has(input[type="checkbox"]:checked) {
background-color: #ff9400;
transition: all .2s;
}
div.genre_element:has(input[type="checkbox"]:checked)::before {
content: "\2713";
transform: rotate(-360deg);
transition: transform .3s ease-in-out;
}
This is supposed to show a checkmark unicode character and add a bg-color to inputs as long is they are checked and add a plus character when they are unchecked. When they are unchecked they automaticaly revert back to the color I set in the genre_element {} class, which is none.
This works as expected in Edge, Chrome and Opera, but in Firefox I can't get it to work. I used caniuse.com to check my class for browser compatibility and enabled the layout.css.has-selector.enabled flag.
This fixes part of the problem as it displays the correct style that the buttons need to have when they are checked, but I cannot uncheck them. Clicking on them has no effect.
This is how the parent divs of the buttons look like before enabling the flag:
This is how they look like after enabling the flag; unchecking does not work:
This is how they look like in Chrome, Edge and Opera (desired outcome) after unchecking them:
Since enabling the flag causes the buttons to look like they are supposed to in their checked state, I am assuming that both the ::before and the :checked are supported by Firefox (which corresponds to the information on caniuse.com and which I could confirm by looking into the developer console) but something else is causing the buttons to not work properly in firefox.
As a last resort I tried out adding this pseudo-class checking for the negation of the checked condition:
div.border_div_in_scrollbox:has(input[type="checkbox"]:not(:checked)) {
background-color: none;
transition: all .2s;
}
But this didn't fix the problem.
P.S.: After playing around a bit more I got firefox to show the desired state, but it is very buggy. Only sometimes after I select the input with the selector tool from the developer console, after I have unchecked it, does it change to the state it should have, but itt is not consistent at all. This is how it looks like (I made the original inputs visible again to make debugging easier):
According to w3.org :before and :after pseudo-elements can not be used with input elements they can only be used with container elements like div or span you can wrap input element with div/span then use :before on div/span.
for more information
can-i-use-a-before-or-after-pseudo-element-on-an-input-field
From what i can see on caniuse.com the :has() selector does not work with Firefox at all.
Had the same issue last week also and still looking for a :has() work around.
I have the following markup:
<div class="cube trigger cuberotate">
<div class="face init f z"></div>
<div class="face init l y"></div>
<div class="face init b z"></div>
<div class="face init r y"></div>
<div class="face init u x"></div>
<div class="face init d x"></div>
</div>
Which resembles a 3d cube, every face is rotated and translated onto their proper position and I let the cube rotate using an animation on the faces' parent.
Here's the related css of it:
.cube {
position: absolute;
cursor: pointer;
width: 120px;
height: 120px;
top: 0;
left: 0;
transform-origin: 50% 50%;
transform-style: preserve-3d;
}
.face {
position: absolute;
width: 120px;
height: 120px;
border: 0px solid #fff;
background: #c82222;
transform-origin: 50% 50%;
opacity: 1;
padding: 0px;
-webkit-touch-callout: none;
user-select: none;
transition: all 0.5s ease-out;
}
I wanted to make the cube appear one face at time on document ready, so I just threw in some javascript, basically an interval every 500ms which simply removes the .init class which overrides the opacity: 1 value on the .face class.
(function($) {
'use strict';
// Some selectors and shit...
var $face = $('.face').first(),
speed = 500,
timer = null;
$(document).ready(function(){
// Start showing faces
timer = window.setInterval(function(){
var $next = $face.next();
$face.removeClass('init');
if(!$next.hasClass('face')) {
window.clearInterval(timer);
}
$face = $next;
}, speed);
});
})(jQuery);
// And the additional CSS below
.face.init {
opacity: 0;
}
In an ideal world this code should work, however I am facing a problem on Google Chrome the opacity doesn't transition back to 1 after the class is removed keeping the cube completely invisible. If you right click and inspect it becomes visible again.
Curiously on Safari, which is also a webkit-based browser this does not happen at all and the faces show one at time as they are supposed to do.
I tried to use both .animate() from jquery and also tried the jquery plugin transit
Now, Safari and Chrome aren't supposed to behave in the same way, or are there major differences under the hood despite the rendering engine being the same?
Is it something I did wrong?
There's a workaround for this?
Here's my pen:
http://codepen.io/luigimannoni/pen/FstKG/
Thanks
Update:
I have tried obviously on Chrome on my Mac and also on Windows 7 and they both behave the same way (different machines also)
Also tried Firefox which works seamlessly like Safari apart from the rotating animation which isn't happening (but I kept Firefox out of consideration as it's a different browser).
Additional update:
Chrome on mobile devices (both iOS and Android) are working and behaving like Safari on desktop.
Another Update:
After playing around around I have found probably it's a browser bug, Chrome Canary works fine as expected.
I posted this on facebook where I've got a couple of good workarounds from a developer, which I found quite creative.
The first one involved in have a rgba() background-color and make the alpha change instead of having the transition on the opacity: http://codepen.io/anon/pen/IjsBL
The second one involved a bit of javascript coding, forcing the browser repaint the faces at each frame: http://codepen.io/anon/pen/Hofzb
I am starting a bounty to see what stackoverflow can do here!
You could try to assign 0.01 to opacity.
.face.init {
opacity: 0.01;
}
Looks like it is a documented regression bug
For the difference in Safari and Chrome, you should know that Chrome uses Blink(a webkit fork) as its rendering engine since version 28.
This problem was brought to my attention on Facebook. As requested, I'll post my initial thought process.
Initial Thought: Aggressive GPU-use / hardware-acceleration
Initially, I thought Chrome was seeing the 3D transforms in the keyframes-animation and hardware accelerating the animation -- which is what we expect -- but then when trying to interfere via JavaScript, was not interrupting the GPU execution.
Workaround 1:
Use a separate keyframes-animation first to animate opacity and rotation at the same time and then start your current animation, animating just the rotation to continue infinitely.
See this codepen.
Workaround 2:
I then immediately realised he wanted each face to fade in independently, in sequence. Knowing javascript wasn't interrupting the CSS animation, I tried animating the .faces using a keyframes-animation. Using an animation-delay to stagger each face.
See this codepen. But for some reason, it stops after the first face :(
Workaround 3:
At this point I was clutching at straws, and thought to toggle perspective: 500px to perspective: 501px, within a requestAnimationFrame callback, in hopes it would break hardware-acceleration, but no luck.
Workaround 3.1:
But having used a requestAnimationFrame, I decided I could just perform the first rotation and intended fade-in's using javascript and then trigger the CSS animation after.
See this codepen. This was the intended visual.
Workaround 4:
While anyone else would have been done and dusted, still using javascript bugged me to hell -- as much as I love JS, CSS is just smoother (right now).
Then it hit me! I could just animate background-color: rgba(...); rather than opacity: ...;.
And so finially, I had the intended animation using pure CSS.
See this codepen.
This was based on Workaround 2. I had to create 3 extra animations: one for each colour .face identified with classes .x, .y and .z.
I used SCSS to make it clear I was using the original colours (hence the rgba(#c82222,0);) and also to save myself the ball-ache of having to convert that to RGB values anyway.
Hope that helps anyone :)
Please try to initiate opacity from zero with bit more transition values.
CSS position relative fixes the problem:
.fullscreen {
position: relative;
http://codepen.io/anon/pen/oekyt
It reminds me the of old IE bugs then you have to set
*zoom: 1;
for element. It made element "really rendered", not just "light rendered".
I'm working on a web page that uses a lot of CSS animations (mostly TranslateY) that are triggered at various scroll positions through JQuery. It works great across Webkit, FF, IE, etc. Unfortunately, on iPhone and iPad, some (but not all) of the elements just don't appear. I'm aware of the differences of 'scrolling' on mobile versus desktop and have confirmed that the class being added to fire the animations is actually getting added.
I plugged the iPad into my desktop and have been using Safari's Mobile Web Inspector to poke around... what's really weird is that I have confirmed that the animations are firing and the divs are moving around, they just aren't visible... UNTIL I add a line of style to the div in the inspector. As soon as I start typing anything, literally even just a blank line, the element appears! This has me totally stumped. I've tried adding a z-index but don't know what else to do.
I'm using Safari 6.1.1, the latest version as of this writing. Also, turning off overflow:hidden; on the parent container has helped, but unfortunately, I need overflow:hidden; for this application.
Any help is appreciated, thanks -
This is how I add the class for the animation:
function getTopHeight() {
return (document.body.scrollTop) ?
document.body.scrollTop :
document.documentElement.scrollTop;
}
$(window).scroll(function() {
// Manage animations on scroll on the 'our story' page.
if (getTopHeight() >= 442){
$('.tree-1').addClass('popup-animation');
} ...
And these are some CSS rules I have surrounding that animation:
.tree-1{
transition: all 0.5s;
-webkit-transition: all 0.5s; /* Safari */
-moz-transition: all 0.5s; /* FF */
}
.popup-animation{
-ms-transform: translateY(-330px);
-webkit-transform: translateY(-330px);
-moz-transform: translateY(-330px);
}
Following some of the solutions on this somewhat related SO question, I was able to solve my problem by adding:
-webkit-transform-style: preserve-3d;
... to the elements being translated.
Most of us know the simple opacity CSS rule, but recently I stumbled upon filter which can have opacity(amount) as it value - among other things. But what exactly is the difference between the two?
filter: opacity() is similar to the more established opacity property; the difference is that with filter: opacity(), some browsers provide
hardware acceleration for better performance. Negative values are not
allowed.
filter: opacity() applies transparency.
A value of 0% is completely transparent. A value of 100% leaves the
input unchanged. Values between 0% and 100% are linear multipliers on
the effect. This is equivalent to multiplying the input image samples
by amount. If the “amount” parameter is missing, a value of 100% is
used.
Source: https://css-tricks.com/almanac/properties/f/filter/
/*
* -----------
* filter: opacity([ <number> or <percentage> ])
* -----------
*/
.filter-opacity {
filter: opacity(0.3);
height: 5rem;
width: 5rem;
background-color: mediumvioletred;
}
/*
* -----------
* standard opacity
* -----------
*/
.just-opacity {
opacity: 0.3;
height: 5rem;
width: 5rem;
background-color: lawngreen;
}
<div class="filter-opacity">
filter-opacity
</div>
<div class="just-opacity">
just-opacity
</div>
I've found some difference between them both, especially in the Chrome browser.
If we set the CSS opacity property to an iframe tag, then we'll not be able to click any links inside this frame (I guess, it's a protection from clickjacking attack) while filter: opacity(0) allows us to click any links. I don't know, maybe it's an omission from Chrome developers' side.
filter in CSS had some different runs, namely for FireFox and MSIE.
In MSIE 5.5 on through 7, filter, also known as Alpha Filter, actually makes use of MSIE's DX Filter (no longer supported). However, in order to be more CSS2.1 compliant, in IE8 MS introduced -ms-filter to replace filter. The syntax is different in that the value of -ms-filter must be encased in quotes. Eventually, IE9 brought deprecation to this method and as of IE10, it is no longer used.
Another interesting note here, if you're wanting full compatibility for older IE, then you must make sure use of filter and -ms-filter must be very specific. For example, the following does not work in IE8 running IE7 compat mode:
element {
filter: alpha(opacity=50);
-ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
}
-ms-filter must come before filter in order to get more out of older IE compatibility.Like so:
element {
-ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
filter: alpha(opacity=50);
}
FireFox made use of filter as an experiment gone awry. I believe the original idea was to mock what IE was doing in using the Direct X engine. There was even a browser specific version, as there was for most browsers at one time. Eventually, HTML5/CSS3 announced use of the filter namespace and it now has a new purpose.
As of CSS3, filter now has a whole new meaning! Firefox docs stay open as if they plan to expand on this, though I've yet to see it (however they do crash JS if your CSS is not to its liking now!). Webkit (which will probably become standard in next update to CSS3) has started to implement filter to the point you can almost "photoshop" images for your site!
Since filter is changing so much, opacity would be the preferred method to use, however, as you can see, to be completely cross-browser compatible means being very thorough.
Browser specific alternates:
-webkit-filter: filter(value);
-moz-filter: filter(value);
-o-filter: filter(value);
-ms-filter: "progid:DXCLASS.Object.Attr(value)";
See Also:
What's compatible with opacity?
What's compatible with the newer filter?
keep in mind, not the same as Older IE's filter
Is there a way to create a fade-in/fade-out effect on mouse over/out respectively that only uses CSS 3?
If there is, would you say that it is a good way to implement such an effect with CSS only or not?
To me, it seems like a presentation only issue so I'm not sure why JavaScript should be involved?
Are you looking for something like this: http://jsfiddle.net/hRuR9/2/ ?
It's pretty simple...
.box{
opacity: 0.0;
-webkit-transition: 0.5s all;
-moz-transition: 0.5s all;
}
.box:hover{
opacity: 1.0;
}
As for whether using it or not is a good idea, it depends on your target audience and which browsers you expect them to use or want to support. Recent versions of Safari, Chrome, and Firefox (and I believe Opera) support it. No idea about recent versions of IE, but you can pretty much forget about the older ones.