Re: Accessible road maps

> I have read this several times and am unable to make any sense out of it.
> Are you simply trying to find ANY reason to dislike scripts?  It is this

Not any reason.  The main reasons I reject scripts by default are 
security (I will override only for sites for which I have a reasonable
level of trust - remember that typo squatting can make even safe
domain names dangerous) and the principle that sites should be about
information that can be processed by many tools, not just about remoting
of a visual interface on browser programs that need large teams to
develop them, and still don't work properly.

Secondary reasons are that scripts (rollovers) often almost double 
initial download times and that sites that break without scripting are,
in most cases, not worth viewing with scripting, as the gimmickry is 
a substitute for real content.

> attitude that inhibits, not promotes, good designs and coding practices.
> What does "...as it is common for the form actually submitted not to be
> the form that is completed by the user..." mean?  What happened to the 

It is quite common for the onsubmit action to copy the fields the user
entered into another form, all of whose fields are hidden, and then 
submit that.  The form the user sees does not have a proper action, 
and will fail without scripting.  In general, any script that uses the
form.submit method is likely to have this problem, and that is quite common.
(It might also have the problem that the form is unsubmittable without
scripting as there is no submit button.)

I think one reason for this is to avoid duplicating hidden state
when there is more than one sub-form on a single page.

> form the user completed?  What is actually submitted?  On what basis in 

Nothing, there is no valid action attribute for it.  It is quite likely
that it is an onclick, rather than an onsubmit, event that triggers
the processing that results in the real submit.

Also, and in the case of the example I can find quickly (photobox.co.uk),
this can be combined with the use of scripting to make links behave like
form controls, rather than links.


> fact are you able to state "...as it is common..."?  If it is common, 
> perhaps a long list of examples would be helpful?  

It's possible that it less common than it once was, but with such sites
I usually give in and either go somewhere else, or if there are strong
reasons for dealing with the company anyway, I probably turn on scripting
without analysing them these days.

> 
> I am also confused by the idea that submitting a form to a server and
> having it sent back to the user due to an error/omission on the form is
> a better, faster, or more accessible approach.  There is a significant 
> amount of discussion about load times, this approach requires doubling
> the load time.  Triggering an alert dialog box on the client side is not 

Not necessarily.  Firstly, the images won't be reloaded.  Secondly, such
pages typically have more scripting than display code, so the load time 
has been degraded by the scripting.  They probably use more bandwidth than
a pure server side implementation, although the latency will be greater.

However, as long as you realise that you have to write the validation code
twice, or use server side tools (like Microsoft's .NET web forms) that
generate two sets of validation code from the same source code, using
client side scripting for validation done the way it was intended to
be done, i.e. do the vaildation in onsubmit, rather than onclick, and
return false, you are likely to improve client responsiveness.

Note that properly written ASP.NET controls always duplicate the 
validation and will work withour client scripting.  I suspect many
user written controls only do the client side validation, although
that is a security no-no.

The real significance of this, though is that so many client side
vaidators do things wrongly, which is as strong indication that scripting
is too powerful a tool for most designers to use responsibly.  (Note that
the really big names, tend to get things right; most of the problems
are in the mass of big and medium companies which are not major web
based businesses.)

> unique to browser applications, yet when this technique is employed via 
> a browser objections are raised.  Please help me to understand the 
> difference between a word processing program and browser rendering an alert.

The code that intiates the alert in the word processing program was
installed from a, presumably, highly trusted source, whereas it isn't really
the browser that is raising the alert, but a program loaded from a
fairly arbitrary web site.  Moreover, the word processor behaves consistently
in how it uses the dialogue box, but each application program (scripted
web page) loaded from a "web" site can behave in its own peculiar way.
The word processor's dialogue box is akin to the file open box in IE.

Most companies would never allow you to download .EXEs from abitrary
web sites, but they do allow you to download powerful programs if they
are embedded in web pages.

Note that MSWord is not a word processor in the same sort of sense that
IE is not a web browser.  Both are really application platforms, although
scripting in Word documents is less common than in HTML and, normally
less intrusive; virus scanners are often set to reject Word documents
with macros, but doing so for HTML with scripts would cause real havoc,
for many users.  I've assumed that you meant the core program initiated
the dialogue, rather than a Word macro.

Also note that raising dialogue boxes is a low risk activity.  The main
risks these days come from the fact that scripts can interact with
"safe for scripting" ActiveX controls, which are often not safe for
scripting, although many cross-site scripting vulnerabilities have been
based on the core object model.

Basically, scripts are attractive because they are so powerful that they
allow an undisciplined approach that only cares about the immediate
subgoal.  Remeber, also that most sites are written by people copying
techniques from other sites, whilst not understanding them.

Received on Thursday, 3 June 2004 02:34:26 UTC