Multiple file upload and the abuse of buzzwords

2005-09-28T06:59:00-07:00

Stickman has posted a cool DOM-scripted multiple form upload and, of course, through no fault of his, commentors are assumming it must be AJAX, since it’s on the web and it’s new and cool. PPK has talked about this issue before but it looks like calling everything “AJAX” really is spreading to even geek bloggers watching web development (it’s only in the talkbacks, so far) who you would hope would be Marketing-ese proof.

Now, we’ve got nothing against AJAX, it’s a great technique that we like using, as appropriate, but this is DOM-scripting pure and simple. AJAX-like technologies have to do with how you handle the round trip to the server without reloading the page and, in this context, would look more like this (thanks to one of the other posters for the link). AJAX could be added onto Stickman’s work to just refresh the part of the page handling the upload, and something similar is used by Basecamp, already, to get around the multiple file upload another way.

Personally, I think what Stickman is doing is far cooler than AJAX, as he’s getting around a more fundamental browser limitation. What you can do with the HTML form upload control is severely restricted in browsers, largely for security reasons. For too long it’s been a basic assumption in web development that you might as well not try to do anything fancy with the form upload widget, since it’s fairly locked down. In fact, it’s still possible for the browser implementors to decide that hiding the widget is a potential security risk, and then this technique goes out the window. Until then, though, it’s useful to have in the toolbox, and even if it gets locked-out by some browsers in the future, it still gets us thinking about how to work around those limitations again.

Generally, I think the Basecamp approach of actually doing it through AJAX (similar to the “this” link above) would often be a better choice, as it allows more granular feedback and control. For instance they confirm each upload and then allow you to re-label it prior to sending a message off. This also avoids having to wait for one massive upload at the end, which might kill your whole message, instead of just the individual upload. Regardless, Stickman’s approach is still cool.

Cross-browser onDOMContentLoaded

2005-09-24T16:08:00-07:00

An elegant solution to the window.onload problem in Mozilla and IE.

Client-side developers have long been frustrated by the shortcomings of window.onload, namely that it takes too long before firing if you want to attach scripts to rework the DOM, yet you have to wait before the DOM is parsed before manipulating it.

The Greasemonkey chaps solved the problem in Mozilla Firefox by uncovering the proprietary DOMContentLoaded event. Now not solving the problem in all browsers would be acceptable, since the other browsers could fall-back to the late firing window.onload, but it’s unrealistic to consider a solution for general web use that doesn’t at least take care of 90% of the market (Windows IE).

Ever since the PPK mentioned something in his blog about a way to solve it in IE and Mozilla(maybe Safari) in the @media event entries a number of us have been very excited. We’ve been contemplating the best way to use this knowledge involving complicated schemes requiring behaviors in IE (.htc files) and waiting for the mysterious “more details to come”

Well, the details have arrived, and it seems to make most of the scripts to handle an early firing domloaded event moot. Dean Edwards has delivered an elegant solution to the window.onload problem in Mozilla and IE. If Safari/kthml, Opera, or any of the other browsers not covered by this are an important enough factor at your site, you might have to still think about an alternative like brothercake’s domFunction.

We’re going to just stick with Dean Edwards solution for now and call it good, though. Especially since, according to work done on the sIFR image replacement technique, Safari won’t layout the page properly until the images are loaded (read the 3rd comment). This means having Safari wait for the window.onload is actually a feature.

InfoSauce: Category CSS-DOM-standards

Multiple file upload and the abuse of buzzwords

Cross-browser onDOMContentLoaded