Enter the MooTools

While the original version used jQuery (1.2.6 at that time) and lots of people like it, we (mootoolers) have a different approach to code specially emphasizing on OOP techniques and readability. Part of the issue might not be jQuery per-se and be Dave's code that was a little obfuscated, but it anyways has a lot of room for improvement.
This article will just describe differences between the MooTools implementation and the Dave's jQuery one, so unless stated otherwise, everything from the ALA article applies here.

enter the Sprites2 class

Part of the requirements I imposed myself when porting to MooTools was that it had to be easier to use than the jQuery version, and that it should give a certain degree of flexibility to extend the possible transition effects.
End result is a class intuitively named Sprites2, where you gracefully pass named parameters:

1

new Sprites2({mode: 'fade', item_selector: 'ul.nav a', duration: 250});

changes to original code and idea

Apart from moving the code to a class, a change to note is the removal of the :active state from the CSS and the setActive parameter in the JS code. This was mostly a personal preference as the :active pseudo-class created a few issues when holding the mouse on the element and releasing outside of it. Other notable changes in the CSS are the simplification of the implementation/adaptation process by using a simpler approach on the styles (for example, using height:100%; where applicable instead of redefining height:48px; 5 times in the CSS).

MooTools also has a free "upgrade" built-in: animations have an internal state so that if you roll out from the element and enter it again, the transition will continue to run smoothly. In contrast, jQuery version (may be by code design, maybe because of a library limitation) flickers madly when you roll over and out of the element repeatedly with an interval less than the effect duration.

Also to note, and as mentioned, the Sprites2 class can be easily extended outside of the sprites2.js file with just a few lines of code to create for example a horizontal slide effect:

1
2
3
4
5
6
7
8
9
10

Sprites2.implement({
  effects: {
    slide_x: function(fx_element) {
      fx_element.store('width', fx_element.getSize().x).setStyles({'width': 0});
 
      this.show_fn = function(fx_element) { fx_element.tween('width', fx_element.retrieve('width')); };
      this.hide_fn = function(fx_element) { fx_element.tween('width', 0); };
    }
  }
});

and you can start using it right away with new Sprites2({mode: 'slide_x'});. This obviously works any way you want, as you can manually add or remove the effects directly in the source file.

download, full demo and requirements

The example here is running on a standard google hosted version of mootools 1.2.1. For those of you that use custom builds, just be sure to add FX.Tween and FX.Morph to your standard array of includes (morph is only used by the "animate" effect, so if you don't use that one you can exclude it.)

View full online demo

Download Sprites2 for MooTools [zip].

new! – by popular demand (not really), I have just set-up a git repo so you can fork the latest source: http://github.com/gonchuki/sprites2-moo

License: Creative Commons Attribution-Share Alike 3.0
disclaimer: original code did not contain any license whatsoever (like all ALA code), so I assumed a CC share-alike license applies perfectly in this case.
]]> http://blog.gonchuki.com/archives/css-sprites2-its-mootools-time/feed/ 24 http://blog.gonchuki.com/archives/updating-moopop-for-mootools-12/ http://blog.gonchuki.com/archives/updating-moopop-for-mootools-12/#comments Tue, 24 Jun 2008 02:37:31 +0000 gonchuki http://blog.gonchuki.com/?p=22 After several requests to update the script, I finally had time to make the update. In fact the script was under production for more than a month running over mootools SVN builds. The update also comes with a couple additions suggested by users, and also some optimizations thanks to the new mootools 1.2 element storage.

so… what's new?

the basic improvement is that the code now works with mootools 1.2, be warned that this actually *breaks* compatibility with mootools 1.11 so please use the older version if you haven't yet gone to 1.2

and then, what else?
resizable windows
I got some requests for this feature, so it's here. Just mix a "r" parameter in this format: "[600,400,r]" and the popup window generated will be resizable.

ability to reuse the same popup
the old moopop had a bad habit of creating a new popup window for each link and not offering an option to reuse the same window. now you can use the "name" attribute native to <a> tags to specify the target of the popup.

defaulting to rel="popup"
now you can just call moopop.captureByRel() without arguments and the script will default to the most common use case.

under the hood…
optimized code a bit, and now it's using both element storage to avoid memory leaks and cleaner CSS2 selectors that got native in mootools 1.2

documentation?

yes sure, unless for the additions specified in this post, all documentation remains the same and you can get it either in the original post, or looking at the source of the uncompressed moopop 1.1

download

as with previous version, you just need Selectors and DomReady from the mootools core builder and the rest of the dependencies are automatically selected.

Download moopop 1.1 with documentation
or
Download minified version without docs to save bandwidth.

License: Creative Commons Attribution-Share Alike 3.0

Navigation

Good Idea

The interface overhaul. Old WordPress admin was really boring and suffered a lot from featuritis, something that all big software suffers but the normal tendency is to redesign the interface when things get out of control. That time has come, and the new interface of the admin is really pleasant to use and almost perfectly organized.

Bad Idea

The design tab should not be primary. Blogs don't change design as frequent as one changes it's own underwear (unless you are an extreme geek stereotype that doesn't even know the meaning of the word "laundry", but that's a topic for another post). Even with the upgrade to 2.5, I guess I won't be touching that tab except for curiosity. The design tab should have been left at the top right, just next to settings and plugins.

Plugins

Good Idea

You can now upgrade plugins without manually uploading files. Great move, automatic upgrade of plugins is one of the most important functionalities that were missing. For heavy loaded blogs with tons of plugins this is a bless, no more downloading of the zip just to manually re-upload the files to the host.

the new plugin upgrade interface

Bad Idea

The plugin upgrade log screen is terrible, and the interface too I can not guess how they ended with this current screen, it's completely washed out and not really useful for the average Joe. I certainly expected a lot more from Happy Cog. Worst part is, it would only have taken 5 minutes to give it proper styles and at least look like a real log screen.

bad idea, good idea

A Better Idea

While we are at it, here's another short suggestion: how about using ajax? click the upgrade link, a throbber replaces the link, and then a nice "success" status message replaces the whole row. badabing! that's what I would call a friendly one click upgrade process. I mean, is there a real need for Mr. Average Joe to read the log on what is happening in the background?

Mr. Average Joe would be really pleased to see this happening!

Widgetized Sidebar

Good Idea

New widgets, and a usable new interface. The widgetized sidebar was one of the worst implemented features in previous wordpress versions, and (at least to me) it was kind of useless as I always ended manually editing de sidebar.php file. All that has ended with the new interface and I give it a great welcome.

Bad Idea

The RSS widget still comes with broken code. All the work you do on the front end is not good if you still keep the garbage at the back end. Is there a reason for one to want to have an orange background on the RSS icon and make it be exactly 14×14?

<img style='background:orange;color:white;border:none;' width='14' height='14' src='$icon' alt='RSS' />

Hey Mr. WordPress, would you please let me customize my theme as I like?
The outcome: I ended manually editing widgets.php (with a similarly hackish approach ^_^) to add my tumblr garbage to the sidebar.

Final Words and Miscellanea

All in all, WordPress 2.5 has been a great step forward. Other things I liked are the new option to have full text in the RSS (I know I will have one more reader now, right? ;) ), the new compose screen is a lot cleaner, the permalink edit while creating the entry is a bless, and overall the admin interface just feels right. Let's hope however that next release comes with some more polishment as there are still lots of rough edges and they are not as complicated to solve. And let's not forget, there's still no fricking undo!

identifying the problem

As we have seen before, long pages work. But we always have an issue in the process: if one wants to navigate to other section of the site you have to scroll all the way up or use your other hand to hit the [Home] key.
Given that the average internet user (I would say more than 90%) use their mouse to browse the web, either having to use your other hand and hunt for a key, scrolling up repetitively or clicking on that very top portion of that 16px wide scrollbar adds complexity to the task we are doing and decreases our efficiency.
Users love to hunt for information from page to page, and our task as user experience designers is to give them the tools to ease their stay.

the wrong approach

The classic solution of spreading links all over the place has great design, usability and accessibility problems.
From the design point of view you either come up with a clever way to disguise the links or just leave them out there clogging the visuals. Not good either way!
Usability wise, do you really know when the user wants to go back to the top of the page? Is there a need to spam the user with back to top links?
And that spamming also means for decreased accessibility, screen reader or keyboard users will be constantly spammed with those meaningless links. They already know how to get back to the top of the page without the need for your "shortcuts".
Shouldn't there be a wiser and cleaner solution?

developing a solution

Fortunately, there is a fairly good solution. And armed with a bit of javascript and standards compliant CSS we can pull the trick.
Did I just say javascript? why, yes! The back to top link is a navigational aid for mouse users and not real content in your page, think of it as an escape pod for when you want to get away from the current page.
When developing this together with Nicolas Sanguinetti for Operator11 our main goals were:
- keep it clean
- be unobtrusive
- keep it usable
The final solution ended as a tiny piece of code written with the aid of Prototype.
However as you may know, my personal and professional focus is into the mootools library and for this reason the solution presented today will be an adaptation from the original code.

methodology and code

Q: So when should we show the back to top link?
A: Once we think the user needs it.
Getting this metric can be a bit tricky and it's mostly arbitrary, but we finally settled for 80% of a full page scroll. It's around this point that we need at least two mouse wheel scrolls to reach the top and hitting the back to top link becomes more efficient.
the javascript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

window.addEvent('load', function(){
  new Element('span', {
    'id': 'back-to-top', 
    'styles': {'opacity': 0.6},
    'events': {'click': function() {
      if (window.location.hash) { window.location.hash = "page"; } 
      else { window.scrollTo(0, 0); }
    }}
  })
  .setText('back to top')
  .injectInside(document.body);
 
  window.addEvent('scroll', function() {
    var fn = window.getScrollTop() > (window.getHeight() * 0.8) ? "addClass" : "removeClass";
    $('back-to-top')[fn]('visible');
  });
});

and this simple CSS:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#back-to-top,
#back-to-top.visible {
  display: none;
}
 
body>#back-to-top {
  position: fixed;
  bottom: 0;
  right: 0;
  cursor: pointer;
  padding: 3px 17px 3px 7px;
  font: bold 14px Arial, Helvetica, sans-serif;
  color: #fff;
  background: #555 url(triangle-gray-up.png) no-repeat right center;
}
 
body>#back-to-top.visible {
  display: inline;
}

pitfalls and caveats

Just a few notes on usage and explanation of the methodology are needed.
The code as you see purposely ignores IE6 as it has inexistent support for position: fixed. By using a CSS2 selector we gracefully degrade and ignore that browser and only display the link on standards compliant browsers.
There is also another issue with IE (6 and 7) that throws the infamous Operation aborted error and it's the reason behind using the onload event instead of ondomready.
Last, but not the least, removing the hash part in the URL reloads the page instead of just cleaning that part of the location. This happens *at least* in Firefox and it is enough to conclude that setting window.location.hash = "" is not an option. For this is that we check the existence of the hash in the current location, and if not present we scroll to the top with javascript or else we set the location to the topmost element in our page.
Be warned then, that if you use internal anchors in your site, you must have an element with an ID at the top of your page, preferably the body tag.
For the curious, we re-set the hash part just for bookmarking purposes. If you hit the back to top link, then you are supposedly at the top and not on #someplace in the page.

compatibility, download and legal bits

The code is tested and works under Firefox, Opera 9, Safari 3 (both Windows and Mac) and Internet Explorer 7.
As for mootools, you just need the "Element.Event" and "Window.Size" modules, pretty much standard stuff.

By the way, you should have already noticed the back to top link in action in this post, feel free to try it out before leaving your comments ;)

Download back-to-top.zip

License: Creative Commons Attribution-Share Alike 3.0

2009/02/27 – Update: The original code above was originally intended for mootools 1.11 (bleeding edge at that time in 2007), but given that 1.2 has been out for a long time I guess it's time for a quick update for mootools 1.2.x
I also took a few minutes to clean-up the CSS (no more CSS2 descendant rule to hide from IE6) and moved the "fixed" styles to the Element creation in the JS. Now all that remains in the CSS is the customization on font, color, padding and background. The effect now also uses a fade in tween if it's available in your custom Mootools build.
Download back-to-top for mootools 1.2.x [zip]

addendum: original Prototype code

Being that I was struck by a very strange bug in mootools 1.11 a lame overriding of the addEvent function by the Wordpress.com Stats plugin, I'm putting here also the original Prototype-based implementation either for comparison or just for those Prototype users out there:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

BackToTop = {
    initialize: function() {
        document.body.appendChild(
            BackToTop.link = new Element('span', {id: 'back-to-top'})
                .update("back to top")
                .setOpacity(0.6)
        );
        BackToTop.link.observe("click", BackToTop.onLinkClick);
        Event.observe(window, "scroll", BackToTop.onWindowScroll);
    },
    onLinkClick: function() {
        if (window.location.hash) {
            window.location.hash = "page";
        } else {
            window.scrollTo(0, 0);
        }
    },
    onWindowScroll: function() {
        if (document.viewport.getScrollY() > (document.viewport.getHeight() * 0.8)) {
            BackToTop.link.addClassName('visible');
        } else {
            BackToTop.link.removeClassName('visible');
        }
    }
};
Event.observe(window, 'load', BackToTop.initialize);

notice that this was first written to be a LowPro behaviour (and fitting more of Nicolas' coding style) but given the Operation Aborted bug in IE we reverted back to plain Event.observe from Prototype.

the call for a simple solution

What's more annoying than a popup window? Writing code to execute them.
- "Was it with quotes or without them?"
- "Should I write px to specify it's in pixels?"
These questions and more always raise in the seldom event that we need to write some kind of code for a popup window. Even worse, we feel it's a waste of time to write spiffy code to manage the popups since we are coding an ugly feature.
Fear not, as I created a simple yet elegant solution based on the mootools framework (In fact, the solution is pretty much library-agnostic, changing 2-3 lines of code is all you need to adapt it.)

how simple can it be?

As simple as adding the JS to your site and adding a rel attribute to your links.

1

<a href="http://www.google.com" rel="popup">popup google</a>

see it in action
rel="popup" will trigger the standard popup behavior that is to open the link in a new window, pretty much works as a target="_blank" while keeping our code tidy, standards based and semantically meaningful.

what about arbitrarily sized windows?

Thanks for asking. That's where moopop shines as you can have a ton of different sized popups in your page while still having to write no javascript code. This is where site maintainers start to love you, as they can edit or add new content without having to learn the intricacies of javascript.
Let's see the code:

1

<a href="http://www.google.com" rel="popup[600,400]">popup google at 600x400</a>

see it in action
as simple as that, we can personalize each popup window by adding the size between square brackets.

documentation, requirements and download

Documentation is built-in on the JS file in case you want to take a peek in a mootools-esque style for easier understanding.
There are more possible uses for this such as setting a default size for all the popups without a given size, but I will leave that to you as that's a silly feature I had to build for a lazy coworker.

If you are already using mootools it's pretty much sure that you have the required dependencies. If not, it requires Element.Selectors, Window.DomReady and the rest of the requirements are automatically selected by the mootools download builder

- Download moopop with documentation
or
- Download JSMin stripped version

License: Creative Commons Attribution-Share Alike 3.0

And no, it's not a problem of being a newbie in wordpress, it's just that there's too much duplicated code revolving on the structure, at least on the default Kubrick theme that is supposed to be the one that shows off most of wordpress "features".

the first challenge:

adding a wrapper around the content and sidebar.
This could have been easy, if only I didn't have to dig through six different files and manually inject the same code on each one of them. Yay for templates!
Come on wordpress staff, you can do it better, i want my header, footer and basic layout on *every* page of the site *unless* I specify the contrary, it's a big let down if my "templated system" makes me go through every top-level page to inject two lines of code on each of them. Learn from Ruby-on-Rails, CakePHP or Symphony, where you specify your top-level layout and it's used site-wide unless you direct the framework not to do it.

on the second day, God created blog entries:

and did it the wrong way. The same issue as with the layout, was now worsened with entries. I had to dig through five different files to *try* to unify the way entries were to be displayed on every page of my site. Appart from being tiresome it's horribly error prone, what get us to the third point…

there's no f*cking undo:

if you mistakenly hit the "update file" button in the middle of an edit while there are still errors to fix there's no way to go back. Even worse, I was editing my CSS externally and copy&pasting on the wordpress admin the whole stuff… all was fun and games until I accidentally overwritten the Main Index Template. Poof! all my previous edits gone without a single undo button. How hard could have been to implement an undo feature like the one in gmail?

now *that* is something to write home about

the sad conclusion:

after going through all of this I figured out I went with the wrong blogging software [duh!].
However, it's too late to go back and start from scratch. May be next time (or when free time is on my side again) I will choose another blogging software suite.
And yes, I think the same as you: this is the saddest attempt at a first blog entry in the whole history of the blogosphere… so be it! :)