Develop Reference

how do I add an animation to my onmouseover javascript function(changing image on hover)?

I have been trying out a function where when a mouse hovers over the photo it changes. Is there a way to animate this change?
<img src='./images/rocks.jpg' onmouseover="this.src='./images/seasky.jpg';"
onmouseout="this.src='./images/rocks.jpg';" />

First, inline HTML event attributes (i.e. onmouseover, onmouseout, etc.) should not be used. The use of these kinds of attributes persists today because sites like W3 Schools still show them and millions upon millions of inexperienced developers just copy/paste code that they've seen somewhere else and because it seems to work, they don't think twice about it. In fact, there are many reasons why these attributes should die the abrupt death they deserve.
Now, to your specific question, if you want a transition effect, you'll need to use CSS to set it up. And, it's probably best done by using background images of a div element, rather than altering the src of an img element.
See the comments for details:
/* Separate your event handling code from your markup */
// Get a reference to the element
let fancy = document.querySelector(".fancyImage");
// Set up the mouseover event handler
fancy.addEventListener("mouseover", function(){
this.classList.add("go"); // Change to the Go image
this.classList.remove("stop"); // Remove the Stop image
});
fancy.addEventListener("mouseout", function(){
this.classList.add("stop"); // Change to the Stop image
this.classList.remove("go"); // Remove the Go image
});
/* Use CSS for all styling and layout */
.fancyImage {
/* Set up a transition for all property changes that takes place over 1 second */
transition:all 1s;
/* Set the size of the div, otherwise it will collapse because there's no content
in its foreground */
width:200px;
height:160px;
}
/* The element starts off with the stop class hard-coded, so it starts with this image */
.fancyImage.stop {
background: url("https://img.favpng.com/15/11/21/stop-sign-traffic-sign-clip-art-png-favpng-YVm6TAKXcApfNG5qQLT1Axke0.jpg");
/* Make the image fit into the element */
background-size:contain;
background-repeat:no-repeat;
}
/* This class gets dynamically added on mouse over */
.fancyImage.go {
background: url("https://theblogreaders.com/wp-content/uploads/2015/12/Go-298x300.gif");
background-size:contain;
background-repeat:no-repeat;
}
<!-- Don't use HTML event attributes or self-terminating tags.
See how much cleaner the HTML is now? -->
<div class="fancyImage stop">

CSS Transition fails on jQuery .load callback

I have a function that loads html into a table with jQuery and subsequently adds a class to one of the rows with the callback. The function is triggered by various UI driven events on the page. I also have a css transition rule so the color should fade in (transition: background-color 1000ms linear). The function looks like this:
function load_tbody(row_id) {
$('tbody').load("load_tbody.php", function() {
$(row_id).addClass('green');
});
}
Once the html is loaded, the class successfully gets added and row color is set to green. However, my css transition rule seems to be ignored.
When I add a slight delay, even 10ms, it works fine:
function load_tbody(row_id) {
$('tbody').load("load_tbody.php", function() {
setTimeout(function() {
$(row_id).addClass('green');
}, 10);
});
}
The jQuery docs for .load() state:
If a "complete" callback is provided, it is executed after
post-processing and HTML insertion has been performed.
To me this would indicate the new elements have been loaded into the dom with existing styles applied and are ready for manipulation. Why does the transition fail in the first example but succeed in the second?
Here is a fully functional example page to demonstrate the behaviour in question:
http://so-37035335.dev.zuma-design.com/
While the example above links jQuery version 2.2.3 from cdn, actual page in question uses version 1.7.1. The same behavior can be observed across both versions.
UPDATE:
After considering some of the comments and answers offered below, I've stumbled upon something altogether more confusing. User #gdyrrahitis made a suggestion which lead me to do this:
function tbody_fade(row_id) {
$('tbody').load("load_tbody.php", function() {
$('tbody').fadeIn(0, function() {
$(this).find(row_id).addClass('green');
});
});
}
Adding the class inside the fadeIn() callback works, even with a duration of 0ms. So this had me wondering... if the element is theoretically there anyway, what background color does the browser think it has before I add that class. So I log the background-color:
console.log($(row_id).css('background-color'));
And do you know what? Simply getting the background-color color made everything work:
function tbody_get_style(row_id) {
$('tbody').load("load_tbody.php", function() {
$(row_id).css('background-color');
$(row_id).addClass('green');
});
}
Just adding the line $(row_id).css('background-color'); which seemingly does nothing at all causes the transition effect to work. Here's a demo:
http://so-37035335-b.dev.zuma-design.com/
I'm just dumbfounded by this. Why does this work? Is it merely adding a small delay or does jQuery getting the css property somehow have a substantial effect on the state of the newly added element?

jQuery load is intended to drop everything that is requested into the page.
You can leverage the power of jQuery Deferred objects by using $.get instead.
Take a look at this plunk.
Code snippet from plunk
function load_tbody(row_id) {
$.when($.get("load_tbody.html", function(response) {
$('tbody').hide().html(response).fadeIn(100, function() {
$(this).find(row_id).addClass('green');
});
}));
}
I am using the $.when which will run its callback as soon the $.get is resolved, meaning will fetch the HTML response. After the response is fetched, it is appended to the tbody, which is fadedIn (fadeIn method) and after it is shown, the .green class is added to the desired row.
Note that if you go and just append the html and then the class to the row_id, you won't be able to see the transition, because it is executed immediately. A little nice visual trick with the fadeIn can do the work.
Update
On newly added elements to the DOM, CSS3 transition is not going to be triggered. This mainly happens because of the internal browser engine that controls all animations. There are numerous articles with workarounds on the issue, as well as stackoverflow answers. Additional resources can be found there, which I believe can explain the topic much better than me.
This answer is about taking a step back and changing the piece of functionality that renders dynamic elements in DOM, without going to use setTimeout or requestAnimationFrame. This is just another way to achieve what you want to achieve, in clear and consistent way, as jQuery works across browsers. The fadeIn(100, ... is what is needed to catch up with the next available frame the browser is about to render. It could be much less, the value is just to satisfy visual aesthetics.
Another workaround is to not use transitions at all and use animation instead. But from my tests this fails in IE Edge, works well on Chrome, Firefox.
Please look at the following resources:
https://www.christianheilmann.com/2015/08/30/quicky-fading-in-a-newly-created-element-using-css/
Update 2
Take a look at the specification please, as interesting stuff lies there regarding CSS3 transitions.
...This processing of a set of simultaneous style changes is called a style change event. (Implementations typically have a style change event to correspond with their desired screen refresh rate, and when up-to-date computed style or layout information is needed for a script API that depends on it.)
Since this specification does not define when a style change event occurs, and thus what changes to computed values are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others.
When a style change event occurs, implementations must start transitions based on the computed values that changed in that event. If an element is not in the document during that style change even or was not in the document during the previous style change event, then transitions are not started for that element in that style change event.

When element is added, reflow is needed. The same applies to adding the class. However when you do both in single javascript round, browser takes its chance to optimize out the first one. In that case, there is only single (initial and final at the same time) style value, so no transition is going to happen.
The setTimeout trick works, because it delays the class addition to another javascript round, so there are two values present to the rendering engine, that needs to be calculated, as there is point in time, when the first one is presented to the user.
There is another exception of the batching rule. Browser need to calculate the immediate value, if you are trying to access it. One of these values is offsetWidth. When you are accessing it, the reflow is triggered. Another one is done separately during the actual display. Again, we have two different style values, so we can interpolate them in time.
This is really one of very few occasion, when this behaviour is desirable. Most of the time accessing the reflow-causing properties in between DOM modifications can cause serious slowdown.
The preferred solution may vary from person to person, but for me, the access of offsetWidth (or getComputedStyle()) is the best. There are cases, when setTimeout is fired without styles recalculation in between. This is rare case, mostly on loaded sites, but it happens. Then you won't get your animation. By accessing any calculated style, you are forcing the browser to actually calculate it
Trigger CSS transition on appended element
Explanation For the last part
The .css() method is a convenient way to get a style property from the first matched element, especially in light of the different ways browsers access most of those properties (the getComputedStyle() method in standards-based browsers versus the currentStyle and runtimeStyle properties in Internet Explorer) and the different terms browsers use for certain properties.
In a way .css() is jquery equivalent of javascript function getComputedStyle() which explains why adding the css property before adding class made everything work
Jquery .css() documentation
// Does not animate
var $a = $('<div>')
.addClass('box a')
.appendTo('#wrapper');
$a.css('opacity');
$a.addClass('in');
// Check it's not just jQuery
// does not animate
var e = document.createElement('div');
e.className = 'box e';
document.getElementById('wrapper').appendChild(e);
window.getComputedStyle(e).opacity;
e.className += ' in';
.box {
opacity: 0;
-webkit-transition: all 2s;
-moz-transition: all 2s;
transition: all 2s;
background-color: red;
height: 100px;
width: 100px;
margin: 10px;
}
.box.in {
opacity: 1;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.0.0/jquery.min.js"></script>
<div id="wrapper"></div>
Here is the listed work arounds [SO Question]
css transitions on new elements [SO Question]

The main solution is understanding setTimeout(fn, 0) and its usages.
This is not related to CSS animations or jQuery load method.
This is a situation when you do multiple tasks into DOM.
And delay time is not important at all, the main concept is using setTimeout.
Useful answers and tutorials:
Why is setTimeout(fn, 0) sometimes useful? (stackoverflow answer)
Events and timing in-depth (real-life examples of setTimeout(fn, 0))
How JavaScript Timers Work (by jQuery Creator, John Resig)
function insertNoDelay() {
$('<tr><td>No Delay</td></tr>')
.appendTo('tbody')
.addClass('green');
}
function insertWithDelay() {
var $elem = $('<tr><td>With Delay</td></tr>')
.appendTo('tbody');
setTimeout(function () {
$elem.addClass('green');
}, 0);
}
tr { transition: background-color 1000ms linear; }
.green { background: green; }
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<table>
<tbody>
<tr><td>Hello World</td></tr>
</tbody>
</table>
<button onclick="insertNoDelay()">No Delay</button>
<button onclick="insertWithDelay()">With Delay</button>

This is a common problem caused by browsers. Basically, when new element is inserted it is not inserted immediately. So when you add the class, it is still not in the DOM and how it will be rendered is calculated after the class is added. When the element is added to the DOM, it already has the green background, it never had a white background so there is no transition to do. There are workarounds to overcome this as suggested here and there. I suggest you use requestAnimationFrame like this:
function load_tbody(row_id) {
$('tbody').load("load_tbody.php", function() {
requestAnimationFrame(function() {
$(row_id).addClass('green');
});
});
}
Edit:
Seems like the above solution doesn't work for all cases. I found an interesting hack here which triggers an event when an element is really parsed and added to the DOM. If you change the background color after the element is really added, the problem will not occur. Fiddle
Edit: If you want to try this solution (Won't work below IE9):
Include this CSS:
#keyframes nodeInserted {
from {
outline-color: #fff;
}
to {
outline-color: #000;
}
}
#-moz-keyframes nodeInserted {
from {
outline-color: #fff;
}
to {
outline-color: #000;
}
}
#-webkit-keyframes nodeInserted {
from {
outline-color: #fff;
}
to {
outline-color: #000;
}
}
#-ms-keyframes nodeInserted {
from {
outline-color: #fff;
}
to {
outline-color: #000;
}
}
#-o-keyframes nodeInserted {
from {
outline-color: #fff;
}
to {
outline-color: #000;
}
}
.nodeInsertedTarget {
animation-duration: 0.01s;
-o-animation-duration: 0.01s;
-ms-animation-duration: 0.01s;
-moz-animation-duration: 0.01s;
-webkit-animation-duration: 0.01s;
animation-name: nodeInserted;
-o-animation-name: nodeInserted;
-ms-animation-name: nodeInserted;
-moz-animation-name: nodeInserted;
-webkit-animation-name: nodeInserted;
}
And use this javascript:
nodeInsertedEvent= function(event){
event = event||window.event;
if (event.animationName == 'nodeInserted'){
var target = $(event.target);
target.addClass("green");
}
}
document.addEventListener('animationstart', nodeInsertedEvent, false);
document.addEventListener('MSAnimationStart', nodeInsertedEvent, false);
document.addEventListener('webkitAnimationStart', nodeInsertedEvent, false);
function load_tbody(row_id) {
$('tbody').load("load_tbody.php", function() {
$(row_id).addClass('nodeInsertedTarget');
});
}
Can be made into a generic solution or library. This is just a fast solution.

Is there a straightforward way of detecting focus changes in a container element?

In the following code:
div {padding: 10px; border: 1px solid black}
div.whenFocused {background: yellow}
input {display: block}
* {outline: none}
<div tabindex=0>
Text:
<input>
</div>
Is there a simple way of detecting when the DIV gained or lost focus, either directly or indirectly through one of its children?
I need the DIV to have a yellow background whenever the user is interacting with it. The DIV is focusable so the user may arrive there via keyboard or mouse.
If they use the mouse, clicking anywhere inside the DIV must trigger a background-color change. Also, clicking outside the DIV must return the background-color to normal.
I already have this behavior implemented with a couple of helper functions and by listening to several events on different elements. But it's too much code for such a simple thing.
I'm sure there must be a simple and straightforward way, but I can't think of one right now.
(By simple I mean listening to a couple of events plus a couple of one-liner event-handlers and that's it)

I found a simple solution using jQuery:
$('div').on('focusin focusout',function(){ $(this)[(this.contains(document.activeElement)?'add':'remove')+'Class']('whenFocused') })
It's not exactly straightforward, but at least it's a one-liner.
It requires support for:
focusin/focusout
Node.contains
document.activeElement

override default focus with css or reseting it

I want something like css reset, but only for the :focus. If there's none of this yet, would be good to know the possible properties to reset(override) in order to make new :focus that will override the previously one(set by the web-site css). For example, z-index may effect on :focus for some specific elements in some browsers. So the :focus should include z-index with some huge number and in order to work it should include position too. perhaps it's wrong example, but I think you got the idea here.

You may want to post some code with some examples of problems that you are having in a jsfiddle or in the question.
That said, there are some elements that tend to get default styling for :focus in the browser - input, a. There is some great information here about potential fixes, for instance:
/* put universal focus changes here */
*:focus {
outline: none;
}
/* put anchor focus changes here */
a:focus {
...
}
/* put input focus changes here */
input:focus {
...
}
I'm not certain what you are trying to accomplish with the z-index setting, but you could handle it as above.

visibility:hidden vs display:none vs opacity:0

I'm currently starting on an animation project. In the project I'll have more than 40000 divs and animate them iteratively. If any of divs are in passive state (i.e. it's not animating at least for 2 seconds), I won't display them to increase animation performance.
The question is: which css property is the most suitable for this?
.passive1{
display:none
}
.passive2{
visibility:hidden;
}
.passive3{
opacity:0;
}
And how can I measure rendering performance like fps, gpu usage?

While all 3 properties make an element's box seem invisible, there are crucial differences between them:
Property
Painted
In layout
Stacking context
Pointer events
Keyboard events
opacity: 0;
No
Yes
New
Yes
Yes
visibility: hidden;
No
Yes
Varies
No
No
display: none;
No
No
Varies
No
No
The "Painted" column indicates if the browser will paint the element's background (e.g. background-image), #text content, and so on.
An element cannot be painted without also participating in the page's layout, of course.
This is No for all 3 properties and values, as the browser won't need to paint the element's box as it's invisible.
The "In layout" column indicates if the browser will compute the layout and dimensions of the element - along with any of its descendants not excluded from layout.
This is only No for display: none;, as with opacity: 0; and visibility: hidden; the browser will still determine the size of the element so it can correctly layout other elements relative to the current element (e.g. if you have span.hidden { visibility: hidden; display: inline; }).
The "Stacking context" column indicates that any use of opacity (except opacity: 1.0;) will create a new stacking-context, which complicates use of the position property.
The "Pointer events" column indicates if the element will respond to user-interaction from a pointing device, such as a mouse, touch-screen, stylus, etc.
e.g. with visibility: hidden; then the :hover state won't work, and clicking the same element won't apply :focus or :active either.
Additionally, the DOM won't raise any pointer events you'd handle in JavaScript (e.g. visibility: hidden; won't raise mouseclick, touchstart, etc - note that the click event can still be raised by certain elements, like <button> if invoked by the user using a non-pointer input method, such as with keyboard or voice (accessible) navigation means.
You can use pointer-events: none; to block pointer events, but this won't block keyboard and other non-pointer input and so should not be used to disable an element because the user can still use the keyboard to interact with it (especially <button>, <input />, <select>, and <textarea>).
The "Keyboard events" column indicates if the element can be interacted-with using keyboard navigation (and possibly other navigation means).
This includes smart-device (smartphones' and tablets') browsers' "Prev/Next Field" buttons for navigating <form> elements (as this uses tabindex).
Unlike how pointer-events can be disabled in CSS using pointer-events: none;, there is no CSS property to disable keyboard interaction.
This table shows a more complete comparison between the main values of those 3 properties:
Property
Painted
In layout
Stacking context
Pointer events
Keyboard events
Animatable
Opacity
opacity: 0;
No
Yes
New
Yes
Yes
Yes
opacity: 0.1;
Yes
Yes
New
Yes
Yes
Yes
opacity: 0.9;
Yes
Yes
New
Yes
Yes
Yes
opacity: 1;
Yes
Yes
Varies
Yes
Yes
Yes
Visibility
visibility: hidden;
No
Yes
Varies
No
No
Yes, with caveats
visibility: visible;
Yes
Yes
Varies
Yes
Yes
Yes, with caveats
Display
display: none;
No
No
Varies
No
No
No
display: contents;
Text and children only
Text and children only
Varies
Yes
Yes
No
Other
pointer-events: none;
N/A
N/A
N/A
No
Yes
No
The "Animatable" column indicates if that property can be used with a CSS transition (transition:) or CSS animation (#keyframes).
Crucially, the display: property cannot be animated, which is why we can't use a #keyframes timeline to completely hide an element after the animation is complete.
But curiously, we can animate the visibility: property despite being non-continuous, albeit with caveats.
Also, don't get confused by the similarly-named backface-visibility and content-visibility properties.
backface-visibility is only applicable to 3D transform operations.
content-visibility is an optimization to speed-up page rendering during initial page-load, but requires CSS Containment first, which is out-of-scope for this QA.

The answer found here will answer your first question (most likely display:none as the space is collapsed completely).
To your second question, tools such as this will probably be useful for you. However 40,000 divs sounds like way too many and you will probably have better performance using canvas or SVG (for example, using the KineticJS library as this handles animations - transformation, rotation, scale, etc.) for you.

display:none will hide the whole element and remove that from layout space whereas visibility:hidden hides an element but take up the same space as before.
Opacity can be used if you want to create transparency or fade effect.

Performance will be an issue if display:none or visibility:hidden is used since they trigger paint and layout in most browsers which means your browser will redraw the viewport whenever those two changes so I will recommend opacity but still for that number of divs it will still be not performant as expected you can try webgl using a library called html-gl which render your divs in webgl check https://github.com/PixelsCommander/HTML-GL

Here is a compilation of verified information from the various answers.
Each of these CSS properties is in fact unique. In addition to rendering an element not visible, they have the following additional effect(s):
Collapses the space that the element would normally occupy
Responds to events (e.g., click, keypress)
Participates in the taborder
collapse events taborder
opacity: 0 No Yes Yes
visibility: hidden No No No
visibility: collapse * No No
display: none Yes No No
* Yes inside a table element, otherwise No.
got from link

display:none because the divs are taken out of the flow then, thus their position does not have to be calculated.
That being said, 40000 divs sounds crazy. Did you consider the alternatives like HTML5 canvas or SVG?

Sometime i use visibility and opacity together to achieve effect to avoid click event
e.g.
normal state/element removed from screen:
visibility:hidden;
opacity:0;
transition: all .3s;
hover state/element on screen:
visibility:visible;
opacity:1;

Found this thread whilst investigating a hover: bug in Safari mobile
Confirming that opacity: 0 is a valid approach (it is in my case, thanks all). opacity: 0 fixes it enough to be workable (still requires an annoying js redraw on screen rotate [width change]).
Background info on the bug I fixed with opacity: 0:
The hover is on a li containing a div that is revealed when hovering (or single touch on mobile) a calendar entry. Really random working/not working in Safari mobile - and even weirder the behavior changes on a screen rotate++ [nb no media queries involved so not that].
So annoying as otherwise works in all other browsers I've tried.