Possible bug with :active selector in Firefox? - css

I was compiling different methods to achieve click & show with pure CSS and I am not sure if I found a bug in Firefox. The html code is:
<span id="show6" class="show6"></span>
<div id="cont6">Ipsum Lorem</div>
The CSS uses the :active selector to make the div visible when the span is clicked:
#cont6{
display: block;
-webkit-transition: opacity 1s ease-out;
transition: opacity 1s ease-out;
opacity: 0;
height: 0;
font-size: 0;
overflow: hidden;
}
#show6 {cursor:pointer;}
#show6:before { content: "Show"}
#show6:active.show6:before {content: "Hide"}
#show6:active ~ #cont6{
opacity: 1;
font-size: 100%;
height: auto;
}
(You can see it in action in Example number 6 or 8 of this dabblet. Don't pay much attention to the notes, since they are directed at me but don't really explain the examples).
If I understand :active, the effect should occur only while the span is pressed, and the moment it is released the effect should stop, however in Firefox the div keeps visible after releasing the click on the span.
Can you reproduce it or am I doing something wrong?

Related

style Visibility:visible is not working intermittently on IE11(works fine on chrome and firefox)

I have a pop up on button click to be displayed on the view.I'm using visibility: visible to show the popup it works fine with chrome and firefox and the class is getting inherited from the design system itself.where as on IE11 it's transparency is high while I want it to be opaque.can I overwrite the parent class which is getting inherited from the design system? or any other solution
I have tried with
opacity: 1;
z-index: 1;
background-color: rgba(white,100%);
transition: opacity 200ms;
visibility: visible
Nothing works while tried with !important too or overwriting the inherited class
Could you please provide a minimal, reproducible sample? I made a simple sample to change the style and visibility: visible can work well in IE 11:
function changecss() {
document.getElementById("test").style.visibility = "visible";
}
#test {
opacity: 1;
z-index: 1;
background-color: rgba(white, 100%);
transition: opacity 200ms;
visibility: hidden;
}
<input type="button" value="test" onclick="changecss()" />
<div id="test">test pop up!</div>
If it doesn't solve your issue, please provide a code snippet including related html, css and javascript to reproduce the issue, so that we can test on our side and see how to help.
I resolved this by increasing transition : opacity 200ms to transition :opacity 500ms it works fine now the popup is opaque not transparent as i expected
opacity: 1;
z-index: 1;
background-color: rgba(white,100%);
transition: opacity 500ms;
visibility: visible

CSS3 animation transform jumping at osx Chrome

I am having an issue with Chrome (v. 67) at OSX and movement animations. I've prepared JS fiddle with it:
https://jsfiddle.net/5m173ghv/31/
If you open it at safari it is working very good. But, when you will use chrome it has little lags when moving.
I cannot describe it a bit more... You need to open it and try yourself on the big screen... Please look carefully at white box. You will see that this box has sometimes something like lags or small jumps(?)...
This is very weird. I've tried almost every answer from the internet (trust me ;) ).
I also tried:
Change transforms at animation into position (left)
Change animations into transitions
adding additional parameters (backface-visibility, perspective, will-change...)
Changing sequences of animation to have more steps (per 10%)
Debugging on chrome dev tools (~30-40fps)
Adding transforms like translateZ(0)
You think that this is chrome bug or maybe my fault? Do you have any solution for that?
Here you have code:
HTML
<span class="spark"></div>
SCSS
body {
background-color: black;
}
#keyframes left-to-right {
0% {
transform: translate3d(0,0,0);
}
100% {
transform: translate3d(50vw,0,0);
}
}
.spark {
position: absolute;
top: 30px;
width: 322px;
height: 500px;
background-color: white;
transform: translate3d(0,0,0);
backface-visibility: hidden;
perspective: 1000px;
animation: left-to-right 5s infinite linear;
will-change: transform;
pointer-events: none;
user-select: none;
}

CSS color transition triggers multiple animations when loading the website

This is my first question in this forum so if it's not well explained, feel free to ask me for more details.
I have a color transition in all the links on my navbar, that triggers when you hover your mouse over them. This work wells, the problem is that when the website loads, all those elements began to resize or move to their initial positions.
CSS
nav{
height: 80px;
width: 100%;
background-color: rgba(250,250,250,1);
font-size: 13px;
border-bottom: 1px solid #D8D8D8;
color: #6E6E6E;
position: fixed;
margin-top: -80px;
}
nav a{
padding: 20px 20px;
line-height: 80px;
-webkit-transition: all 0.8s;
transition: all 0.8s;
}
nav a:hover{
color:#00BFFF;
}
UPDATE
I have tried to make a JSFiddle with the problem, but even when the CSS and HTML is exactly the same its seem to work correctly on the demo
I have changed the transition property from all to color. This has solved the problem partially, since now the elements don't move when the page loads, but the problem now is that all links that include this color transition, when the website loads, show an initial blue color (inexistent in my CSS) taking the transition time to change to the correct color. This initial blue color is similar to the visited links standard color (but I have also used the selector a:visited without positive result.
This only happens on Firefox.
As due to my low reputation I can't post images, I have taken the blue initial tone: RGB (6,6,231)
You only need animate the color:
-webkit-transition: color 0.8s;
transition: color 0.8s;
note that I change all for color only.
note 2 you can do
transition: color 0.8s, height 0.2s ease-out, opacity 1s linear 0.5s;
Try adding script tag at footer of the html page.This worked for me.
<script> </script>

CSS: Animation vs. Transition

So, I understand how to perform both CSS3 transitions and animations. What is not clear, and I've googled, is when to use which.
For example, if I want to make a ball bounce, it is clear that animation is the way to go. I could provide keyframes and the browser would do the intermediates frames and I'll have a nice animation going.
However, there are cases when a said effect can be achieved either way. A simple and common example would be implement the facebook style sliding drawer menu:
This effect can be achieved through transitions like so:
.sf-page {
-webkit-transition: -webkit-transform .2s ease-out;
}
.sf-page.out {
-webkit-transform: translateX(240px);
}
http://jsfiddle.net/NwEGz/
Or, through animations like so:
.sf-page {
-webkit-animation-duration: .4s;
-webkit-transition-timing-function: ease-out;
}
.sf-page.in {
-webkit-animation-name: sf-slidein;
-webkit-transform: translate3d(0, 0, 0);
}
.sf-page.out {
-webkit-animation-name: sf-slideout;
-webkit-transform: translateX(240px);
}
#-webkit-keyframes sf-slideout {
from { -webkit-transform: translate3d(0, 0, 0); }
to { -webkit-transform: translate3d(240px, 0, 0); }
}
#-webkit-keyframes sf-slidein {
from { -webkit-transform: translate3d(240px, 0, 0); }
to { -webkit-transform: translate3d(0, 0, 0); }
}
http://jsfiddle.net/4Z5Mr/
With HTML that looks like so:
<div class="sf-container">
<div class="sf-page in" id="content-container">
<button type="button">Click Me</button>
</div>
<div class="sf-drawer">
</div>
</div>
And, this accompanying jQuery script:
$("#content-container").click(function(){
$("#content-container").toggleClass("out");
// below is only required for css animation route
$("#content-container").toggleClass("in");
});
What I'd like to understand is what are the pros and cons of these approaches.
One obvious difference is that animating is taking a whole lot more code.
Animation gives better flexibility. I can have different animation for sliding out and in
Is there something that can be said about performance. Do both take advantage of h/w acceleration?
Which is more modern and the way going forward
Anything else you could add?
It looks like you've got a handle on how to do them, just not when to do them.
A transition is an animation, just one that is performed between two distinct states - i.e. a start state and an end state. Like a drawer menu, the start state could be open and the end state could be closed, or vice versa.
If you want to perform something that does not specifically involve a start state and an end state, or you need more fine-grained control over the keyframes in a transition, then you've got to use an animation.
I'll let the definitions speak for themselves (according to Merriam-Webster):
Transition: A movement, development, or evolution from one form, stage, or style to another
Animation: Endowed with life or the qualities of life; full of movement
The names appropriately fit their purposes in CSS
So, the example you gave should use transitions because it is only a change from one state to another
A shorter answer, straight on point:
Transition:
Needs a triggering element (:hover, :focus etc.)
Only 2 animation states (start and end)
Used for simpler animations (buttons, dropdown menus and so on)
Easier to create but not so many animation/effect possibilities
Animation #keyframes:
It can be used for endless animations
Can set more than 2 states
No boundaries
Both use CPU acceleration for a much smoother effect.
Animation takes a lot more code unless you're using the same transition over and over, in which case an animation would be better.
You can have different effects for sliding in and out without an animation. Just have a different transition on both the original rule and the modified rule:
.two-transitions {
transition: all 50ms linear;
}
.two-transitions:hover {
transition: all 800ms ease-out;
}
Animations are just abstractions of transitions, so if the transition is hardware accelerated, the animation will be. It makes no difference.
Both are very modern.
My rule of thumb is if I use the same transition three times, it should probably be an animation. This is easier to maintain and alter in the future. But if you are only using it once, it is more typing to make the animation and maybe not worth it.
Animations are just that - a smooth behavior of set of properties. In other words it specifies what should happen to a set of element's properties. You define an animation and describe how this set of properties should behave during the animation process.
Transitions on the other side specify how a property (or properties) should perform their change. Each change. Setting a new value for certain property, be it with JavaScript or CSS, is always a transition, but by default it is not smooth. By setting transition in the css style you define different (smooth) way to perform these changes.
It can be said that transitions define a default animation that should be performed every time the specified property has changed.
Is there something that can be said about performance. Do both take
advantage of h/w acceleration?
In modern browsers, h/w acceleration occurs for the properties filter, opacity and transform. This is for both CSS Animations and CSS Transitions.
.yourClass {
transition: all 0.5s;
color: #00f;
margin: 50px;
font-size: 20px;
cursor: pointer;
}
.yourClass:hover {
color: #f00;
}
<p class="yourClass"> Hover me </p>
CSS3 Transitions brought frontend developers a significant ability to modify the appearance and behavior of an element as relative to a change in his state. CSS3 animations extends this ability and allow to modify the appearance and behavior of an element in multiple keyframes, so transitions provides us the ability to change from one state to another, while that animations can set multiple points of transition within different keyframes.
So, let's look at this transition sample where applied a transition with 2 points, start point at left: 0 and an end point at left: 500px
.container {
background: gainsboro;
border-radius: 6px;
height: 300px;
position: relative;
}
.ball {
transition: left 2s linear;
background: green;
border-radius: 50%;
height: 50px;
position: absolute;
width: 50px;
left: 0px;
}
.container:hover .ball{
left: 500px;
}
<div class="container">
<figure class="ball"></figure>
</div>
The above can be also created via animation like so:
#keyframes slide {
0% {
left: 0;
}
100% {
left: 500px;
}
}
.container {
background: gainsboro;
border-radius: 6px;
height: 200px;
position: relative;
}
.ball {
background: green;
border-radius: 50%;
height: 50px;
position: absolute;
width: 50px;
}
.container:hover .ball {
animation: slide 2s linear;
}
<div class="container">
<figure class="ball"></figure>
</div>
And if we would like another in-between point, it would be possible to achieve only via animation, we can add another keyFrame to achieve this and this is the real power of animation over transition:
#keyframes slide {
0% {
left: 0;
}
50% {
left: 250px;
top: 100px;
}
100% {
left: 500px;
}
}
.container {
background: gainsboro;
border-radius: 6px;
height: 200px;
position: relative;
}
.ball {
background: green;
border-radius: 50%;
height: 50px;
position: absolute;
width: 50px;
}
.container:hover .ball {
animation: slide 2s linear;
}
<div class="container">
<figure class="ball"></figure>
</div>
transition can go reverse from middle of the way, but animation replay the keyframes from start to end.
const transContainer = document.querySelector(".trans");
transContainer.onclick = () => {
transContainer.classList.toggle("trans-active");
}
const animContainer = document.querySelector(".anim");
animContainer.onclick = () => {
if(animContainer.classList.contains("anim-open")){
animContainer.classList.remove("anim-open");
animContainer.classList.add("anim-close");
}else{
animContainer.classList.remove("anim-close");
animContainer.classList.add("anim-open");
}
}
*{
font: 16px sans-serif;
}
p{
width: 100%;
background-color: #ff0;
}
.sq{
width: 80px;
height: 80px;
margin: 10px;
background-color: #f00;
display: flex;
justify-content: center;
align-items: center;
}
.trans{
transition: width 3s;
}
.trans-active{
width: 200px;
}
.anim-close{
animation: closingAnimation 3s forwards;
}
.anim-open{
animation: openingAnimation 3s forwards;
}
#keyframes openingAnimation {
from{width: 80px}
to{width: 200px}
}
#keyframes closingAnimation {
from{width: 200px}
to{width: 80px}
}
<p>Try click them before reaching end of movement:</p>
<div class="sq trans">Transition</div>
<div class="sq anim">Animation</div>
in addition, if you want the javascript to listen for end of transition, you'll get one event for each property that you change.
for example transition: width 0.5s, height 0.5s. the transitionend event will trigger two times, one for width and one for height.
Just a summary, thanks to this post, there are 5 main differences between CSS transitions vs CSS animations:
1/ CSS transitions:
Animate an object from one state to another, implicitly by browser
Cannot loop
Need a trigger to run (:hover, :focus)
Simple, less code, limited powerful
Easy to work in JavaScript
2/ CSS animations:
Freely switch between multiple states, with various properties and time frame
Can loop
Don’t need any kind of external trigger
More complex, more code, more flexible
Hard to work in JavaScript due to syntax for manipulating keyframes
I believe CSS3 animation vs CSS3 transition will give you the answer you want.
Basically below are some takeaways :
If performance is a concern, then choose CSS3 transition.
If state is to be maintained after each transition, then choose CSS3 transition.
If the animation needs to be repeated, choose CSS3 animation. Because it supports animation-iteration-count.
If a complicated animation is desired. Then CSS3 animation is preferred.
Don't bother yourself which is better. My give away is that, if you can solve your problem with just one or two lines of code then just do it rather than writing bunch of codes that will result to similar behavior.
Anyway, transition is like a subset of animation. It simply means transition can solve certain problems while animation on the other hand can solve all problems.
Animation enables you to have control of each stage starting from 0% all the way to 100% which is something transition cannot really do.
Animation require you writing bunch of codes while transition uses one or two lines of code to perform the same result depending on what you are working on.
Coming from the point of JavaScript, it is best to use transition. Anything that involve just two phase i.e. start and finish use transition.
Summary, if it is stressful don't use it since both can produce similar result

What's the point of visibility in transition?

Please advise if i'm confused but is there any point of having a transition on visibility? Opacity creates a neat effect, sure. But the change none to block will be from nada to full immediately. Maybe we can spread its occurrence sometime in a time interval but the transition will happen all at once. Or am i mistaken?
Here's the code i'm creating. Should i keep the last three lines in the first style?
div.contentItem{
border: 2px solid #00bb00;
border-radius: 20px;
background-color: Beige;
padding: 10px;
-webkit-transition: visibility 3.0s, opacity 3.0s;
-moz-transition: visibility 3.0s, opacity 3.0s;
-o-transition: visibility 3.0s, opacity 3.0s;
}
div.contentItemHidden{
opacity: 0;
}
div.contentItemVisible{
opacity: 1;
}
Before, i had block styles in the two last clauses but that actually damaged the transition of the opacity (probably due to the fact that display: none causes the elements not to be opacitable at all).
div.contentItemHidden{
display: none;
opacity: 0;
}
div.contentItemVisible{
display: block;
opacity: 1;
}
Yes, there is a point to having a transition on visibility. If you just use opacity on an element, that element will still be there and will block clicks and hover effects on whatever is below it. With visibility: hidden, the element will no longer be visible (similar to opacity: 0), but cannot be clicked.
Here is a link that helps to explain in more detail why using visibility and opacity together may be necessary, and how to do so correctly: http://www.greywyvern.com/?post=337
As a side note, I noticed that you mention visibility in your question, but have display in your code. I'd like to note that there is a difference between visibility and display. In particular, elements visibility: hidden are not visible but still take up space. Elements with display: none are not visible but do not take up space.

Resources