[Javascript] Best Practices

[Triche Osborne]

Paul Novitski wrote:
>> suppose the issue were validation instead? Do you . . .
>>         (1) attach onchange and/or onsubmit events through an external 
>> script
>> using the older forms collection and use alert-style messages instead of
>> pretty DOM errors;
>>         (2) or go DOM the whole way and let the server-side sticky 
>> validation
>> catch the non-DOM users?
> 
> 
> (3): server + DOM + alerts.
> 
> I always validate input server-side.  For DOM-aware browsers, I also 
> provide front-line validation client-side to save the user a few seconds 
> of their time or to provide some fancy footwork, but my server-side 
> application (where the real work is done because it's where I have 
> complete control) never assumes that the client-side validation is 
> present and awake to block the garbage-in.
> 
Absolutely. I'm  a firm believer in the Mulder school of server-side
development: Trust no one.

> If a browser isn't DOM-aware, it falls back to server-side processing.  
> When validation errors are detected on the server, I include the error 
> messages in the HTML markup so they stay on the screen, and I add js 
> alert scripts if desired to duplicate the error messages to make them 
> harder for the user to overlook.

Okay, with the exception of the added alerts, this is what I meant by
the second choice. Nice touch, the alerts. It give the user a heads-up
to look for the individual field messages.

> > 
>>         Re: graphic button image swaps: Do you . . .
>>         (1) use the old style of wrapping the image in an anchor tag 
>> which
>> contains omo/omo events;
>>         (2) attach the omo/omo to the anchor via the DOM so that, 
>> although
>> non-DOMs can't see the swap, the button still works;
>>         (3) or go DOM all the way, attaching the omo/omo/onclick 
>> behaviors
>> directly to the image? Although this latter disables the buttons, it
>> does not disable the functionality of the text links which you have (of
>> course you have) included for text-only users.
> 
> 
> (4): I use CSS a:hover for mouseover events and HTML anchors for click 
> processing, which eliminate the need to use JavaScript for those basic 
> navigation needs.  I generally attach background images to anchor 
> elements rather than wrapping the anchors around foreground image 
> elements.  I change images on rollover by toggling the CSS 
> background-position, including both image states in the same image file 
> so there's no time delay the first time an image is moused over 
> (eliminating the need for JS image preloading for nav menus).
> 
This sounds similar to an approach that I read about on ALA some time
ago and had completely forgotten about. (She has a V-8 moment.)

> 
> Please understand that I love using JavaScript, it's just that over the 
> past couple of years I've learned that I can produce page scripting 
> that's faster to create and easier to maintain and more elegently 
> degradable if I shift cosmetic mouse events to CSS that I used to handle 
> with JavaScript.  These days I use JS primarily for things like 
> client-side validation, converting anchor hrefs to form actions or 
> hidden form fields, drag & drop, and other nice-to-haves that enhance 
> the user's experience but don't leave the page broken when they're not 
> present.
> 
> I believe this is the point Steve Champeon is trying to make in pushing 
> "progressive enhancement" over "graceful degradation":  with PE you 
> start with a page that will work in any browser and then you add things 
> to enhance them for smarter browsers, rather than the GD approach of 
> starting with a page that requires a modern browser and then trying to 
> plug the holes for the older browsers.  While I maintain that both 
> strategies if done well will produce the same page, the pro-PE argument 
> is that we just get lazy with GD and inevitably leave some holes 
> unplugged.  I've seen too much of human nature to protest that too much.
> 
True. And it's not always laziness so much as so much to do, so little
time, and so many other clients to distract one . . .

> 
> Speaking as someone who supports myself and my household with web work, 
> these are absolutely nitty-gritty, every-day, practical concerns and not 
> simply philosophical musings.  I like to natter on about design beauty 
> and code elegance as much as the next person, but ultimately I have to 
> give my clients (and myself) robust pages that aren't going to break and 
> that I can change quickly & easily when the clients change their minds 
> (and they always do).
> 

Agreed. And this is why I asked. I'm not disdaining the philosophical
aspects at all, just saying that I need to establish practical
frameworks for integrating new ways of doing things client-side so that
they interact synergistically with each other and with what I'm doing
server-side.

Triche