With the following rules:
.container[data-direction="reverse"] .pane[style*="display: none"]{
animation:SlideOutToRight 1s ease;
}
.container[data-direction="forward"] .pane[style*="display: none"]{
animation:SlideOutToLeft 1s ease;
}
The animation runs whenever (a) the data-direction attribute changes and (b) whenever the style becomes display:none. How can I change this code so that the animation only runs when the style becomes display:none but not when the data-direction attribute changes?
Right now, when the direction changes, all of the containers go flying across the screen to the other side because the animation gets applied to all of them when the data attribute changes value.
The data-direction attribute should only control which animation plays, but changes to it's value should not trigger the animation. Is this possible?
Update:
Here is a fiddle of the problem: https://jsfiddle.net/j6ytzbh6/
Expected behavior: The forward button should cause the next sequential box to enter from the right hand side while the current box exists left. The backward button should cause the previous sequential box to enter from the left while the current box exits right. No other box should move or cross the view-port when its not it's turn to move.
Reminder: This is a CSS question, so doing the animation in javascript is cheating. The idea is that Javascript controls functionality (ie a box should be shown or hidden) while css controls presentation (ie. do we make it disappear, fade out or fly to the side). You shouldn't have to re-write your plugin to change the visual way things get shown or hidden.
Related
I am working with Vue SFC and Composition API and my goal is to have a shiny-on-hover effect that follows the mouse when it hovers a specific div on the page.
I added a #mousemove directive on this div. Events are triggered when the mouse hovers the div (which is the expected behaviour) but my issue is that events continue to be triggered even after the mouse left the div
Here is the Vue SFC playground where I reproduced the issue and added more details.
Oh, that's a fun one: You are drawing the blue dot in a CSS :after of the container, and put it right under the cursor. However, it does still belong to the container. So basically a part of the container gets stuck to the cursor, so it is still hovering a child of the container, even outside it, and the mousemove event keeps firing.
When I move the mouse fast enough, I can escape the blue dot and the events stop. Similarly, I can pick it up again.
An easy fix (as suggested by #tao in the comments), is to stop the :after element from receiving pointer events:
.ctn:after{
pointer-events: none;
...
}
I'd like to show a modal dialog using a 3D flip effect, exactly like the "3D flip (horizontal)" example in the Effeckt.css library.
However I really don't need the whole Effeckt library, since I just want this one effect. So I've tried to strip out the relevant bits of the library into free-standing CSS and JavaScript.
This is my attempt, but it's not working: http://jsfiddle.net/eJsZx/
As the JSFiddle demonstrates, it's only showing the overlap - not the modal itself. This is odd, because the element inspector suggests that the modal should be visible - it has display: block, visibility: visible and zindex: 2000 (higher than the overlay element).
This is the JavaScript:
$('button').on('click', function() {
$("#effeckt-modal-wrap").show();
$("#effeckt-modal-wrap").addClass('md-effect-8');
$("#effeckt-modal-wrap").addClass("effeckt-show");
$('#effeckt-overlay').addClass("effeckt-show");
$(".effeckt-modal-close, .effeckt-overlay").on("click", function() {
$("#effeckt-modal-wrap").fadeOut();
$('#effeckt-modal-wrap').removeClass("effeckt-show");
$("#effeckt-modal-wrap").removeClass('md-effect-8');
$('#effeckt-overlay').removeClass("effeckt-show");
});
});
What am I doing wrong?
There were a couple of issues in the code.
First, your styles were missing the following:
.effeckt-show .effeckt-modal {
visibility: visible;
}
This was causing the modal to remain invisible.
Once the dialog was visible, the dialog would rotate in just fine, however when being dismissed it would not rotate out. This was due to the following line:
$("#effeckt-modal-wrap").removeClass('md-effect-8');
If you want to remove this class, it would need to be done after the animation is complete otherwise the 3d effect is lost. It doesn't necessarily need to be removed, but that depends on what the rest of your content needs.
The final issue was that the wrapper, on completion of the fadeout, was getting its local style set to display: none. Because of this, the second time showing the dialog would cause it to simply appear because it was moving from display: none to display: block. There are a couple of options here.
Use CSS to animate the fade in/out.
Use window.setTimeout after calling $.show on the element to give the dom a chance to update.
The final result: Working Fiddle
I want to have a transparent background-color and I use gradient filter as a fallback of RGBA in IE. The code is like this:
filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#bfffffff,endColorstr=#bfffffff);
I also want to trigger an event when the user clicks the background, but it seems like the click event doesn't get triggered after I set the filter. Everything is ok without the filter.
So is it another IE bug? How can I solve the problem?
This is probably related to the IE bug that makes links with transparent background no longer clickable: I came across it today. I had a link with a transparent background and display set to block: the main area of the link wasn't clickable, but a 10px border I set on it was. It seems IE also has problems with filters.
This kind of bug is discussed here and here. The first guy's solution is to give a fake background image to the element before setting the filter. The second guy's is to give the element a background colour and set the opacity to 1%, which will make it practically invisible in IE. Hopefully you'll be able to get round it using one of these.
This is not the deal.
Internet explorer creates the filters on a separate layer which is placed above your element and since the new graphic layer is not part of the element - which you have the click event on - there will be no event bubbling.
Recently I made a label element with a nice gradient filter for IE. Only the text can be clicked. If I analyze the label layers from the side with and without the gradient layer, then you will understand the problem.
without gradient filter:
------------------
text layer
------------------
background layer
------------------
with gradient filter:
------------------
text layer
------------------
gradient layer
------------------
background layer
------------------
By the way, that is the reason, why you cannot put a border radius on a gradient filter too. Try it. Create an element, and style it with border radius and give it a gradient filter and run it in IE 9. No matter how you try to force the gradient to stay inside the round borders - with for example overflow:hidden -, it will never obey. Its like a separate element which is positioned absolute and right above your element to cover it up and right under the text.
I may be trying to get too fancy on this one.
I have a pair of radio-like buttons in a row with a divider between them with background images. When one of the 'buttons' is clicked, I change its class. The CSS for the divider is keyed to the classes of the buttons on either side to select a background image. I am doing this with CSS 'sibling' selectors.
I have jQuery .click events tied to the 'buttons'. the first thing they do is clear the 'selected' class from the other button and set it on the button that was clicked.
For example, if the LEFT button class='selected' and the RIGHT button is not, the divider between them will get a blue background. Click on the RIGHT button and it gets class='selected' while the LEFT button's class is cleared. The divider turns red.
This works in IE, FF, Safari, etc. But IE is odd (IE7) - it will only reflect the divider background change when I mouse OFF the button I clicked! That is, in the example, the RIGHT button gets class='selected' and changes immediately on the click. But the divider stays blue until I mouse off the button, then it turns red.
The class itself IS changing and the button's appearance changes as a result. It's only the neighboring stuff that doesn't!?
It reminds me of my old VB6 days when you had to periodically call 'DoEvents' to get Windows to make UI changes. Could there be something similar here for IE?
I have no idea why this helps, but adding .hide().show() to a selector that includes the stuff that changed class seems to make it update.
I've read that using setAttribute to change the class will force IE7 to re-render the styles. Try that, and if it still fails, I've solved a similar IE7 problem by rewriting the html, which forced IE7 to re-render (using jquery):
if ($("html").hasClass("ie7")){
var tempHolder = $("#ajaxresults").html();
$("#ajaxresults").html(tempHolder);
}
As for giving the html or body tag the ie7 class, I recommend taking a look at html5boilerplate.com. If for some reason you can't use their solution, the jquery for it is:
if ($.browser.msie){
if ($.browser.version < 8){
$("html").addClass("ie ie7");
}
else {
$("html").addClass("ie");
}
}
This is a CSS-Question.
In this fiddle you can see a button.
It has got two span-elements inside. One with float:left; the other with float:right;.
The style is a normal button-style.
When clicking that button on the iPhone or hover it in a Browser the style gets lost.
This is because I changed the background-color.
Is there a way to change the background-color without losing the whole button-style?
EDIT:
Here are the two images: The first button is a normal button-element. The second button is a button where I changed the background-color ... this is what it looks like when I'm hovering over a button.
I think I understand what you mean. It looks like the rounded corner is gone when hovering, while a border is added. I'm afraid there's not a easy way to get what exactly you want, as the behavior & appearance of Button is controled by system.
Maybe you can try to replace it with a div, which you have full control of the style (chaning the style via JS when hovering).
All's working fine for me. However floating-right elements should always be placed before floating-left elements. Don't know if it will change anything.