Add fade-in, fade-out, fade-to commands

[bob2517]

Because adding and removing classes can lead to more complications than just having these commands available. If you have to sigh whenever you need to get something to fade in - like multiple images in a set - then you know something needs to change.

The "fading to" display property will default to reaching "initial", but there will be an parameter to reach to any other display type, like "inline-block" or whatever.

[bob2517]

Making good headway on this. Example syntax:

button:click {
    fade-in: .myImages 500ms inline-block;
}

or

img:load {
    fade-in: self 500ms inline-block;
}

That's a lot simpler than dicking about with classes when you're not really interested in keeping track of state - that smells like over-engineering right there, but is the recommended way.

Even better would be a fade property in the element itself as it's such a common requirement in this age - but that's not my call to make and life is too short for me to bother making a suggestion about it.

The performance hit here shouldn't be noticeable for most scenarios.

[bob2517]

For fade-in, all that will be needed if for display: none to be present on the element being faded in.

[bob2517]

This mostly works - some finer points to attend to, mainly what happens when starting from certain values. Fade-to only currently works when fading in and needs to work when fading out happens. Will continue tomorrow.

[bob2517]

Docs done. Just some race condition issues to sort out when switching to a different fade whilst in the middle of one already, and that should be that. I don't see the point (at the moment anyway) of needing a stop() function like the one used in jQuery to get around the same issue. If a different fade is called before another one is called then it would be logical to assume that it should just switch to the new fade and continue with that from the existing opacity.

[bob2517]

Gonna add a no-display-none parameter to fade-out, so the item optionally doesn't have to do the display: none at the end.

[bob2517]

That's done. Gonna add a wait-display-none to fade-out, so the item that has previously been faded out with no-display-none optionally doesn't do the remove until the duration has fully elapsed.

[bob2517]

Switching between up and down fades randomly and quickly all works predictably now. Just need a few more tests and that should be that. Will try and finish this off during the week.

[bob2517]

This is mostly done - committing to branch. Still need to implement "wait-display-none" or something like it before release, which waits until the end of the duration before displaying none on the element itself. There's a working no-display-none option which doesn't remove the element at the end of the fade, but it needs that extra option to be a complete solution to stop jerky element removals after fading amongst grouped items. I could release it as it is though, even as it is it's quite decent functionality.

[bob2517]

OMG, completely forgot about this one. Ok - wrapping this up next.

[bob2517]

Looking at the examples I've set up for this, this is really good - I'm quite excited to release this one. I've seen some dodgy fading techniques out there that break as soon as you sneeze on the fading element, and it's rare that I find any that actually work, like, properly. I'm not even sure if I've ever seen any that work completely. Most break if you change the fade state on a fading element. Anyway - this is one for the front page examples for the new release.

[bob2517]

"wait-display-none" functionality is now done. I'm not convinced I'm naming these correctly though. The other one is no-display-none".

Maybe "no-hide" and "wait-for-hide" is better. Will change them to these and see what it looks like.

[bob2517]

Going with "no-hide" and "complete-then-hide".

[bob2517]

Looks good - removing in-progress. Docs are also complete on this.

[bob2517]

Closing in preparation for release.