a little back story

A few months ago, the IE Blog showcased some IE9 goodness and made a call to action for better border-radius implementations. They rightfully shown how they are getting it right this time, and how most other browsers out there are broken, with Safari/Chrome (Webkit) being the worst still at the time of writing this article. But not everything in their implementation is correct, IE9 pre 3 still exhibits the same issue as the other browsers that I'm presenting today.

the big bug theory

So what's the issue with border-radius? simple answer: the background color bleeds behind the radius when you also have a border in the same element.
Let's first use a real world example of a live site that paradoxically exposes the bug: HTML5 Rocks Playground

Chrome 5.0.375.99 on the left, Firefox 3.6.6 on the right, Windows 7 with ATI X300

See the blue garbage on the rounded corner? that's what most browsers do.

Now, to rule out a possible specific software/hardware combination, I went thru several test machines and browsers to see if the bug was repeatable:

reproducing the bug

So how hard is to reproduce the bug? sadly, not at all. Here's the base recipe for disaster:

1
2
3

border: 3px solid #999;
background-color: #f00;
border-radius: 20px;

zooming-in the issue:

Firefox 3.6.6

Chrome 5

Opera 10.60

IE9 pre 3

given the previous example and screenshots, you might have noticed the other issue: Firefox is not actually bug-free. It has a slight issue blending the element background with the border. it's not as bad as the bleeding issue, but it's still annoying. Also from the previous set and this one, we notice how the IE9 and Opera 10.60 implementations are an order of magnitude better than what Webkit achieves.

finding a work-around

As you might have guessed, the only reliable work-around to date is nesting rounded elements when you need a distinctly colored border. Using padding on the outer box equal to the border-width required does the trick and works across all browsers:

Of course it's not all fun and games, you need to specify a different border-radius for the inner box as they both have different sizes. In this case, the outer box has 25px while the inner one has 23px.

Can we stop with the pain already? How many years have passed since the first border-radius implementation and they are still getting it wrong?
this is how I feel about the current state of border-radius:

Can every browser get it right before boring us once again with their endless speech on how shiny and compliant they are? It's not frelling rocket science.

the sheeple herder has spoken

Today, April 29th 2010, our dearest dictator ruler decided to publish a pedantic article on why he won't let Flash run on their mobile devices. It's a nice read if you want to take a laugh or two, but at the end if you read between lines he will just self-promote his products based on false premises. I will be analyzing his speech on this post so it's not fully required to read his article first.

at first I was like…

In my recent article I made a lot of things clear so that reading the aforementioned Steve Jobs article will be easier on your feelings. Thankfully, the article also warns people about the weak arguments that HTML5 fundamentalists are trying to push, ignoring every weakness of the spec.

…but then I lol'd

now on to the analysis:

First, there's "Open".

Adobe's Flash products are 100% proprietary. They are only available from Adobe, and Adobe has sole authority as to their future enhancement, pricing, etc. While Adobe’s Flash products are widely available, this does not mean they are open, since they are controlled entirely by Adobe and available only from Adobe. By almost any definition, Flash is a closed system.

Wrong.
As stated in comments of my previous article only the "official" Flash plugin is proprietary, however the specs for running .swf content are open and there's even an open source Flash Player implementation using Javascript+SVG and tons of open source tools for creation and running of SWF content.
As for the rest of the components, the VM responsible for interpreting ActionScript is Open Source (Tamarin), and even the Flex SDK goes for free and is Open Source, so there's absolutely no charge for creating SWF content. Zero, gratis.

The only thing that Adobe charges for is the Flash IDE, the one that eases creation of content, the one that no one using HTML5 technologies has yet, and might take a few years until someone creates one comparable to what the Flash IDE allows you to do.

Second, there's the "full web".

Adobe has repeatedly said that Apple mobile devices cannot access “the full web” because 75% of video on the web is in Flash. What they don’t say is that almost all this video is also available in a more modern format, H.264, and viewable on iPhones, iPods and iPads.
[snip]
Another Adobe claim is that Apple devices cannot play Flash games. This is true. Fortunately, there are over 50,000 games and entertainment titles on the App Store, and many of them are free. There are more games and entertainment titles available for iPhone, iPod and iPad than for any other platform in the world.

Yet H.264 is not part of HTML5, or is it? let me clear this for you, H.264 has royalty fees, ones that you are paying when you buy an iProduct but don't really notice, and Apple is the only vendor opposing the adoption of Ogg Theora as a de-facto video format. This article from Ars Technica has a very complete explanation on the points against Ogg Theora that Apple is trying to shove in the face of their users.

About the games, I'm not keeping tabs but the number of Flash games easily dwarfs any number that Steve Jobs can throw. Even if you remove low quality games from both platforms, Flash would still be the clear winner.

Third, there's reliability, security and performance.

Symantec recently highlighted Flash for having one of the worst security records in 2009. We also know first hand that Flash is the number one reason Macs crash. We have been working with Adobe to fix these problems, but they have persisted for several years now. We don’t want to reduce the reliability and security of our iPhones, iPods and iPads by adding Flash.

Weak argument Mr. Jobs, Adobe has been working hard on Flash and the upcoming 10.1 rewrites history by fixing every problem that previous versions had on the Mac. They even try to use the most advanced rendering mode in Mac OS X, but dictatorial resolutions by Apple avoid third-party applications from accessing the fastest rendering path. Does this ring a bell? oh yeah, the App Store review team can reject your app for using a "pinch to zoom" gesture.

Maybe it's not entirely Adobe's fault. Yes they have they part, but Apple is doing a terrible job at helping them.

Fourth, there’s battery life.

To achieve long battery life when playing video, mobile devices must decode the video in hardware; decoding it in software uses too much power. Many of the chips used in modern mobile devices contain a decoder called H.264 – an industry standard that is used in every Blu-ray DVD player and has been adopted by Apple, Google (YouTube), Vimeo, Netflix and many other companies.

Flash 10.1 also uses hardware acceleration for H.264, so this argument is soon to get outdated. But even if the argument was true, isn't the end user the one responsible for deciding which content is right for them? If I want to drain my battery watching some indie video (that was not created in H.264 as it's not open) then I should be able to do it. It's my right as a customer, and as a web user.

There's also a nice article that compares HTML5 and Flash performance for a data graphing application. The results are not surprising: HTML5/Canvas is slower than Flash in many cases, and that translates to higher battery power usage. [another bench here, comparing mostly raw synthetic speed]

Fifth, there’s Touch.

Flash was designed for PCs using mice, not for touch screens using fingers. For example, many Flash websites rely on “rollovers”, which POP up menus or other elements when the mouse arrow hovers over a specific spot. Apple’s revolutionary multi-touch interface doesn’t use a mouse, and there is no concept of a rollover. Most Flash websites will need to be rewritten to support touch-based devices. If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript?

There have been numerous propositions on how to fix the "rollover" issue in Flash for touch devices, yet Steve Jobs won't acknowledge them. The Flash-to-iPhone compiler demonstrated how you can make Flash content without piggybacking on rollovers to deploy an iPhone application that seems like native.

But the most hilarious argument is how Steve Jobs dictates that we rewrite all the Flash content in HTML5, will he pay for it? I bet it's a no.

Sixth, the most important reason.

Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.

Yet developers are at the mercy of Apple and their App Store policy, in which case if an app gets accepted, it might have taken a month to reach end users. Isn't this the same as waiting a month till the middle-ware developer adopts the new features in Apple's SDK? The end user will suffer just the same.

Let's be sincere, Apple doesn't care about developers (see all of the above points), they just care about making money.

conclusions

Apple wants your money, and native Flash in Safari won't bring them any as people would have access to an immense gallery of free content, tons of nice games that would affect the economy of their App Store.
Apple also wants to kill Flash, so they won't allow you to develop native apps using Flash for arbitrary reasons. They created a closed ecosystem where your only options are to do what they say or GTFO.

Their "open" idea is to control what developers do, in what programming language, and even what APIs or touch gestures they use. By killing the Flash cross-compiler they are also giving the finger to Windows, so developers will still need to buy a Mac to develop for their mobile platform.

What comes next Steve? Wanna dictate the amount of sugar that we put to our coffees while we code?

addendum

some interesting arguments on different views of this same subject have been popping during the day, I will be adding these and anything interesting that comes next as they are a good complement to my thoughts on this matter.

• http://www.adambanks.com/wordpress/thoughts-on-thoughts-on-flash/
• http://billmackin.com/2010/04/a-response-to-steve-jobs-thoughts-on-flash/
• http://jessewarden.com/2010/04/steve-jobs-on-flash-correcting-the-lies.html
• http://www.icodeflash.com/flashblog/?p=63
• http://uza.lt/blog/2010/04/my-take-html5-vs-flash/

Let's put some nails in the idiotic debate coffin.

1. The HTML5 spec won't be ready for consumption for at least another 2 years.

   You avid HTML5 advocate, do you really have any idea on the actual HTML5 roadmap? Well, it's not until 2012 that it will reach Candidate status (an important milestone, which like in any software determines when all features are ready and only testing and minor bugs remain), and sometime around 2022 that it will be finally settled as an official W3C recommendation.

   What this means: whatever code you write based on today's working draft version of the specs is not assured to work in 2012. Yes, there are lots of sections on "last call for comments" status, but that also means a strong argument on said sections could potentially introduce a major breaking change over any current concept code you already wrote.

2. Flash is a mature platform, HTML5 is just in its initial implementation phase.

   Let's face it, like it or not browser vendors haven't yet adopted every part of the current working draft. There are sections that were sitting for over two years in the spec (more specific, the form elements) and those haven't been yet fully implemented by any vendor. Having more browsers in play also doesn't help, as even Chrome's WebKit version doesn't behave exactly the same as Safari's version in regards of HTML5 completeness (or accuracy, for that matter).

   We have at least a good one full year before mainstream browsers implement enough of the HTML5 spec to call it a stable and usable implementation. You can check over on Wikipedia to see a fairly well updated list on current support for the various HTML5 components, or you can even check the working draft maintained by WHATWG where each point of the spec is accompanied by a tool-tip displaying the level of support provided by each major rendering engine.

3. Flash is made by a single vendor, HTML5 sees duplicate efforts by at least 5 different companies on at least 4 different platforms.

   Love it or hate it, Adobe is the only single vendor responsible of developing the Flash player. Yes, it might fail miserably on Linux for some use cases or cause unexpected crashes in Mac OS X, but the behavior is consistent. This single unified implementation is what web developers are desperately looking for.

   HTML5 doesn't bring anything new compared to current HTML4/XHTML in regards of consistency. We will still be suffering from testing our sites across different browsers, operating systems and mobile devices. HTML5 won't steal the world's smallest violin from us, we will still play it to the end of the days. Yes, consistency across vendors is getting better every day, yet you will never experience the same exact representation in every one of them (that will be the day we only have one single browser to rule them all).

   And don't get me started about the <audio> and <video> tags issue, the h264 vs Theora (or AAC vs Vorbis) debate is like the <blink> vs <marquee> nightmare all over again. The only current solution with HTML5 is the same as with Flash: target a single platform and your creation will work flawlessly.

4. Flash is built as a multimedia and animation platform, HTML5 is a progressive enhancement over a content centric and descriptive language

   In case the title is not self-explanatory, or you still don't get the point: HTML5 is *not* a gaming platform nor its design was centered around building banners or vectorial animations.

   Want to cite Canvas? moot point, there are lots of options for layer compositing and using matrix transformations on bitmaps, yet it still falls short compared to Flash. Also notable are the lack of brightness/contrast/tint operations, and the lack of a native vector animation API.
   Want to cite WebGL? another moot point, WebGL isn't anything but a glorified "native" plugin that's not different from running the Unity 3D plugin: a rectangular viewport embedded inside your browser that talks directly with your GPU and has nothing to do with content or information per-se. Writing stuff for WebGL isn't any different than writing it for a standalone OpenGL viewport.

5. Flash is good at what Flash does, HTML5 is good at what HTML does

   You get it now? It's not like Flash is bundled with an IDE resembling an animation studio for nothing, or that the only reliable way to build a good piece of HTML code is by hand coding for arbitrary reasons. Both are strong at what they do, but you need to understand that <canvas>, <video>, <audio> and the likes are just the "nice to have" in HTML5 and not the core itself. Heck, HTML5 can't even access the system's camera/microphone so there's absolutely no way to develop sites like tinychat or justin.tv without requiring the end-user to install additional software to be able to communicate.
   This issue even gets magnified in the iPhone/iPad world, where you can only distribute such kind of software via the app store. An update for your chat app could even take a month to reach your end users!

   As much as your zealot HTML5 advocacy urges you to debate about how *this* and *that* can be replicated using HTML5, one day you will realize that even trivial tasks in Flash like adding bones to an object (LMGTFY: Inverse Kinematics) can and will take enormous amounts of effort and time using whatever raw tool the Canvas+Javascript world provides you.

   Yet again, don't fall in the trap of citing "framework X uses Canvas and has support for inverse kinematics" because you are back at square zero: depending on a third party vendor to add features/fix bugs so you can work on top of it.
   Are you aware you are already suffering from this with the video tag? These two examples just show how the native browser implementation is so barebones that you have to build an entire wrapper around the object.

6. The Flash vs. HTML5 argument will implode after every Flash feature is ported into an HTML5/Canvas equivalent

   So you don't like Flash Ads? say hello to iAd. As annoying as before, but you can't Flash-block or Ad-Block it as it can be served from within your very own DOM tree. Say hello to popunders with video, sound and flying colors.
   Flash is not accessible? then let me know how your Canvas or WebGL piece is in any way more accessible.
   Flash is a closed source platform? to certain extent, all the tools you will be using to "compete" against Flash will ultimately seem like closed source to you. You can only hack on so many projects at once. To make it worse, the browser upgrade cycle takes a lot more time than Flash and a buggy implementation might stay on the market for even 10 or more years (o hai IE6).
   Flash is slow and eats CPU time? Javascript is the same, and will even be slower as you will be running those framework layers over the Javascript VM instead of running it as native compiled code.

Conclusions

To quickly summarize the article, you must understand that Flash and HTML5 are completely different things. They share a lot of features, yet each technology remains so unique that both will stay in the market for many years to come. Neither the one-sided push from Apple nor the fanatic zealotry of HTML5 advocates will take Flash out of the market. But if one thing is certain, the days of using Flash for trivial tasks that *do* require accessibility are over. The bad side of Flash is not the product itself, it's developers misusing it for tasks it was not intended to do.

Let's continue using Flash for delivering heavy animations and interactive content, and of course try to avoid it at all times when there's an usability and accessibility friendly alternative be it using current (X)HTML+Javascript or using the new HTML5 tools as soon as they are ready. Our friends from Mootools, jQuery and the likes are already doing their part to eradicate Flash from what is rightfully the HTML domain.

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!

I have also taken the time to update plugins and enable caching, so everything should be going smoother from now on :)
Expect some new articles soon, I've been very busy lately but there are always stuff I would like to blog and share with the community.

/gonchuki

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

the event-driven web

Developers need to understand that events are (or should be) everywhere, whether on DOM elements, over the HTTP protocol on in plain old javascript objects.
Now, the former two methods are well agreed and documented, yet the later is still an undiscovered world for many developers.

event driven… objects?

Think about it, you attach events to DOM elements, you respond to events pushed by the server yet you are still using a rigid callback based architecture in your objects and pseudo-Classes. That's plain wrong.
let's take object foo as:

1
2
3
4
5

var foo = {
  bar: function(baz) {
    /* do some stuff here */
  }
}

what the average developer does when they need to do something after bar is finished is to add another parameter into the call of bar:

1
2
3
4
5
6

var foo = {
  bar: function(baz, callback) {
    /* do some stuff here */
    callback();
  }
}

If you then need another callback to do something in the middle of bar, soon enough before you notice you will be growing a bloated piece of code. You will notice this approach is not extensible any more when you see you need *yet another* parameter passed into your object to add the new functionality.
To keep things clear, what your object/widget/Class should do is to "raise it's hand" when it needs our attention, and allow us to externally do whatever we desire on the outside, we should not pass-in callbacks to the object, we should run our callbacks once the object told us it's proper time to do so.

mootools to the rescue

So yes, achieving this in plain javascript is not possible as events are only part of the DOM elements. However there's one nifty (yet barely known) feature in mootools that lets us extend any object with whatever set of functions we desire. For the Ruby folks, that's mixins for javascript.

If you are a mootools lover, you may already know that Classes natively implement the Events interface. What you might not know is that *any* object can be mixed-in with Events to be that event-raiser we need.
So when needing to set-up callbacks in our code we could better use:

1
2
3
4
5
6
7

var foo = {
  bar: function(baz) {
    /* do some stuff here */
    this.fireEvent('onComplete');
  }
}
$extend(foo, new Events);

The result of this is that our object foo can now raise events, ones that we can attach to at *any* point of our code by the simple means of:

1
2
3

foo.addEvent('onComplete', function(){
  alert("hello from foo's onComplete");
}.bind(this));

and any time you need a new callback you can just set up another event and respond to it accordingly. Setting up an event of course, is as simple as adding a new fireEvent call where necessary and no more fiddling around with you perfectly built object.

conclusion

Events are everywhere on web development, and it's our job to use them where applicable and know how to do it. Events for regular objects help you keep your code extensible and semantically consistent with the rest of your DOM-based code, and that is a Good Thing.

PS: for those out there not using mootools or not needing it's whole range of functionalities, there's also the tiny Object.Event library that basically allows you to reach the same results, with a prototype-like syntax.

2008-07-13 Update: Having re-read this article many times, I must warn you that I do not fully agree any more to many of the points exposed at that time, so take the lecture with a grain of salt and simply imagine that the article was correctly written and explained.
Still, there's a lot of potential in using custom events inside your javascript code and I encourage you to investigate more into the topic.