I've started using LESS for CSS lately and was wondering if my method is the correct way to target multiple vendor prefixes by creating my own LESS "mixin" (I think)?
.transition (#transition: 1s) {
transition: #transition;
-webkit-transition: #transition;
-moz-transition: #transition;
}
So if I were for example to have a .btn class and call .transition (which works)
.btn:hover {
color: red;
.transition(#transition: 1s ease-in);
}
And for animations.
#animate-fadein: fadeIn 1.7s linear;
.animation (#animation: fadeIn .2s linear) {
animation: #animation;
-webkit-animation: #animation;
-moz-animation: #animation;
-o-animation: #animation;
}
.btn
.btn {
#animation(#animation: fadeIn .2s linear);
}
This method works by the way. I'm just curious. Is my method over-complicating things and or am I just reinventing the wheel?
Well, using mixins help you to code more DRY (Don't repeat yourself), so that's good and the main reason why you should use Less.
When your requirements change ( different browser to support) you will only have to change your mixins (which you can share over your projects too).
Notice that there are many mixin libraries to find on the web which have already create these prefix mixins for you. See: http://lesscss.org/usage/#frameworks-using-less-mixin-libraries
As already mentioned by #seven-phases-max, nowadays most people use autoprefix postprocessors to prefix their mixins. Also Bootstrap have integrate the autoprefixer into their Grunt build process in favor of the prefix mixins (since version 3.2). The only disadvantage of the most popular autoprefix postprocessor (https://github.com/postcss/autoprefixer) will be that it require Node.js installed and can not be used with some alternative compilers.
Since version 2 of Less its easy to use plugins. Less provide you an autoprefix plugin too. This plugin can be installed by running npm install -g less-plugin-autoprefix. After installing you can run for instance lessc --autoprefix="last 2 versions" main.less.
The Less autoprefix plugin an not use when compiling your Less code client side with the less.js compiler. -prefixfree seem to be a reasonable alternative when compiling Client side.
Last note about your vendor prefixes in some situations a [Graceful degradation strategy] (https://www.w3.org/community/webed/wiki/Optimizing_content_for_different_browsers:_the_RIGHT_way#Graceful_degradation) will be better than trying to support even the most old browser with newest technologies.
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)
SO, here my first mixin
.3transitions (#value1,#value2,#value3,#duration){
#value: ~"#{value1},#{value2},#{value3}";
.transition-property(#value);
.transition-delay(0);
.transition-duration(#duration);
.transition-timing-function(ease);
}
and here is the second (among many others)
.transition-property(#transition-property) {
-webkit-transition-property: #transition-property;
transition-property: #transition-property;
}
On webkit browsers I should get the compiled CSS with proper browser prefix, but I get
-webkit-transition-property: margin-top,opacity,transform;
instead of
-webkit-transition-property: margin-top,opacity,-webkit-transform;
How can I go around this please? Is there a way to determin in LESS that I am using a CSS3 style?
Since Less v2, it become easy to use plugins. The autoprefix plugin post-processed your Less code by autoprefixer.
You can install the autoprefix plugin by running the following command in the console:
npm install -g less-plugin-autoprefix
After installing the plugin you should be able to run for in stance the following command:
echo "element{ transition-property: margin-top,opacity, transform; }" | lessc - --autoprefix="last 20 versions"
The preceding command will compile into CSS code as follows:
element {
-webkit-transition-property: margin-top, opacity, -webkit-transform;
-moz-transition-property: margin-top, opacity, -moz-transform;
-o-transition-property: margin-top, opacity, -o-transform;
transition-property: margin-top, opacity, transform;
}
You can not use this autoprefix plugin when compiling your Less code client side in the browser. For client side in browser compiling you can consider to use -prefixfree This Javascript library add browser’s prefix to any CSS code leveraging Javascript.
When you can not run the autoprefix which requires Node installed, for instance those who compile Less with one of the alternative compilers, you should fall-back to prefix mixins such as that found here written by #seven-phases-max. Better you should not reinvent the wheel and try one of the mixin libraries that already fix the prefix problems for you.
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;
}
I recently downloaded sublime text 3 along with autoPrefixr. I got node.js and made sure it is in the $PATH. I restarted sublime text, yet when i try to run autoPrefixr, it only adds like 10 lines of code to my 150 lines of css. I know it's not doing it's job because I see nothing about -moz- or -o-. Please help as soon as possible, and thanks in advance.
Look for -webkit- prefixes. The reason you're not seeing very many changes is that, by default, the settings are to support the last two versions of each browser. Recent versions of Firefox and Opera don't require the -moz- and -o- prefixes, respectively, to many CSS items, which is the reason you're not seeing them.
To test earlier versions of Firefox and Opera, first create the following generic CSS:
body {
transition: all 1s ease-out;
}
p {
transform: skewx(10deg) translatex(150px);
}
Then, go to Preferences -> Package Settings -> Autoprefixer -> Settings - User and set its content to the following:
{
"browsers": ["last 2 versions", "> 10%", "ff > 4", "opera > 9"]
}
This adds support for the last two versions of any browser, any version with greater than 10% market share, Firefox versions 4 and above, and Opera versions 9 and above.
Save this content, go back to your test CSS file, and run Autoprefix CSS from the Command Palette. You should now get the following:
body {
-webkit-transition: all 1s ease-out;
-moz-transition: all 1s ease-out;
-o-transition: all 1s ease-out;
transition: all 1s ease-out;
}
p {
-webkit-transform: skewx(10deg) translatex (150px);
-moz-transform: skewx(10deg) translatex (150px);
-o-transform: skewx(10deg) translatex (150px);
transform: skewx(10deg) translatex (150px);
}
For more (brief) details about the settings, check the README.
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.