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

[Paul Jordan]

interchange-users-bounces at icdevgroup.org wrote:
>> -----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.
>

Cameron

Try the extra="" param for button. I seem to remember throwing JS in there. You
will want your JS to activate a hidden CGI var <input type=hidden
name=was_looked_into value="">

Then in your profile, fall back to checking with IC if the JS was deactivated,
thus no 'was_looked_into' .

Paul