[ic] Client side javascript and the [button] tag.

[Cameron G]

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org 
> [mailto:interchange-users-bounces at icdevgroup.org] On Behalf 
> Of Ethan E. Rowe
> Sent: Wednesday, 19 May 2004 9:13 PM
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] Client side javascript and the [button] tag.
> 
> Peter wrote:
> 
> > Cameron G wrote:
> >
> >> Hi guys, I'm sitting here pondering the best way to achieve this 
> >> task, and I figured I'd throw it amongst a few other heads 
> and see if 
> >> anything comes up.
> >> Basically, on my checkout page, I want a checkbox they 
> must tick in 
> >> order for the submission to succeed. Of course, I can 
> check it within 
> >> the order profile, but that requires the page to be 
> reloaded - so I 
> >> was thinking client side JS. The only problem with this that I can 
> >> see is that the button tag appears to only have a confirm 
> option, not 
> >> an onClick. Am I wasting my time by pondering this, or is there an 
> >> easy way around it?
> >
> >
> > Use OnSubmit for the <Form> tag.  Keep in mind that disabling 
> > javascript will work around the requirement for checking the box.
> >
> Also keep in mind that there are still plenty of users out 
> there using non-javascript-supporting browsers such as Lynx.  
> This is an issue that comes up when you worry about 
> accessible design (though the accessibility guidelines tend 
> to focus more on how you use HTML and CSS stylistically); my 
> employer (National Braille Press, Inc) primarily serves the 
> braille-reading community, and I've consequently learned that 
> there are a lot of visually-impaired computer users out there 
> who prefer the command line interface to the 
> visually-oriented GUIs of Windows, Mac, etc.  Such users will 
> employ browsers such as Lynx, and it's extremely frustrating 
> for that community when sites are reliant on Javascript.  
> Just yesterday I encountered a site that requires users to 
> register in order to access any significant features, and the 
> registration form uses an <a href="...">...</a> tag rather 
> than a standard submit button; the anchor tag's HREF points 
> to a javascript function that authenticates and submits the 
> form.  Were the javascript function called via the OnSubmit 
> event of the <form>, that would be one thing (Lynx would be 
> free to ignore the OnSubmit); however, in this case, the link 
> just doesn't work in Lynx and consequently, the site is not 
> usable for a particular user community.
> 
> This is getting pretty picky, but perhaps it's of interest to 
> you.  Web design frequently gets into the sticky area of 
> backwards compatibility and it doesn't always make sense for 
> a particular organization to try to support older browsers.  
> However, considering the flexibility Interchange gives you in 
> form validation and error-reporting, the safest choice for 
> such things is to avoid javascript for critical functions 
> (unless you can absolutely guarantee that your users will run 
> a certain type of browser), and failing that, always back it 
> up with server-side validation/processing.
> 
> -Ethan Rowe
> Interchange site: www.nbp.org (primarily designed by End Point Corp
> www.endpoint.com)

Yep, you're right, it may just pay to atleast nod in the direction of
absolute backwards compatibility. To be honest, this whole thing is an
attempt to prevent customers entering the wrong addresses. Believe it or
not, but it would appear that a significant number of the people on this
planet don't actually know where they live, and it becomes quite an issue
when we've sent their goods to a place that they thought they lived at, but
really don't. I figure if I can atleast TRY to get them to make sure they
have everything right, it'll help. Who really knows.