CSS3 Transitions: Is "transition: all" slower than "transition: x"? - performance

I have a question about rendering speed for the css3 transition property.
Suppose I have a number of elements:
div, span, a {transition: all}
div {margin: 2px}
span {opacity: .5}
a:hover {background-position: left top}
div:hover {margin: -100px}
span:hover {opacity: 1}
a:hover {background-position: -5px top}
It's much more efficient to target all of the transitions for all of those elements using one declaration div, span, a {transition: all}. But my question is: would it be "faster" in terms of the smoothness and quickness of the animation rendering to target each element's specific transition property? For example:
div {margin: 2px; transition: margin .2s ease-in}
span {opacity: .5; transition: opacity .2s ease-in}
a {background-position: left top; transition: background .2s ease-in}
div:hover {margin: -100px}
span:hover {opacity: 1}
a:hover {background-position: -5px top}
My logic in asking this is that if the css "engine" has to search for "all" transition properties even if there is just one single property for an element, that it might slow things down.
Does anyone know if that's the case? Thanks!

Yes, using transition: all could cause major drawbacks in performance. There can be a lot of cases where the browser would look if it needs to make a transition, even if user won't see it, like the color changes, dimension changes etc.
The simplest example I can think of is this: http://dabblet.com/gist/1657661 — try to change the zoom level or the font's size and you'll see that everything become animated.Of course there couldn't be a lot of such user interactions, but there could be some interface changes that can cause the reflow and repaints in some blocks, that could tell the browser to try and animate those changes.
So, in general, it's recommended that you won't use the transition: all and would use the direct transitions instead.
There are some other things that can go wrong with the all transitions, like the splash of animation on page load, where it would at first render the initial styles for blocks and then apply the style with an animation. In a lot of cases it wouldn't be the thing that you want :)

I've been using all for cases where I needed to animate more than one rule. For example, if I wanted to change the color & background-color on :hover.
But it turns out that you can target more than one rule for transitions, so you never need to resort to the all setting.
.nav a {
transition: color .2s, text-shadow .2s;
}

Related

Trying to make the buttons clickable and canvas to draw on top of background image

I have this jsfiddle script that I am having trouble to do the following:
Respond to button click.
To show the box drawn on the canvas
I know that I could make this work if I add "z-index: -1" to
var sss = `
.container:before {
content: "";
position: absolute;
width: 200%;
height: 200%;
top: -50%;
left: -50%;
background: url("${url}") 50% 50% no-repeat;
-webkit-transition: all 1s;
-moz-transition: all 1s;
-ms-transition: all 1s
-o-transition: all 1s;
transition: all 1s;
}
`;
$(`<style id="dynastyle" type='text/css'>${sss}</style>`).appendTo("head");
But I don't want to do that for a peculiar reason that is too complicated to explain here.
Does anyone know how to get this to work? To be honest, I have no idea why the button is not clickable. enter link description here
Also, I need to be able to draw on top of the canvas. BTW, I don't want to draw the image in the canvas.
After tweaking it for a few hours, I finally got it working. Basically I needed to do the following:
enclosing the buttons in a div that has the position attribute and z-index'd (I used 1, I believe that the default value is 0, giving 1 to the buttons makes it bigger than the 0 for the background image).
place the canvas in a different div and use absolute position to overlay it on top of the div that has the background image and use z-index 1.
When all these two things are done, I can remove the z-index on the dynamic style for the background image. What has giving me a lot of trouble during this was that I keep forgetting to add the position attribute on the elements involved in the layering.

Css transition all Vs specific transition [duplicate]

I have a question about rendering speed for the css3 transition property.
Suppose I have a number of elements:
div, span, a {transition: all}
div {margin: 2px}
span {opacity: .5}
a:hover {background-position: left top}
div:hover {margin: -100px}
span:hover {opacity: 1}
a:hover {background-position: -5px top}
It's much more efficient to target all of the transitions for all of those elements using one declaration div, span, a {transition: all}. But my question is: would it be "faster" in terms of the smoothness and quickness of the animation rendering to target each element's specific transition property? For example:
div {margin: 2px; transition: margin .2s ease-in}
span {opacity: .5; transition: opacity .2s ease-in}
a {background-position: left top; transition: background .2s ease-in}
div:hover {margin: -100px}
span:hover {opacity: 1}
a:hover {background-position: -5px top}
My logic in asking this is that if the css "engine" has to search for "all" transition properties even if there is just one single property for an element, that it might slow things down.
Does anyone know if that's the case? Thanks!
Yes, using transition: all could cause major drawbacks in performance. There can be a lot of cases where the browser would look if it needs to make a transition, even if user won't see it, like the color changes, dimension changes etc.
The simplest example I can think of is this: http://dabblet.com/gist/1657661 — try to change the zoom level or the font's size and you'll see that everything become animated.Of course there couldn't be a lot of such user interactions, but there could be some interface changes that can cause the reflow and repaints in some blocks, that could tell the browser to try and animate those changes.
So, in general, it's recommended that you won't use the transition: all and would use the direct transitions instead.
There are some other things that can go wrong with the all transitions, like the splash of animation on page load, where it would at first render the initial styles for blocks and then apply the style with an animation. In a lot of cases it wouldn't be the thing that you want :)
I've been using all for cases where I needed to animate more than one rule. For example, if I wanted to change the color & background-color on :hover.
But it turns out that you can target more than one rule for transitions, so you never need to resort to the all setting.
.nav a {
transition: color .2s, text-shadow .2s;
}

line-height 2px lower in firefox vs webkit

I have the following css:
.btn_container {
cursor: pointer;
font-family: Tahoma,Verdana,Arial;
font-size: 11px;
padding: 0;
width: auto;
}
.btn_center {
background: blue;
color: #FFFFFF !important;
display: block;
float: left;
font-weight: bold;
height: 32px;
line-height: 32px;
padding: 0 10px;
}
line-height of 30 lines up center in firefox, but 32 in webkit.
I know browsers will render things differently, but i've never had a problem getting text to center properly.
In the following example you can see that it drops a couple px lower in firefox:
http://jsfiddle.net/mstefanko/EGzEB/5/
I've done heavy testing of this in the past. I call it text jiggle. It's not something you can control. All you can do to minimize it is apply an explicit line-height (especially one in px) to every text element.
The default line-height varies by a wide margin in different browsers, and for different font families at different font sizes. Setting an explicit line-height addresses that.
But within that, the exact placement of the text within the line-height space will vary slightly browser-to-browser no matter what you do. For some combinations of font-size and line-height, all browsers match up. For instance, Arial at font-size:11px and line-height:14px renders the same in FF, Webkit, and IE. But change the line-height to 13px or 15px, and it varies by 1px browser-to-browser.
There's no standard or defined behavior for it. It's the result of how that particular font-family, font-size, and line-height happens to be rendered by the browser on that operating system. Arial, for instance, is a relatively consistent font, generally not varying by more than 1px as long as an explicit line-height is defined, while Helvetica varies by as many as 4 to 6 pixels.
I had the opposite experience actually. I noted that some header elements were positioned higher in IE7/compatibility mode as well as Chrome/Safari. So after much trouble I inspected with chrome and saw -webkit-margin-before: 1.6em or something added to the headers. Adding that value and tweaking it didn't work because it effected the height of the header which pushed some elements down but the padding option worked well for me ...
I found that this worked for me:
H1, H2, H3, H4, H5, a.mainTab div {
-webkit-padding-before: 1px;
}
a.mainTab div had spans which wouldn't respond to the padding/margin so wrapped them in a div ... this may work for li span span headers as well.

Transparent Background Image with a Gradient

Today I was designing a transparent PNG background that would only sit in the top left of a div, and the rest of the div would maintain a gradient background for all transparent areas of the PNG, and the rest of the div itself.
It might be better to explain through the code I thought might work:
#mydiv .isawesome {
/* Basic color for old browsers, and a small image that sits in the top left corner of the div */
background: #B1B8BD url('../images/sidebar_angle.png') 0 0 no-repeat;
/* The gradient I would like to have applied to the whole div, behind the PNG mentioned above */
background: -moz-linear-gradient(top, #ADB2B6 0%, #ABAEB3 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#ADB2B6), color-stop(100%,#ABAEB3));
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ADB2B6', endColorstr='#ABAEB3',GradientType=0 );
}
What I've been finding is that most browsers pick one or the other - most choosing the gradient since its further down the CSS file.
I know some of the guys around here will say "just apply the gradient to the PNG you're making" - but thats not ideal because the div will maintain a dynamic height - sometimes being very short, sometimes being very tall. I know this gradient isn't essential but I thought it might be worth asking y'all what you thought.
Is it possible to have a background image, while keeping the rest of the background as a gradient?
Keep in mind that a CSS gradient is actually an image value, not a color value as some might expect. Therefore, it corresponds to background-image specifically, and not background-color, or the entire background shorthand.
Essentially, what you're really trying to do is layering two background images: a bitmap image over a gradient. To do this, you specify both of them in the same declaration, separating them using a comma. Specify the image first, followed by the gradient. If you specify a background color, that color will always be painted underneath the bottom-most image, which means a gradient will cover it just fine, and it will work even in the case of a fallback.
Because you're including vendor prefixes, you will need to do this once for every prefix, once for prefixless, and once for fallback (without the gradient). To avoid having to repeat the other values, use the longhand properties1 instead of the background shorthand:
#mydiv .isawesome {
background-color: #B1B8BD;
background-position: 0 0;
background-repeat: no-repeat;
/* Fallback */
background-image: url('../images/sidebar_angle.png');
/* CSS gradients */
background-image: url('../images/sidebar_angle.png'),
-moz-linear-gradient(top, #ADB2B6 0%, #ABAEB3 100%);
background-image: url('../images/sidebar_angle.png'),
-webkit-gradient(linear, left top, left bottom, color-stop(0%, #ADB2B6), color-stop(100%, #ABAEB3));
background-image: url('../images/sidebar_angle.png'),
linear-gradient(to bottom, #ADB2B6, #ABAEB3);
/* IE */
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#ADB2B6', endColorstr='#ABAEB3', GradientType=0);
}
Unfortunately this doesn't work correctly in IE as it uses filter for the gradient, which it always paints over the background.
To work around IE's issue you can place the filter and the background image in separate elements. That would obviate the power of CSS3 multiple backgrounds, though, since you can just do layering for all browsers, but that's a trade-off you'll have to make. If you don't need to support versions of IE that don't implement standardized CSS gradients, you have nothing to worry about.
1 Technically, the background-position and background-repeat declarations apply to both layers here because the gaps are filled in by repeating the values instead of clamped, but since background-position is its initial value and background-repeat doesn't matter for a gradient covering the entire element, it doesn't matter too much. The details of how layered background declarations are handled can be found here.
You can use Transparency and gradients. Gradients support transparency. You can use this, for example, when stacking multiple backgrounds, to create fading effects on background images.
background: linear-gradient(to right, rgba(255,255,255,0) 20%,
rgba(255,255,255,1)), url(http://foo.com/image.jpg);
The order of the image and gradient is very KEY here, i want to make that clear. The gradient/image combo works best like this...
background: -webkit-gradient(linear, top, rgba(0,0,0,0.5), rgba(200,20,200,0.5)), url('../images/plus.png');
background-image will also work...
background-image: -webkit-gradient(linear, top, rgba(0,0,0,0.5), rgba(200,20,200,0.5)), url('../images/plus.png');
the gradient needs to come first... to go on top. The absolute key here though is that the gradient uses at least 1 RGBA color... the color(s) need to be transparent to let the image come through. (rgba(20,20,20,***0.5***)). putting the gradient first in you css places the gradient on top of the image, so the lower the alpha setting on you RGBAs the more you see the image.
Now on the other hand if you use the reverse order the PNG needs to have transparent properties, just like the gradient, to let the gradient shine through. The image goes on top so your PNG needs to be saved as a 24 bit in photoshop with alpha areas... or a 32 bit in fireworks with alpha areas (or a gif i guess... barf), so you can see the gradient underneath. In this case the gradient can use HEX RGB or RGBA.
The key difference here is the look. The image will be much more vibrant when on top. When underneath you have the ability to tune the RGBA values in the browser to get the desired effect... instead of editing and saving back and forth from your image editing software.
Hope this helps, excuse my over simplification.
This is possible using multiple background syntax:
.example3 {
background-image: url(../images/plus.png), -moz-linear-gradient(top, #cbe3ba, #a6cc8b);
background-image: url(../images/plus.png), -webkit-gradient(linear, left top, left bottom, from(#cbe3ba), to(#a6cc8b));
}
I read about this at Here's One Solution.
UPDATED
* {
margin: 0;
padding: 0;
}
html,
body {
width: 100%;
height: 100%;
}
.hero {
width: 100%;
height: 100%;
min-width: 100%;
min-height: 100%;
position: relative;
}
.hero::before {
background-image: url(https://images.unsplash.com/photo-1566640269407-436c75fc9495?ixlib=rb-1.2.1&ixid=eyJhcHBfaWQiOjEyMDd9&auto=format&fit=crop&w=750&q=80);
background-size: cover;
content: "";
display: block;
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
z-index: -2;
opacity: 0.4;
}
<div class="hero flex-center">
<div class="hero-message">
<h1 class="hero-title">Your text</h1>
<h1 class="hero-sub-title">Your text2</h1>
</div>
</div>
<div class="not-hero flex-center bg-info">
<div class="not-hero-message">
<h1 class="hero-title">Your text</h1>
</div>
</div>
** It's working**
Transparent images are not yet a CSS standard, yet they are supported by most modern browsers. However, this is part of the W3C CSS3 recommendation. Implementation varies from one client to another, so you will have to use more than one syntax for cross-browser compatibility.
http://www.handycss.com/effects/transparent-image-in-css/

CSS3 Continuous Rotate Animation (Just like a loading sundial)

I am trying to replicate an Apple style activity indicator (sundial loading icon) by using a PNG and CSS3 animation. I have the image rotating and doing it continuously, but there seems to be a delay after the animation has finished before it does the next rotation.
#-webkit-keyframes rotate {
from {
-webkit-transform: rotate(0deg);
}
to {
-webkit-transform: rotate(360deg);
}
}
#loading img
{
-webkit-animation-name: rotate;
-webkit-animation-duration: 0.5s;
-webkit-animation-iteration-count: infinite;
-webkit-transition-timing-function: linear;
}
I have tried changing the animation duration but it makes no difference, if you slow it right down say 5s its just more apparent that after the first rotation there is a pause before it rotates again. It's this pause I want to get rid of.
Any help is much appreciated, thanks.
Your issue here is that you've supplied a -webkit-TRANSITION-timing-function when you want a -webkit-ANIMATION-timing-function. Your values of 0 to 360 will work properly.
You also might notice a little lag because 0deg and 360deg are the same spot, so it is going from spot 1 in a circle back to spot 1. It is really insignificant, but to fix it, all you have to do is change 360deg to 359deg
my jsfiddle illustrates your animation:
#myImg {
-webkit-animation: rotation 2s infinite linear;
}
#-webkit-keyframes rotation {
from {-webkit-transform: rotate(0deg);}
to {-webkit-transform: rotate(359deg);}
}
Also what might be more resemblant of the apple loading icon would be an animation that transitions the opacity/color of the stripes of gray instead of rotating the icon.
You could use animation like this:
-webkit-animation: spin 1s infinite linear;
#-webkit-keyframes spin {
0% {-webkit-transform: rotate(0deg)}
100% {-webkit-transform: rotate(360deg)}
}
If you're only looking for a webkit version this is nifty: http://s3.amazonaws.com/37assets/svn/463-single_spinner.html from http://37signals.com/svn/posts/2577-loading-spinner-animation-using-css-and-webkit
Your code seems correct. I would presume it is something to do with the fact you are using a .png and the way the browser redraws the object upon rotation is inefficient, causing the hang (what browser are you testing under?)
If possible replace the .png with something native.
see; http://kilianvalkhof.com/2010/css-xhtml/css3-loading-spinners-without-images/
Chrome gives me no pauses using this method.
I made a small library that lets you easily use a throbber without images.
It uses CSS3 but falls back onto JavaScript if the browser doesn't support it.
// First argument is a reference to a container element in which you
// wish to add a throbber to.
// Second argument is the duration in which you want the throbber to
// complete one full circle.
var throbber = throbbage(document.getElementById("container"), 1000);
// Start the throbber.
throbber.play();
// Pause the throbber.
throbber.pause();
Example.

Resources