What is the equivalent of
-webkit-transition: opacity 0.6s linear;
in -moz?
I tried replacing -webkit with -moz, but nothing happened. I even tried extending it to -moz-transition-property/duration, but with no success.
Try it in Firefox 3.7 (Gecko 1.9).
There isn’t one. CSS animation properties like transition were pretty much invented by Apple (although I think they’ve submitted them for inclusion on CSS3), and they’ve only been implemented in WebKit so far.
There is some support in the nightly builds of Firefox though: http://blog.mozbox.org/post/2009/10/12/Some-new-demos
Related
I'm using gulp with postcss/autoprefixer and have the browserlists list set up as a .browserslistrc file and that's all working well but when it comes to Safari and using flexbox I'm still getting this issue...
Safari then completely ignores flexbox as it seems to have an issue with the display duplication. I have the browserslist query set as Last 2 versions.
Any thoughts?
Ran into this issue myself, ended up playing around and figured out if you put the css properties in the correct order it seems to solve the problem:
display: flex;
display: -ms-flexbox;
display: -webkit-flex;
If you write #keyframes in a css file in IntelliJ IDEA it suggests you animation names like blink, dance, fadein, fadeout etc.
Is it just a name suggestion function? Can I get the implementations behind these names somehow from IDEA? I guess you have the same functionality in Webstorm too.
WebStorm and IDEA are collecting all #keyframe names in the project during indexing. All these names are suggested in completion when you write #keyframes or animation-name:.
Showing an implementation behind a suggested name is not implemented yet (WebStorm 2016.3.3). I've filed a feature request about it, you may want to vote for it to get updates on its progress: https://youtrack.jetbrains.com/issue/WEB-25641
The latest compiled css for Bootstrap V3.3.0 (and at least the previous version) contains some unusual syntax for the line-height in a few places. Can anyone explain it? Needless to say, it causes Resharper to spit the dummy...
input[type="month"] {
line-height: 34px;
line-height: 1.42857143 \0; <<<-- here. the '\0' is what bothers me
}
You will find it around line 2408 in the css.
Also noteworthy is the repeat definition, with and without units. What browser 'feature' does this rectify?
See this issue on GitHub and this question on SO
Its a CSS hack specific to IE, it will only apply to IE10 and under. \9 would apply to IE9 and under etc... All other browsers will ignore it and keep 34px line-height.
I am getting following error while trying to run an html5 file on opera 12 browser :
-webkit-transition is an unknown property
-webkit-transition: opacity 0.5s ease-in-out 0s;
-----------------------^ Linked-in stylesheet mycsspage.css:21
How to resolve this?
Thanks
Sneha
If a property starts with -webkit- it means you're using some experimental code that will normally only work in WebKit-based browsers (Safari, Chrome) and cause errors or warnings everywhere else.
In noticing this error and asking the question you've done the right thing though - now you can learn a few simple things about how CSS is developed and how to use experimental and upcoming features safely.
First: why is this code "experimental"? It's because the experienced web developers and computer specialists who sit down together to plan new features for CSS are still trying to figure out how it should work exactly. Over time they try different keywords and syntaxes (discussing details like 'should it say "ease-in-out" or "in-out"?'). While doing so they also want some testing in the real world and feedback from real developers, so they encourage web browsers like Chrome and Opera to support stuff that's unfinished - but with a prefix. The prefix -webkit- then means "this is a temporary implementation, we're not sure that any other browser will ever understand the "ease-in-out" instruction because we haven't finished deciding this, but you can test it as long as you understand it's temporary and you may have to go back and fix your code later, if we change our mind".
To do this correctly, you need to do a bit of research on whether this CSS feature is still experimental. You're trying to use CSS transitions, so you might for example take a look at this:
http://caniuse.com/#feat=css-transitions
Here you see a table of browsers and versions. You see which versions require a prefix like -webkit- , -ms- , -moz- or -o- (for Safari/Chrome, Internet Explorer, Firefox and Opera respectively).
In this case, the most recent versions of Internet Explorer, Firefox and Opera support this CSS instruction without a prefix, which basically means "we think we're done discussing this now, pretty sure it's going to be like this forever. If you write just 'transition' now you won't have to come back and fix your code because we changed our mind."
On the other hand, WebKit-based browsers still require a -webkit- prefix. So what you should do is to make sure you add this instruction twice - once with a -webkit- prefix, followed by one line without the prefix. Like this:
-webkit-transition: opacity 0.5s ease-in-out 0s;
transition: opacity 0.5s ease-in-out 0s;
If you feel very thorough and want to support older Firefox and Opera versions you could also add the -moz- and -o- lines.
If you make sure the code looks like that, you can now ignore the warnings. You've dealt with the problem it was warning you against.
Hey there,
this time I have a quite rare issue that's occurring only in Safari 5.0.2. When using CSS3's box-shadow parameter, Safari's performance is that bad, you can't even scroll down properly or interact as expected with the site.
I have a <div class="blox"></div> which has an average size (960x320 pixels), and these are its relevant CSS settings:
-moz-border-radius: 4px; /* FF1+ */
-webkit-border-radius: 4px; /* Saf3-4 */
border-radius: 4px; /* Opera 10.5, IE9, Saf5, Chrome */
-moz-box-shadow: inset 0px 0px 140px #dfe1e2; /* FF3.5+ */
-webkit-box-shadow: inset 0px 0px 140px #dfe1e2; /* Saf3.0+, Chrome */
box-shadow: inset 0px 0px 140px #dfe1e2; /* Opera 10.5, IE9 */
I tried setting the CSS3 box-shadow with jQuery (.css()) but the outcome was the same (lag). Oh and, the border-radius does not cause this (I've discarded it by testing it several times).
So, is there any solution to this? Honestly, I am shocked that a WebKit browser such as Safari even presents these sorts of issues. I know there must be a way, since several websites use inset&outset shadows and run just fine in Safari. I found a post here in StackOverflow which mentioned the box-image as a solution.. however, that post was quite old.
I really, really appreciate your time and any support given.
Thank you so much in advance!
Chris
This is a known issue. Follow issue 22102 in the WebKit bug tracker (“-webkit-box-shadow causes awful scroll/resize/redraw performance”) to get notified when it’s fixed.
Note that the box shadow in your example has a very large radius, which makes it worse. This explains why it might seem to work on other sites — they’re just using smaller radii.
Why are you shocked? Webkit might be fast in implementing new stuff, but it does so in extremely buggy ways most of the time.
Anyway, it looks like you're trying to fake a gradient with box-shadow. Better consider using a CSS3 gradient (Moz syntax | Webkit syntax | Opera support coming soon and will follow the moz syntax with an -o- prefix) or an image background.
Also, there is no box-image CSS property. They might have meant border-image.