I read the following and it got me thinking
Help the browser to render
The browser manages rendering tree, and
elements depend on each other. If the animated element is deep in the
DOM, then other elements depend on it’s geometry and position. Even if
the animation actually doesn’t shift them, the browser has to perform
additional calculations.
To make the animation consume less CPU (and be smoother), don’t
animate the element deep in DOM.
This is referring to vanilla JS - is it outdated advice? Does jQuery have this issue or does it do something clever to avoid it?
It does makes sense. By changing an element the browser will have to verify if this change affects anything 'up the chain'. You can bypass this by making that object independent of the layout. You can make it positioned absolute or animate a transform propriety. In that case the animated element should not affect anything on the page.
Yes, jQuery has that issue. If you want performantanimations you should use CSS or Native element.animate if available: http://updates.html5rocks.com/2014/05/Web-Animations---element-animate-is-now-in-Chrome-36
Related
How do you tell if one element is above another (like after all the z indexes are calculated) with the results from querySelectorAll.
Don't think there is an easy solution, as in there is a browser API you could call and get element "z-height".
You could approach this problem similarly to how rendering engine is working, which stacking elements one on top of the other based on DOM tree depth. Then there is also CSS engine, which changes element positions based on tag types and special rules from CSS, such as z-index, special position properties (relative, absolute, etc.) and even CSS "quirks", for example z-index + opacity changes how elements are stacked.
Based on your goal, you could simplify the parsing and ignore what CSS is doing and only take HTML in consideration. There you have DOM API, which makes traversing the tree structure super easy and the DOM rendering engine will handle all the weird cases of wrong-but-still-working markup.
If you can use jQuery, check
$(element).css("z-index");
In the interesting article Everything You Need to Know About the CSS will-change Property it says that using the translate3d() hack is the old way of doing things if you want hardware acceleration, and instead of that you should use will-change. Is there any benefit in performance when using will-change? I have found it is extremely difficult in some cases to add will-change via JavaScript just before element triggers animation. For example
You can't just put will-change in CSS and expect it to work, because it will be worse if you had multiple elements.
You can't either put will-change in :hover pseudo selector because the browser needs some time to prepare.
You are left with animation on click event, when you can add willChange on hover via JavaScript leaving the browser enough time to prepare (200ms).
Overall you must somehow predict users behavior and that is difficult. It is too complicated (you must, also, remove will-change after animation ends) over translate3d(). Why use it?
As you've already stated, specifying a transform constitutes a hack. will-change is a standard.
There are guidelines around when to use will-change and when not to (with the general idea of using it sparingly and only when you need to). On the other hand, many authors recommend using the transform hack without abandon.
If you expect a user to interact with an element in a way that triggers some resource-intensive visual effect, set will-change. Simple as that. You don't have to predict when or if the user will ever interact with the element and decide whether or not to set will-change — you just set will-change and let the browser worry about the rest.
You don't will-change all the things, but the moment you expect a certain property to change on a certain element, tell the browser that that specific property will-change on that specific element. Whether or not a user actually triggers the change in that specific page load or browsing session is irrelevant to you as the author.
will-change doesn't inherently have better performance — in fact, it does pretty much the same thing as the transform hack at a high level. The performance boost comes mostly from judicious use of will-change so you don't waste system resources on things that don't need them (see point #2 above).
Is it good to depend on the dom (CSS)hover, for detecting when i'm on another div, or figure that from the already stored array of all the div.s positions and dimensions on the page,
keep in mind that the said array, updates every time an element changes either position/dimension
i want the process to be effecient, a part of me want to depend on that array for detecting when i'm over another div. but i'm afraid that, that will be an extra processing.
can anybody please help me ?? (thanks in advance)
To my knowledge, relying on the DOM would be the more advantageous of the two. Like, arbitter said, relying on CSS will probably have a very slight performance advantage, but really this type of process wouldn't slow down your program all that much, if any.
Which of these is more efficient (i.e. faster):
$(elem).show();
or
$(elem).addClass(displayClass); // Where display class is "display: block;"
Or are they identical?
It depends what you're after, they do different things:
$(elem).show(); - shows the element, restoring the display from before .hide() or restoring the default display for the element type
$(elem).addClass(displayClass); - adds a class, always with a certain display, not really restoring what was there - this is less flexible
Which is faster? .addClass() hands down, you can test it yourself here, it simply does a lot less work than .show() does. However, it doesn't do as much feature-wise, so it's less flexible for the reasons above.
No, they are absolutely not identical.
There's a big difference between direct modifications to element styles and "indirect" modifications by changing the element's class, and that really should be pretty obvious. By writing cooperative code between Javascript and CSS, the class changes give you a lot more flexibility. The Javascript manages the state of elements, while the CSS drives the actual effect of that state.
The show() and hide() methods are handy and easy, but (in my opinion) managing state/appearance by class name is really a much more powerful and maintainable way to do things. In fact you can always write your own little jQuery plugins to add/remove classes that are meaningful to your app, to avoid having the class names themselves propagate through your code.
They're not identical; they work completely differently. They may in your case have the same effect, but don't count on it.
For example, addClass may not actually make the element visible in all cases. If the element has other styles which supercede the class (eg ID-level CSS, or inline styles, etc), then adding a class won't have any effect at all.
Also, setting display:block is only correct for elements that you want to be displayed as a block. If you've got inline elements (or worse, tables) and you try to display them as block, the results will probably not be what you're expecting.
Finally, .addClass() definitely involves more processing for the browser than .show(), so you're not making things any easier for your site by using it.
In short, if that's all you're trying to achieve, use .show() - it's the correct jQuery way to do it.
What is the best method for applying drop shadows? I'm working on a site right now where we have a good deal of them, however, I've been fighting to find the best method to do it. The site is pretty animation heavy so shadows need to work well with this.
I tried a jQuery shadow pulgin. The shadows looked good and were easy to use but were slow and didn't work well with any animations (required lots of redrawing, very joggy).
I also tried creating my own jQuery extension that wraps my element in a couple gray divs and then offsets them a little bit to give a shadow effect. This worked well. It's quick and responsive to the animation. However, it makes DOM manipulation/traversal cumbersome since everything is wrapped in these shadow divs.
I know there has to be a better way but this isn't exactly my forte. Thoughts?
ShadedBorder is a good looking and easy to use Shadow-Library. check it out
You don't need to wrap those shadow-divs around the other content, just set them a little askew and place them on a lower z-index !-)
if your main problem is to navigate the DOM, just add a class and/or id to your element, and refer it with JQuery selectors. even better if you store the ref in a variable, so you don't need to select it too frequently
Although it is yet to have full cross-browser support, you might like to try using the CSS 3 text-shadow property.
It largely depends on how frequently your images will need to be changing, and the colored areas that they'll be covering. Because I'm guessing that you'll be needing to pay attention to IE6 compliance, most alpha-PNG solutions will cause such horrible jittery-ness that you'll spend more time in performance optimzation than you would have wanted to guess.
To solve this in the past, since our images are modified less than once a month, we call the images through a caching-PHP script which automatically applies the shadow using a pre-defined background color so we don't have to rely on any transparency. This results in faster downloads (fewer HTTP requests) and a faster-interface because there's less Javascript/CSS magic in the works.
I understand that this is a very old-school solution, and the above solutions would be entirely acceptable if your images were static, but being cross-browser compliant and animated will likely force you to do a solution of this style.