I'm having an issue when trying to position :before content in Safari. In Chrome/IE the content is positioned correctly, but Safari is interpreting the styles differently (see: http://jsfiddle.net/danwoods/Yb8aR/). my initial thought was to remove the position: absolute from the span:before, but that presents it's own issues...
Does anything look out of place? Any explanation as to why Safari is displaying things differently than Chrome?
Thanks,
Dan
I'm not sure what problems you were having with removing position absolute, but I've changed it to position: relative, used top: 4px to line it up with the text, and display: inline-block to allow margin right to separate it from the text.
span:before {
content: url(https://dl.dropboxusercontent.com/u/6114719/progress-2.png);
display: inline-block;
position: relative;
top: 4px;
margin-right: 5px;
transition: all 1.5s ease-in-out;
-webkit-transition: all 1.5s ease-in-out;
-moz-transition: all 1.5s ease-in-out;
-o-transition: all 1.5s ease-in-out;
}
Fiddle is here: http://jsfiddle.net/Yb8aR/5/ - tested in Chrome and Safari.
Note:
Looks like Safari aligns the before pseudo-element to the span element, whereas Chrome seems to align it to the text within the span element (which is centered). Why that happens, I'm really not sure.
Related
I'm using transitions to move text when their parent element is hovered. However, the transition is not reversed when testing in Safari. This results in the text quickly jumping back to the beginning if you stop hovering the parent element before the transition has finished. If you do this in Chrome, the transition reverses back to the beginning.
Can this be fixed in Safari in some way?
GIF showing Safari & Chrome comparison
Safari not reversing clearification
Overview of CSS:
.infoContainer {
display: inline-block;
position: absolute;
transition: bottom .5s ease-in-out;
-webkit-transition: bottom .5s ease-in-out;
bottom: 1rem;
}
.body:hover .infoContainer {
bottom: calc(100% - 1.8rem - 1.3rem - 1rem);
}
Running Safari Version 16.1 (18614.2.9.1.12), Chrome Version 108.0.5359.98.
Expectations and attempts:
I was expecting the transition to be smoothly reversed like it is in Google Chrome. I've tried using the following CSS without success.
-webkit-transition: bottom .5s ease-in-out;
I can't comment so I will write my answer here.
You can add this
.infoContainer {
display: inline-block;
position: absolute;
bottom: 1rem;
transition: bottom .5s ease-in-out;
-webkit-transition: bottom .5s ease-in-out;
transition-delay: 1ms;
-moz-transition-delay: 1ms;
-webkit-transition-delay: 1ms;
-o-transition-delay: 1ms;
}
It should help on safari ;)
I have a div which gets the width set to 280px:
HTML:
<div id="propertiesPane">.. </div>
CSS:
#propertiesPane {
position: absolute;
width: 280px;
right: 10px;
top: 6px;
bottom: 0px;
left: auto !important;
-webkit-transition: width 0.1s linear;
-moz-transition: width 0.1s linear;
-o-transition: width 0.1s linear;
transition: width 0.1s linear;
}
#propertiesPane.collapsed {
width: 50px !important;
}
Also, what's happening is in JavaScript code, on document ready and depending on a flag, the 'collapsed' class is applied, which sets the width to 50px.
The problem is this works fine on desktop (IE, FF, Chrome) and Android 4.3 but not on Safari iOS 8+.
On Safari, although the 'collapsed' class gets applied, the width is not 50px but 280px. If I remove the 'transition' line from the CSS id selector, it works OK.
Is there a strange "race condition"-like on applying the width on Safari? I'm inclined it is, because sometimes I see it works correctly, the width is set to 50px.
JSFiddle: https://jsfiddle.net/fkhq88eb/3/
First stackoverflow post, so please forgive if I'm missing something obvious. I did search for an answer first but didn't find one I recognized as relevant.
In this jsfiddle, I have a div that I'm using as a hover target to get some transitions to happen to an <a> element.
http://jsfiddle.net/ramatsu/Q9rfg/
Here's the markup:
<div class="target">Target
<p>.LightMe</p>
</div>
And the css:
body {
background-color: #099;
height: 100%;
width: 100%;
margin-top:200px;
}
.target{
position: absolute;
left: 40%;
height: 100px;
width: 200px;
padding: 20px;
background-color: #ccc;
cursor: pointer;
}
a {
display: block;
position: relative;
padding: 1px;
border-radius: 15%;
}
a.LightMe {
/*Starting state */
background-color: white;
border-style:solid;
border-color:#fff;
top: -120px;
left: -200px;
height: 80px;
width: 80px;
z-index: 10;
opacity: 0;
transition:left 0.55s ease, opacity .5s .7s ease;
-webkit-transition:left 0.55s ease, opacity .5s .7s ease;
-o-transition:left 0.55s ease, opacity .5s .7s ease;
}
.target:hover a.LightMe {
/*Ending state*/
left: 80px;
opacity: 1;
transition:left 0.55s .7s ease, opacity .5s ease;
-webkit-transition:left 0.55s .7s ease, opacity .5s ease;
-o-transition:left 0.55s .7s ease, opacity .5s ease;
}
.target:hover {
transition: background-color 500ms ease;
-webkit-background-color 500ms ease;
-o-background-color 500ms ease;
background-color:#999;
}
Hover over the grey box labeled Target and back off again to see the transitions on the <a> element. It's doing what I want: opacity fades in during position delay, then it slides to the desired position. when moving out of the hover target, the <a> slides to it's original position, then opacity fades back out. All good so far.
The catch is, if the user hovers over the hidden <a> element, it triggers the same set of transitions, which causes all kinds of unintended havoc.
I'd like to prevent any response to a hover directly over the <a> element, and really like to continue to keep it in css if possible.
I tried adding an explicit hover to <a> and .LightMe to override this, to no avail. (Though that could be that I just didn't get the selector syntax right.)
I added the background-color transition to .target intentionally for testing, and it provided an interesting clue: hovering over the <a> triggers the upstream transitions of the .target div. That's about where my brain broke and I decided I'd better seek help.
I'm working with a few things here that are above my head, I just started from the closest thing I could find and worked toward what I needed. This was the starting point jsfiddle (with thanks to the author):
You can start your 'top' position outside of the viewer port and delay the 'top' transition until after your 'left' transition is over. That way the <a> element will not be clickable until the left transition start.
See: http://jsfiddle.net/Q9rfg/4/
Or you can also use this method, combined with the sibling selector as suggested by aorcsik.
Update: another hacky solution is to place a div which is outside, the hover sensitive element, that covers the moving link. Check it out: http://jsfiddle.net/aorcsik/Q9rfg/2/
The problem with my original idea (below) was, that you could not click on the moving link, since it returned to its original position, once you hovered out of the gray box, also the cursor changed over the hidden link.
I would try to get the <a> out of the gray box, put it after, and reference it in css with the sibling selector +.
.mainclass.subclass:hover + a.LightMe {
/* ... */
}
This way it won't trigger the hover effect of the gray box when itself is hovered, and you stay in pure css land.
This would make positioning a bit trickier, here is a fiddle, check it out: http://jsfiddle.net/aorcsik/Q9rfg/1/
I'm creating a link button with a background image sprite, that transitions on :hover. It works great in all browsers except for IE, which seems to reset the transition direction.
See a jsFiddle demo here or a video of IE10 here or see the css inline here:
.button {
background:url('http://blackspike.com/temp/icon-github.svg') 0 0 no-repeat; width: 30px; height: 30px; display: block;
-webkit-transition: background-position 0.3s ease;
-moz-transition: background-position 0.3s ease;
-ms-transition: background-position 0.3s ease;
transition: background-position 0.3s ease;
}
.button:hover {background-position: 0 -30px}
Expected behaviour is for it to smoothly transition up then back down. It's like a Fill behaviour is messed up somehow?
Any help greatly appreciated!
It looks like a bug, where the original background-position is not being remembered correctly to transition back to, or some such.
I don't know the exact reason why IE10 is behaving that way, but you can fix it by explicitly setting the background-position to a non-zero value for the vertical offset value. For example:
.button { background-position: 0 1px; }
http://jsfiddle.net/aZqEa/22/
Is it possible to animate CSS pseudo-classes?
Say I have:
#foo:after {
content: '';
width: 200px;
height: 200px;
background: red;
display: block;
-webkit-transition: all 1s ease-in-out;
-moz-transition: all 1s ease-in-out;
-o-transition: all 1s ease-in-out;
}
#foo:hover:after {
width: 250px;
height: 250px;
}
Is this even possible? I've been testing and so far I can't seem to find a solution. I'm trying to trim down the amount of JavaScript support I need by using Modernizr.
I already have a JavaScript method, so please no JavaScript alternatives.
Demo: http://jsfiddle.net/MxTvw/
Your fiddle does work for me in Firefox. And as far as I know, and if this article is up to date this is the only browser that can animate pseudo-elements.
EDIT: As of 2016, the link to article is broken and the relevant WebKit bug was fixed 4 years ago. Read on to see other answers, this one is obsolete.
Google Chrome added the webkit bug fix to Version 27.0.1453.110 m
This WebKit bug was fixed: http://trac.webkit.org/changeset/138632
IT IS POSSIBLE to animate pseudo :before and :after, here are a couple of examples for animating the psuedo-elements :before and :after.
Here is a modification of your example above with some edits, that make it animate in and out more smoothly without the simulated mouseleave / mouseout delay on hover:
http://jsfiddle.net/MxTvw/234/
Try adding the main selector #foo with the grouped :hover pseudo-class in your second :hover pseudo-class rule. Also add the transition property, and not just the vendor specific prefixed properties for transition:
#foo:after{
display: block;
content: '';
width: 200px;
height: 200px;
background: red;
-webkit-transition: all .4s ease-in-out;
-moz-transition: all .4s ease-in-out;
-o-transition: all .4s ease-in-out;
transition: all .4s ease-in-out;
}
#foo,
#foo:hover:after,
#foo:hover:before{
width: 250px;
height: 250px;
}
Note that going forward any Pseudo Elements like :before and :after should use the double colon syntax ::before and ::after. This example simulates a fade in and out using a overlay background-color and a background-image on hover:
http://jsfiddle.net/MxTvw/233/
This example simulates a animate of rotation on hover:
http://jsfiddle.net/Jm54S/28/
Of course moving forward with css3 standards we could use ::before and ::after.
This works in latest Firefox, Chrome, Safari, Opera 18+, IE10, IE11 (IE9 and below do not support css3 transitions or animate.)
It does not seem to work now, however according to the W3 specs you can apply transitions to pseudo-elements. Maybe some time in future…
I just found out that you can animate :after and :before (:
Code example-
.model-item {
position: relative;
&:after {
content: '';
position: absolute;
width: 100%;
height: 100%;
top: 0;
right: 0;
background: transparent;
transition: all .3s;
}
}
.opc {
&:after {
content: '';
position: absolute;
width: 100%;
height: 100%;
top: 0;
right: 0;
background: rgba(0, 51, 92, .75);
}
}
I have the div .model-item and i needed to animate his :after.
So i've added another class which changes background and i added the transition code to the main :after (before animation)