I'm looking at CSS transitions, in particular which CSS properties can be transitioed and their respective browser support. Struggling to find anything comprehensive on google.
I believe that not all CSS properties are transitional. For example, background: isn't, but background-color: and background-image: are.
Would this mean that CSS transitions only work on long-hand syntax? Or perhaps this example is just an exception.
Does anyone have a comprehensive list of properties that can be transitioned?
Would this mean that CSS transitions only work on long-hand syntax? Or perhaps this example is just an exception.
It works on shorthand properties, but only for specific longhand components that are animatable. This is mentioned in the CSS Transitions spec.
If you specify transition-property: background, for example, it will work, but only background-color, background-position and background-size, as well as gradient values in background-image, will be animated, and they will all animate according to the delay, timing function and duration specified for the background transition.
I suspect asking for links to lists of properties might be off-topic here, but for what it's worth, MDN contains a list of animatable properties.
For most properties, whether or not — and how — they're animatable is also described in their respective propdefs (specifications). For example, the definition of border-radius can be in the Backgrounds and Borders module:
Animatable: as two values of length, percentage, or calc
Like background-image, border-radius is a shorthand property, made up of four components (one for each corner). You can transition all four corners the exact same way by simply specifying transition-property: border-radius, and exactly one delay, timing function and duration.
There is animatable-properties package on npm based on the MDN list.
animatable.propertiesCSS is an array containing all the animatable properties in CSS format.
You can also get a list of them sorted by usage popularity based on Chrome's anonymous usage statistics.
console.log('First 10 properties by usage statistics:', animatable.popular())
console.log('All properties sorted alphabetically:', animatable.propertiesCSS)
<script src="https://unpkg.com/animatable-properties"></script>
The package also provides syntax for each property and ability to validate that syntax.
Related
First of all, I did use Google and SOF Advanced search but I didn't find this question.
Now to my question:
I know that initial sets the shadow to default i.e none.
Then what is the difference between these two keywords WHEN APPLIED TO BOX-SHADOW PROPERTY.
For some properties, none doesn't work so that time it is understood but it doesn't make sense in box-shadow and other such properties.
And I did read w3schools initial keyword page completely and I made this thread after reading that so please don't stick me that. :)
Please help me clear my doubt. :)
There is no difference according to CSS specifications and drafts. However, there is a practical difference, because not all browsers support the initial keyword. Such browsers ignore a declaration with the value initial. (If no other style sheet sets the property for an element, then the valus of the property is still its initial value.)
According to the CSS Values and Units Module Level 3 CR, initial “represents the specified value that is designated as the property's initial value”. For the box-shadow property, this value is none.
This question already has answers here:
What is the difference between background and background-color
(17 answers)
Closed 8 years ago.
What is this best practice to use that's most compatible across multiple browsers:
background:#ffffff;
or
background-color:#ffffff;
or is it best to use both to cover more:
background:#ffffff;
background-color:#ffffff;
There's no difference about compatibility. The only difference is that using background you could add several properties in the same line, as you probably know, instead of repeating background-color, backgroud-image etc in different lines.
To set the color, you can use either of these.
As per W3C Standards, we shall follow the background-color property. However, if you follow this, you will be only able to add color and not other options like size, image, attachment etc.
I would suggest you to go for standard format as it is easy for others to clearly read about the properties.
You can learn more about the background property from:
W3C Schools - Background Property
I prefer background-color. My first reason is readability because in a first glance you can know what's the purpose of that style. When you use plain "background" you can define many properties inside it which makes it more complicated to read.
Background: color position/size repeat origin clip attachment image|initial|inherit;
versus background-color: color|transparent|initial|inherit;
And ie is not fully compatible with all background properties:
Note: IE8 and earlier do not support multiple background images on one
element.
Good luck!!
It doesn't really matter if you use background or background-color since background is a prefix/shortcut to:
-color
-image
-position
-attachment
-repeat
Its just that using background can let you add its additional css properties to prevent repetition of declarations. It is one of the basics of CSS. But if you are only going to change the color of the background and nothing else, I recommend you use background-color.
Do the "::before" and "::after" pseudo elements not work on image elements?
Here's an example I put together...I'm just trying to get a yellow background behind the image here:
http://dabblet.com/gist/3861878
I saw this "answered" (but no other details) in another post, but can't seem to find anything about it elsewhere.
CSS 2.1 spec says:
Note. This specification does not fully define the interaction of
:before and :after with replaced elements (such as IMG in HTML). This
will be defined in more detail in a future specification.
http://www.w3.org/TR/CSS21/generate.html
So it it'd be wise to avoid using this. Behavior across the browsers is uncertain and can change in future.
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/
It seems that both of them could make the element move from its current position. Are these two methods interchangeable?
The two methods are not exactly the same thing: Translating an element will not require to change its top, left, right or bottom CSS properties, so in the same way offsetTop/offseLeft Javascript properties are not affected by a CSS translation. Beside, the position of the element could be also static (and thus no z-index is required)
If you use position: relative instead, you will change those properties to visually achieve the same effect.
Example Fiddle: http://jsfiddle.net/LkLey/
Of course if you have to deal with old browser (like IE8 or FF2) the necessary choice is relative positioning, otherwise I can't see a clear convenience on choosing one of the two methods (well, to be honest relative positioning has no need of multipe prefixes -moz-, -webkit- ... to work everywhere) so the choice is up to you (and it depends on the layout).