What mind is behind this prioritize of CSS3 cross browser?
for example:
.box_scale {
-webkit-transform: scale(0.8); /* Chrome, Safari 3.1+ */
-moz-transform: scale(0.8); /* Firefox 3.5+ */
-ms-transform: scale(0.8); /* IE 9 */
-o-transform: scale(0.8); /* Opera 10.50-12.00 */
transform: scale(0.8); /* Firefox 16+, IE 10+, Opera 12.10+ */
}
first is -webkit-, second is -moz-, third is -ms- forth is -o- and at the end without any prefix. what is the point of this prioritize ? or this is not matter which one is first?
You can see an inverted staircase in the property names, starting with the longest (-webkit-) and ending with the shortest (-o-) and the unprefixed property, supported by indenting the declarations so that the colons and values line up.
Other than that there is no practical meaning to the order of prefixes — you can mix and match the order of your prefixes however you like, with one exception: the unprefixed property always comes last because it's the standardized version of the property, and you want browsers to choose to use that over their prefixed version to ensure you get the most standards-compliant behavior for that property.
The order is irrelevant as the selectors target specific browsers. Most people chose this method purely because it looks better than writing them without tabs.
Well as browsers ignore css codes they don't understand, so the order is not important. browser will use the one it understands and will ignore the others.
Related
If a designer is using a fancy css animation and hopes to have functionality in older and newer browsers, we usually create a #keyframes and a #-webkit-keyframes section. Most of the examples I have seen use both non-prefixed and browser prefixed css under both keyframes, but is this necessary.
#keyframes coolEffect {
-webkit-transform: some value;
transform: some value;
-webkit-animation-timing-function: some value;
animation-timing-function: some value;
}
#-webkit-keyframes coolEffect {
-webkit-transform: some value;
transform: some value;
-webkit-animation-timing-function: some value;
animation-timing-function: some value;
}
Do we need non-prefixed values in the #-webkit-keyframes, since a browser using that would also use -webkit- prefixed css? And likewise since we are using #-webkit-keyframes, do we need to include -webkit- prefixed css in the main #keyframes? Would a simpler smaller version work equally as well?
#keyframes coolEffect {
transform: some value;
animation-timing-function: some value;
}
#-webkit-keyframes coolEffect {
-webkit-transform: some value;
-webkit-animation-timing-function: some value;
}
To clarify, I am not asking about what would work for my particular website, I am asking about functionality and whether or not code sample two would work the same as code sample one.
Thanks.
From my answer to this similar question:
WebKit-based browsers (including Opera 15 and later) still require the -webkit- prefix for animations today, and transforms are only unprefixed in recent versions of Chrome. You will need the prefix for both features.
(Transforms were unprefixed in Chrome 36; animations were not unprefixed until Chrome 43. Both features were unprefixed simultaneously in Safari 9 so you never need to worry about prefixed/unprefixed overlap in Safari.)
In a nutshell, while your two samples don't provide exactly the same functionality, there is no point including any unprefixed properties in #-webkit-keyframes as most WebKit browsers that depend on the prefixed at-rule are never going to need the unprefixed properties. Specifically, from our chat discussion:
You can lose the unprefixed [animation-timing-function] declaration. #keyframes is in the same family as the animation-* properties and no browser in existence supports one unprefixed without the other
As for transforms, only a very fringe few browsers simultaneously support unprefixed transforms and require prefixes on animations. These browsers do still support prefixed transforms, so similarly you can lose unprefixed transforms in #-webkit-keyframes
Note the difference between "support" and "require"
So, code sample two is all you need. It's over 40% smaller than code sample one, with no loss of functionality. 40% is a big deal. The only change I'd make is move the #-webkit-keyframes rule up:
#-webkit-keyframes coolEffect {
-webkit-transform: some value;
-webkit-animation-timing-function: some value;
}
#keyframes coolEffect {
transform: some value;
animation-timing-function: some value;
}
Readers may also be interested in my comments on Autoprefixer:
I assume Autoprefixer sees that Chrome 36-42 supports unprefixed transforms but requires prefixed animations, so it puts transform in #-webkit-keyframes. I don't think that's a good approach. It needlessly doubles the transform declarations. All those versions of Chrome still understand -webkit-transform, so might as well stick to just that
Autoprefixer is good for those who just don't want to have to worry about prefixes or doing all the research needed to really optimize their stylesheets
If you want to optimize your stylesheet, you'll need to do quite a bit of research to find out where prefixes are needed and where they aren't, where unprefixed declarations are needed and where you can leave them out, etc. Prefixes are a pain either way ;)
No. All modern browsers, even going back to IE10, support unprefixed animations.
(source)
I would like to start using the CSS3 filter:opacity() and filter:drop-shadow() properties that are currently under development, as I read that they are hardware accelerated in some browsers on some machines. But at this early point I definitely need a fallback to normal CSS properties like opacity and box-shadow.
Problem is, that the normal CSS fallback strategy of placing new after old fails. Normally new (if supported) would overwrite old. But in this case new and old are completely different properties that will combine! The CSS declaration...
.half-transparent{
opacity: 0.5;
-webkit-filter: opacity(0.5);
filter: opacity(0.5);
}
...will result in a total opacity of 25% instead of 50%.
Example: https://jsfiddle.net/uq4ybvk8/
Is there any way (preferably CSS only) to create a fallback from the new filter properties to well established CSS properties?
The support for filter (with and without prefix) should overlap pretty nicely with support for the Conditional Rules module (#supports), with the exception of older versions of Safari/iOS (before Safari 9). If you treat it as an enhancement (i.e. with a fallback to regular opacity for other browsers), that shouldn't be a big issue. Try something like this, perhaps?
.half-transparent {
opacity: 0.5;
}
#supports ((filter: opacity(0.5)) or (-webkit-filter: opacity(0.5))) {
.half-opacity {
opacity: 1;
-webkit-filter: opacity(0.5);
filter: opacity(0.5);
}
}
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
I have the following css rules:
-webkit-transform: scale(0.5); /* Saf3.1+, Chrome */
-moz-transform: scale(0.5); /* FF3.5+ */
-ms-transform: scale(0.5); /* IE9 */
-o-transform: scale(0.5); /* Opera 10.5+ */
transform: scale(0.5);
Which I intend to apply to a div in order to scale it, including all its contents, images, etc, to 50% its size while keeping the same center. As you probably know the rules I listed do exactly that, except for IE7-8.
According to this site, the equivalent, MS proprietary rule would be:
/* IE8+ - must be on one line, unfortunately */
-ms-filter: "progid:DXImageTransform.Microsoft.Matrix(M11=0.5, M12=0, M21=0, M22=0.5, SizingMethod='auto expand')";
/* IE6 and 7 */
filter: progid:DXImageTransform.Microsoft.Matrix(
M11=0.5,
M12=0,
M21=0,
M22=0.5,
SizingMethod='auto expand');
However these don't seem to actually resize the contents of the div, it seems to shift its position but that is all.
CSS3Please.com reports different matrix values to be the equivalent for scale(0.5):
filter: progid:DXImageTransform.Microsoft.Matrix(/* IE6–IE9 */
M11=0.9999619230641713, M12=-0.008726535498373935, M21=0.008726535498373935, M22=0.9999619230641713,SizingMethod='auto expand');
I've tested these aswell, but the effect was the same; the div seemed to change its position, but the actual size of its contents remained unchanged.
Finally I've tried transformie.js, which calculates the matrix via sylvester.js automatically as you assign the transform property, but the end result was still:
M11=0.5, M12=0, M21=0, M22=0.5
Exactly the same as the one I tried first, which seemingly did do nothing other than shift the position of the div.
I would try cssSandpaper.js, but it looks pretty bloated for what I intend to do, plus there's no jQuery port and I don't feel like adding cssQuery to the project only for that. Chances are the results would be the same as what transformie.js generates though, because it seems to use sylvester.js aswell.
Edit: I also tried this which seems to come from microsoft directly, and suggests the following matrix calculation method:
function resizeUsingFilters(obj, flMultiplier) {
// If you don't do this at least once then you will get an error
obj.style.filter = "progid:DXImageTransform.Microsoft.Matrix(M11='1.0', sizingmethod='auto expand')";
// Resize
obj.filters.item(0).M11 *= flMultiplier;
obj.filters.item(0).M12 *= flMultiplier;
obj.filters.item(0).M21 *= flMultiplier;
obj.filters.item(0).M22 *= flMultiplier;
}
Unfortunately this does not scale the contents of the div itself either. It looks like this may not be possible at all, but:
How can the modern transform: scale be simulated in IE8-7, in such a way that it actually resizes inner div contents aswell?
Perhaps I'm looking for something that doesn't exist, but I wanted to be sure. All the tests have been done using IE9 in compatibility mode for IE8 and IE7 (so far it has always done the job, I don't believe it's unreliable but feel free to correct me if you think otherwise)
I'm a little confused by your explanation. This fiddle in IE7-8 scales the inner elements down for me just fine with the first set of code you posted (though you indicate it was not scaling, only changing position). What that code does not do (and cannot do) is scale it from the center point (it is from the upper left), and the matrix transform cannot accommodate a translation (it only "Resizes, rotates, or reverses the content of the object"), so it is not "keeping the same center" as you indicate you desire.
There is a page I found similar to the transformie.js you noted in performing transform, but this other page speaks to the issue of the transform origin being centered. Ultimately, to get the appearance of being scaled on center, you must include a calculation of some kind to do a shift of the element using position: relative.
In this fiddle I've made it easy on myself to do such a calculation manually by setting a width on the wrapping div and knowing the height based on the inner sizes. This could get complicated with any dynamic sizing, but the link above I believe gives the calculations to do it dynamically using javascript (JQuery) with the sylvester.js as well.
You can also use IE's zoom property:
zoom: 0.5
This should do what you want it to do.
I want to rotate the DIV to a certain degree. In FF it functions but in IE I am facing a problem.
For example in the following style I can set rotation=1 to 4
filter: progid:DXImageTransform.Microsoft.BasicImage(rotation=1);
This means that the DIV will be rotated to 90 or 180 or 270 or 360 degree. But if I need to rotate the DIV only 20 degrees, then it doesn't work anymore.
How may I solve this problem in IE?
To rotate by 45 degrees in IE, you need the following code in your stylesheet:
filter: progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand', M11=0.7071067811865476, M12=-0.7071067811865475, M21=0.7071067811865475, M22=0.7071067811865476); /* IE6,IE7 */
-ms-filter: "progid:DXImageTransform.Microsoft.Matrix(SizingMethod='auto expand', M11=0.7071067811865476, M12=-0.7071067811865475, M21=0.7071067811865475, M22=0.7071067811865476)"; /* IE8 */
You’ll note from the above that IE8 has different syntax to IE6/7. You need to supply both lines of code if you want to support all versions of IE.
The horrible numbers there are in Radians; you’ll need to work out the figures for yourself if you want to use an angle other than 45 degrees (there are tutorials on the internet if you look for them).
Also note that the IE6/7 syntax causes problems for other browsers due to the unescaped colon symbol in the filter string, meaning that it is invalid CSS. In my tests, this causes Firefox to ignore all CSS code after the filter. This is something you need to be aware of as it can cause hours of confusion if you get caught out by it. I solved this by having the IE-specific stuff in a separate stylesheet which other browsers didn’t load.
All other current browsers (including IE9 and IE10 — yay!) support the CSS3 transform style (albeit often with vendor prefixes), so you can use the following code to achieve the same effect in all other browsers:
-moz-transform: rotate(45deg); /* FF3.5/3.6 */
-o-transform: rotate(45deg); /* Opera 10.5 */
-webkit-transform: rotate(45deg); /* Saf3.1+ */
transform: rotate(45deg); /* Newer browsers (incl IE9) */
Edit
Since this answer is still getting up-votes, I feel I should update it with information about a JavaScript library called CSS Sandpaper that allows you to use (near) standard CSS code for rotations even in older IE versions.
Once you’ve added CSS Sandpaper to your site, you should then be able to write the following CSS code for IE6–8:
-sand-transform: rotate(40deg);
Much easier than the traditional filter style you'd normally need to use in IE.
Edit
Also note an additional quirk specifically with IE9 (and only IE9), which supports both the standard transform and the old style IE -ms-filter. If you have both of them specified, this can result in IE9 getting completely confused and rendering just a solid black box where the element would have been. The best solution to this is to avoid the filter style by using the Sandpaper polyfill mentioned above.
You'll need to do a matrix transform as follows:
filter: progid:DXImageTransform.Microsoft.Matrix(
M11 = COS_THETA,
M12 = -SIN_THETA,
M21 = SIN_THETA,
M22 = COS_THETA,
sizingMethod = 'auto expand'
);
-ms-filter: "progid:DXImageTransform.Microsoft.Matrix(
M11 = COS_THETA,
M12 = -SIN_THETA,
M21 = SIN_THETA,
M22 = COS_THETA,
SizingMethod = 'auto expand'
)";
Where COS_THETA and SIN_THETA are the cosine and sine values of the angle (i.e. 0.70710678 for 45°).
There exists an on-line tool called IETransformsTranslator. With this tool you can make matrix filter transforms what works on IE6,IE7 & IE8. Just paste you CSS3 transform functions (e.g. rotate(15deg) ) and it will do the rest.
http://www.useragentman.com/IETransformsTranslator/
http://css3please.com/
Scroll down to '.box_rotate' for the Microsoft IE9+ prefix.
Similar discussion here: Rotating a Div Element in jQuery
Just a hint... think twice before using "transform: rotate()", or even "-ms-transform :rotate()" (IE9) with mobiles!
I've been knocking hard to the wall for days. I have a 'kinetic' system going on, that slides images and, on top of it, a command area. I did "transform" on an arrow button so it simulates pointing up and down... I've reviewd the 1.000 plus code lines for ages!!! ;-)
All ok, once I removed transform:rotate from the CSS.
It's a bit (not to use bad words) tricky the way IE handles it, comparing to other borwsers.
Great answer #Spudley! Thanks for writing it!
Usefull Link for IE transform
This tool converts CSS3 Transform properties (which almost all modern browsers use) to the equivalent CSS using Microsoft's proprietary Visual Filters technology.
For IE11 example (browser type=Trident version=7.0):
image.style.transform = "rotate(270deg)";