I am using this tab switcher for my website together with a custom map by MapBox
TabSwitcherCode
MapBox supplies me with this code to embed in my HTML
<iframe
width='100%' height='500px' frameBorder='0' src='https://a.tiles.mapbox.com/v3/ionious.gejgm43n/mm/zoompan,zoomwheel,geocoder.html?secure=1#11/35.8679/14.4539'>
</iframe>
Now what I tried is posting that iframe on line 17 (before the /div) of the TabSwitcher.
This was also pasted in line 21 (before the /div) of the TabSwitcher.
After hitting run the iframe maps appear. However when click-interacting with the second map (the one in line 21) everything acts funny and the style gets messed up!
After a long time debugging I realised that the following CSS transition was the culprit of this behaviour:
.tabs {
position: relative;
-webkit-transition: all .3s ease-in-out;
-moz-transition: all .3s ease-in-out;
-ms-transition: all .3s ease-in-out;
-o-transition: all .3s ease-in-out;
transition: all .3s ease-in-out;
}
Without it both maps work fine. But that nice transition is lost...
Has anyone encountered something similar to this? Note: This only occurs in Chrome
Thanks and regards.
I did not have a lot of time to look into this but perhaps, you can resolve that by using the MapBox API and parse the results from JavaScript. The API is currently in a state where you have to get in contact with MapBox though.
This should help you get away from problems related to iframe implementations in browsers.
Regards,
Daniel
Related
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.
According to caniuse.com, for those browsers that support both CSS transition and CSS transform, combinatorically there are at least three different types:
Those that require the -webkit- prefix on both transition and transform (e.g. Safari 6, Android browser < 4.4).
Those that only require the -webkit- prefix on transform (e.g. Chrome 3x).
Those that require prefixes on neither (e.g. FF and IE10/11).
How can I safely write my transition styles so that they are parsed correctly in each type? I see two options:
-webkit-transition: -webkit-transform 300ms;
transition: -webkit-transform 300ms, transform 300ms;
or
-webkit-transition: -webkit-transform 300ms;
transition: -webkit-transform 300ms;
transition: transform 300ms;
Now because of type 2 and type 3 browsers I need to have a prefix-less transition for both -webkit-transform and transform. The problem with the first option is I worry that type 2 and type 3 browsers will not be able to parse the second line, since they will always contain an unrecognized property. The question is, how do browsers handle invalid properties inside a transition--ignore the entire transition style or just skip the invalid property?
I thought this may be mitigated by separating it into two properties so that if one is not parseable it will just be ignored. Apart from this second option being a bit verbose, I still wonder if, in the case of type 2 browsers, the third transition will be unparseable and "reset" the transition back to null.
Any ideas how these perform, generally? Also, which of these are future-compliant for when Chrome et al. switch from -webkit-transform to the prefix-less transform?
UPDATE NOTICE Unfortunately it turns out Safari at the time of this post does not follow the standard outlined in the W3 Specification below, and including both a webkit prefixed property and a prefix-less property after transition will cause it to break and not be animated at all. I am still exploring this issue for a good general solution but it looks like until Safari fixes this, there may not be one that works everywhere, and for all future properties, without adjusting your CSS rules per browser dynamically with JavaScript.
If you add an unrecognized or invalid property to a list of transition properties, the valid properties in the list will still be added (except on Safari, see notice above).
According to section 2.1 of the w3 Specification for CSS Transitions:
If one of the identifiers listed is not a recognized property name or is not an animatable property, the implementation must still start transitions on the animatable properties in the list using the duration, delay, and timing function at their respective indices in the lists for ‘transition-duration’, ‘transition-delay’, and ‘transition-timing-function’.
W3 Specification for CSS Transitions
If you take the following style, the width property will still be animated despite being preceded by an invalid and unrecognized property.
transition: unrecognizedProperty 2s, width 2s;
If you follow a transition rule with another transition rule (with the same prefixing or lack thereof), the first rule will be overwritten and no longer applied even if the second rule only has invalid properties listed on the right hand side.
If you try the following style the width will not be animated because the first rule will be overwritten by the second rule, which effectively does nothing since "unrecognizedProperty" is not recognized.
transition: width 2s;
transition: unrecognizedProperty 2s;
Based on this I believe your first approach is correct.
-webkit-transition: -webkit-transform 300ms;
transition: -webkit-transform 300ms, transform 300ms;
The first rule will only be applied if -webkit-transition is recognized, in which case since transform came out after transition it will definitely have to be prefixed and we can omit the unprefixed transform property (although I don't think it would hurt to leave it). The second rule will only be applied if unprefixed transition is recognized, in which case whichever of the right-hand side properties that are recognized by the browser will be applied, even if other properties in the list are not recognized.
Your second approach is flawed since the second rule will always be overwritten by the third rule regardless of if any properties on the right hand side are or are not recognized.
I believe the complete list of browser prefixed properties to guarantee that you apply transition of 2s to transform on all browsers that are capable is the following, but please read the rational below because it only happens to be this neat for this property pair by chance:
-webkit-transition: -webkit-transform 2s;
-moz-transition: -moz-transform 2s;
-o-transition: -o-transform 2s;
transition: transform 2s;
Note there is no such thing as -ms-transition, but there is a -ms-transform. That being said transition was not added to IE until 10 where -ms-transform was also outdated by unprefixed transform. Hence for IE the only rule we need is "transition: transform".
I will additionally note that any time we have a browser prefix for transition (< Chrome 26, < Firefox 16, < Safari 6.1, < Opera 12.1), then transform was definitely still prefixed as well (< Chrome 36, < Firefox 16, all Safari, < Opera 23), meaning we can leave off the unprefixed version of transform following a prefixed rule.
Since Firefox released unprefixed transition at the same time as their unprefixed transform, we do not need the prefixed "-moz-transform" on the right-hand side of the unprefixed "transition".
Opera at some point used -webkit- prefix for transform in addition to -o-, however they started using -webkit-transform in version 15, after starting to use prefixless transition in version 12.1, so we do not need to include the -webkit-transform after -o-transition. Also since Opera only used prefixless or -webkit-transform after version 12.1, we do not need to include -o-transform after the prefixless transition.
In this case we do not have to include -webkit-transform to the right of prefix-less transition because browsers that only recognize -webkit-tranform will fall back to -webkit-transition and still apply this property.
If you don't mind the length of your CSS though, the following should be a safe generalized solution for ensuring proper browser prefixing of transition and a prefixed right hand property. UPDATE NOTICE As it turns out this approach may not be safe on Safari since they do not follow the W3 standard on ignoring unrecognized properties to the right of transition if there is one that is prefixed and one that is not.
-webkit-transition: -webkit-property,
property;
-moz-transition: -moz-property,
property;
-ms-transition: -ms-property,
property;
-o-transition: -o-property,
-webkit-property,
property;
transition: -webkit-property,
-moz-property,
-ms-property,
-o-property,
property;
I believe the transition prefix that is unrecognized is simply skipped until a recognized one is found.
I am currently using this for a site and it works for us.
CSS
.viewElement{
-webkit-transform: translatex(0) translatey(500px);
-moz-transform: translatex(0) translatey(500px);
-o-transform: translatex(0) translatey(500px);
-ms-transform: translatex(0) translatey(500px);
transform: translatex(0) translatey(500px);
-ms-filter: "progid: DXImageTransform.Microsoft.Alpha(Opacity=0)";
filter: alpha(opacity=0);
opacity: 0.0;
-webkit-transition: all .8s ease-out;
-moz-transition: all .8s ease-out;
-o-transition: all .8s ease-out;
-ms-transition: all .8s ease-out;
transition: all .8s ease-out;
}
I was reading about Impress.js and I have some questions about the code below (Part of the Inpress's demo).
.impress-enabled .step {
margin: 0;
opacity: 0.3;
-webkit-transition: opacity 1s;
-moz-transition: opacity 1s;
-ms-transition: opacity 1s;
-o-transition: opacity 1s;
transition: opacity 1s;
}
.impress-enabled .step.active { opacity: 1 }
My questions:
What is .impress-enabled class here for?
So class .active is applied on the step currently displayed? And thus, its opacity changes to 1 when its displayed and back to .3 when its next one is displayed; as described in .impress-enabled .step above it, right?
Thanks for help
if javascript is deactivated by the visitors browser, he won't get a .impress-enabled class at all, because it is added via javascript. that's how they could separate a javascript and a non-javascript version (simply deactivate javascript for a moment and visit an example page of impress.js again). So if you have js activated, the class "bored" gets removed and a class called "impress-on-bored" and "impress-enabled" gets activated.
Yes. You're right.
impress-on-ID can be used to add slide specific js or css code when it becomes active. For example, if your slides are small and multiple slides are contained in the browser window, we can initially hide all the slides other than first slide.
Once specific slide becomes active, it will get impress-on-ID class. We can use this class to make the step visible.
If you want to know more, read my book on Building Impressive Presentations with impress.js
Currently I'm using the following code to translate both x and y at the same speed:
-webkit-transition:all 180ms ease-out;
I would like to translate the X axis slower than the Y. Is it possible to specify something similar to:
-webkit-transition:translateX 180ms ease-out;
-webkit-transition:translateY 50ms ease-out;
Thanks in advance!
Sad but true: you can't use different timings for different parts of transform since it's now only one property and cannot be spliced.
The only things you can do:
Use translate only for one axis, and use the positioning for another (like top or left). Doing so you could attach different timings.
Use two wrapped blocks, so you could use different transforms on them. It would take more code, but would be helpful if you'll need the GPU acceleration.
No other ways for us :(
Not ideal, but you could translate one dimension and change another property, such as left on the other...
-webkit-transition: left 180ms ease-out, -webkit-transform 50ms ease-out;
Demo http://jsfiddle.net/DFLL7/
I'm not sure, but maybe you can try.
.m01 { -webkit-animation:test_XY 3.5s 1.5s ease both; }
#-webkit-keyframes test_XY {
0%{ -webkit-transform:translateX(450px)}
70%{ -webkit-transform:translateX(-1px)}
80%{ -webkit-transform:translateX(0)}
95%{ -webkit-transform:translateY(-95px)}
100%{ -webkit-transform:translateY(-90px)}
}