Mark:

What ever happened to idiot proof the code.  This means we should code 
to allow an idiot to understand what need to be done, not have idiots 
code and everyone else try to understand them.

It should be done right the first time....not after dozens of patches or 
rewrites.....

Olav.

Mark Wonsil wrote:

>Just a reply to James unrelated to Gary's request...
>
>James wrote:
>  
>
>>...  And why force people to go though
>>a javascript menu generator when a simple xhtml one suffices?  Many,
>>many business users have javascript from unapproved webs sites
>>blocked.  Why provide a user facing system that requires a risky
>>technology be enabled for it to work?  What happened to the idea of
>>graceful degradation? ...
>>    
>>
>
>Forget "graceful degradation" and consider Progressive Enhancement.
>The goal is the same but the approach is from the opposite direction.
>This should be taught in any web design course IMHO.
>
>Graceful degradation starts with a site that has certain features that
>works in a few targeted browsers and then tries to code for failure to
>fall-back to some basic working condition. The trouble is, with so
>many browsers (and versions) to support and with so many devices, it's
>impractical, I daresay impossible, to code for all possible failures.
>
>OTOH, Progressive Enhancement starts with a minimal document with no
>styling or scripting at all. The first attempt works in every browser
>from IE3, NN4, every cell phone in the world, and even Lynx. It also
>works with non-traditional web browsers like screen readers for the
>blind. If you're using forms, you put all validation on the server -
>FIRST. Next, one adds styling while keeping in mind that users can
>change font sizes, screen colors, etc. So if they don't like your
>styling, they may change it. Worse case scenario, they turn it off.
>But that's OK, because you designed your page to work with no styling.
>Finally, you add behavior. No inline JavaScript please. If a browser
>supports scripting, your JS should dynamically test for the
>capabilities of the particular browser and enable just those behaviors
>on the fly. Want to add client-side form validation? Great. But you
>still have to check at the server because scripting can be turned off.
>But if they do, ,that's OK because you still have server validation in
>place.
>
>For anyone who creates dynamic (X)HTML with ASP, ASP.Net, Perl, PHP,
>or JSP - this is the ONLY way to do it. Why garble up your code with
>in-line styles and scripting? What a pain in the ASCII!!!
>
>For more information on Progressive Enhancement:
>
>http://en.wikipedia.org/wiki/Progressive_enhancement
>http://www.alistapart.com/articles/understandingprogressiveenhancement/
>http://www.hesketh.com/publications/articles/progressive-enhancement-paving-the-way-for/
>http://icant.co.uk/articles/pragmatic-progressive-enhancement/
>http://www.filamentgroup.com/lab/progressive_enhancement_convert_select_box_to_accessible_jquery_ui_slider/
>or
>http://tinyurl.com/5n9gyg to see a jQuery Prog Enh example.
>
>Mark W.
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>  
>

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *