Blogless: Blog of Design Less Better.

Posts tagged .

Fancy File Inputs with Mootools and CSS

God, I hate HTML DOM FileUpload Objects (<input type="file"> elements). They're displayed differently by every browser, and it's always ugly. Let's use some fancy AJAX and CSS to fix these horrible, horrible form objects.

Some time ago, we were working on a website that required a contact form with the ability to attach a file. This sounds like, at this point in web design, it should be incredibly simple. Imagine my chagrin as I learned that, in fact, styling the FileUpload Object had a smack of Holy Grail-ness to it. Well, at least as far as HTML form objects are concerned.

A lot of people have had similar ideas on how to handle this. I suppose it all started with Michael McGrady's solution, which was followed closely by an improvement on McGrady's technique from Peter-Paul Koch over at Quirksmode. The closest thing I found to a satisfactory solution, though, came from Shaun Inman. His solution was definitely the right idea, but it wasn't exactly full-featured, and I wanted it built in my favorite Javascript framework.

Like Shaun, I don't think that the text-box is an appropriate UI element for a file upload in 2008 (who wants to type c:\Documents and Settings\Paul\My Documents\My Photos\2008-06-02-Me.jpg into a field that only shows 25 characters?!). Further, every implementation I've ever seen that makes use of a text-box is wonky. So I wanted to do a Safari-style upload.

The default display for a file input in Safari.
I appreciate the cleanliness of Safari's implementation. It's the best default browser implementation out there...but it's still not good enough!

Shaun's really clever idea involves setting the input's opacity to zero and then using a little javascript function to keep the button under your mouse while you're hovering inside the input's parent container. With the hardest part figured out, I had two additional goals:

  1. First, I needed it to display the file name of the uploaded file. One problem with Shaun's is that I couldn't even verify if I'd successfully attached a file.
  2. Second, I agree with Peter on the importance of being able to clear the file from the form. No implementation I've seen allows you to do that, so I added the feature.

To see how it's done, you can either read the walkthrough or else download a working example.

These icons link to social bookmarking sites where readers can share and discover new web pages.
PaulJun 16, 2008
 

Validating opacity in CSS 2.1

Opacity-related CSS definitions are the bane of validating, standards-compliant AJAX components. But we can fix that.

Now more than ever, our clients want cool AJAX components for their sites. It seems like more often than not, we find ourselves creating whiz-bang image galleries, file upload forms, and a variety of other interactive components. These components can be tasteful and add much-needed fun to an otherwise run-of-the-mill interaction experience, so we like doing it.

One of the things we don't like about it, however, is the ease with which web standards can be thrown out the window in the "getting it working" part of the component development. One of the most frustrating culprits is often the family of tags that are required to generate CSS-based opacity effects for interaction elements.

Now, I am generally against using Javascript to apply unsupported CSS definitions as a salvo against the mean red screen of the CSS validator. This is usually a bad idea because, among other reasons, it can fail to degrade gracefully if the user doesn't have Javascript, and it provides a strategy to allow invalid CSS validate in cases where it really shouldn't, it's a little bit clunky when compared to other available methods, and frankly, introducing Javascript into the equation just to validate CSS rarely seems worth the trade-off. That said, in this situation, I think it's legit because:

  1. The opacity definition(s), while being supported by all current major browsers and darn useful, isn't included in the CSS 2.1 spec, despite apparently being part of the jetpack-esque CSS 3 spec (::someday::), and doesn't validate.
  2. In the case of an AJAX component, you're already requiring that your users have Javascript enabled, and hopefully you have a graceful exit strategy already in play if they don't.
  3. Your only other choice to achieve the effect you want is to use something like Flash, which is certainly worse even than invalid CSS.

So let's take a look at how to save your opacity effects and your valid CSS using some handy DOM scripting.

Example: SmoothGallery

I like Mootools. I like its speed, and its clever implementations, and of course, its tiny size. From now until something better comes out, when I write example AJAX, it's going to use Mootools. It rules. End of plug.

Along with the Mootools framework, I have (several times) used customized versions of JonDesign SmoothGallery, a free Mootools-based AJAX image gallery. It is a very nice little component in many respects, but, being one of these it doesn't validate, which makes it untenable as a final client solution, at least out of the box.

By brilliant deduction, you will have already gathered that the reason it doesn't validate is because CSS 2.1 doesn't support a handful of opacity-related tags that SmoothGallery uses. It is full of CSS definitions that look like this:

filter: alpha(opacity=n);
-moz-opacity: n;
-khtml-opacity: n;
opacity: n;

Which lead to something like this:

Results from the CSS Validator.
Opacity: Does not compute!

To fix this up nicely, I always go in and delete these CSS definitions, and then write a little Javascript function, using the good old Mootools selectors, to apply these events at runtime:

function applyOpacity()
{
    if ($E('a.right'))
    {
        $E('a.right').setStyle("filter:","alpha(opacity=20)");
        $E('a.right').setStyle("-moz-opacity","0.2");
        $E('a.right').setStyle("-khtml-opacity", "0.2");
        $E('a.right').setStyle("opacity", "0.2");
        $E('a.right').addEvent('mouseover', function(e) {
            $E('a.right').setStyle("filter:","alpha(opacity=100)");
            $E('a.right').setStyle("-moz-opacity","1.0");
            $E('a.right').setStyle("-khtml-opacity", "1.0");
            $E('a.right').setStyle("opacity", "1.0");
        });
        $E('a.right').addEvent('mouseout', function(e) {
            $E('a.right').setStyle("filter:","alpha(opacity=20)");
            $E('a.right').setStyle("-moz-opacity","0.2");
            $E('a.right').setStyle("-khtml-opacity", "0.2");
            $E('a.right').setStyle("opacity", "0.2");
        });
    }
}

You'll note that in addition to setting the default opacity, we have to add some events to mouseover and mouseout. This is because Mootools (currently) doesn't support CSS pseudoselectors, so we have to replace the .n:hover definitions in the CSS with Javascript events.

Now all we have to do is call this method on domready (or on window load in more old-skool cases):

	window.addEvent('domready',applyOpacity);

Here are the final opacity effects in action, at one of our client sites, Angel Guardians, Inc:

AJAX Slideshow at Angel Guardians, Inc.
Runtime-applied CSS opacity in an image slideshow. Look at the top left and top right corners.

And here's the gin in your martini:

Results from the CSS Validator.
Opacity, computing!

Hopefully you can see how this abstracts to any situation in which CSS opacity is being used on elements in an AJAX component, and also to any Javascript framework. You can always use document.getElementsByClassName('right'), or any other selector you
prefer, as well as window.onload = applyOpacity or your choice of any method of attaching a Javascript event.

Update (2008-05-24)

Due to some confusion regarding the application of this technique, I've created an example, which you can view online or download (12kb, zip).

These icons link to social bookmarking sites where readers can share and discover new web pages.
PaulMay 12, 2008
 

The Numbers Don’t Lie: Math speaks about Conditional Comments

When it comes time to choose which users to punish for Internet Explorer's broken family of rendering engines, making the right choice should be as easy as 11 minus 2.

We all know the scenario. Some movie protagonist is facing some movie antagonist, and the antagonist tells him to choose who dies, his (insert family member) or his (insert other family member). Always, always our good-hearted protagonist offers himself first. Only very rarely does this work.

Screen capture from Donnie Darko, the movie.
Donnie Darko, because his enemy is metaphysical, chooses himself. Ontic enemies rarely allow this.

The rest of the time, our insidious villain makes some smart comment, and we're back to square one. The Internet Explorer team's smart response to our valiant attempt to save all our users was to provide us the conditional comments specification. Please note, the villain will never just decide to give up his evil ways at this point. Never.

These icons link to social bookmarking sites where readers can share and discover new web pages.
PaulMay 2, 2008
 
Close this
E-mail It