Coding for intranets (was RE: [thelist] Color Chooser Review -- c orrection)

[Steve Lewis]

JCanfield at magisnetworks.com wrote:

> If I control the environment (and will continue to control it unless I leave
> the company) what are the dangers of browser specific coding? Or, in Tom's

1) The browser developers may change their 'enhanced features' behavior
in a future version, breaking your code.  If your coding for M$, this
one counts double.

2) You may (want to) change your mind about your prefered environment
(ie you may decide that you really don't want to use IE) for some very
valid reason, and as you said you have control of the environment so
such a thing could happen.  Do you really want to code yourself into a
corner now?  What is the opportunity-cost of that early decision when
you do decide to bite the bullet and try to adapt the browser-specific code?

3) browser-specific tricks are often platform dependant too. Not likely
to be an issue if you have complete confidence in the OS-flavor in your
office and you have complete control; but be careful that your PHB does
not have some unstated expectation that your code works on his pretty
new platinum G4 laptop that he takes with him on vacation.  If you are
coding for M$, this one counts double.

> case, if it's not possible for a blind or other special user to even access
> the system, what are the real-world problems with coding with that in mind?

You want to know what the potential pitfalls of coding for your current
environment are?  Here are two reasons:

1) Things change. A legaly blind user may be a far-fetched case for most
of us but do we really need to enumerate the numerous OTHER disabilities
that our employers and clients may encounter and be forced to accomodate
in The Future.

There are more than a few very intelligent and employable people out
there who are, for one reason or another, not very good with computer
mice.  And what about all those folks out there who are red-green color
blind?  Someday they may work down the hall from you.  Marginalizing
these folk by saying they are uncommon in your userbase is really just a
Bad Idea IMnsHO.  You have to measure the costs involved, but if it
doesn't cost you too much up front to do it right...

2) The markup and code we write may very possibly be around after we are
dead and gone--really, and is almost guaranteed to survive beyond the
day that we are no longer employed with the organization we write it
for.  What sort of soup are you leaving for your children to clean up?
And even if our work is no longer in use, what about all the folks who
may reuse portions of our work in their own application?  *cough* Matt's
Script Archive *cough* *cough*

Let me illustrate with one of my favorite stories:

"I once wrote a program that was designed to work only on a computer at
Caltech.  The program was highly system dependant.  As I was the only
one who would ever use the program, the program would print the
following message if I got the command line wrong:

?LSTUIT User is a twit

A few years later I was a student at Syracuse University.  The secretary
at the School of Computer Science needed a program that was similar to
my Caltech listing program, so I adapted my program for her use.
Unfortunately, I had forgotten about my funny little error message.

Imagine how horrified I was when I came into the Computer Science office
and was accosted by the chief secretary.  This hady had so much power
she could make the dean cringe.  She looked at me and said, 'User is a
twit, huh?'  Luckily she had a sense of humor, or I might not be here
today."

from Practical_C++_Programming by Steve Oualline

We can laugh, but there is more truth to this than we can know.  Data
storage is cheep, and the Internet remembers the strangest stuff.
*cough* Usenet *cough* *cough*

> Are there cases where the rules can legitimately be ignored?
When the W3C standards ("the rules" in this case) are just written or
are not implemented in the browsers that you need to support, you
sometimes need to brew your own solutions until the browsers catch up.

Even then, think for a moment about all the folks who made
browser-specific dynamic tiered navigation menus for IE when it just
wasn't possible in other browsers--but who now should be hard at work
making it work under for NN7/Mozila since it can be done now.  Think of
all the hours they don't have free to watch Friends reruns because they
had to be on the bleeding edge of the web a year ago?

Your organization may be using 3 ActiveX components or other
browser-specific tools that you had no part in, but why set yourself up?
  Do you really want to put in 60 hour weeks a year from now when the
ActiveX components can be, and are, replaced with some other solution?

I will repeat one of my personal coding principles, because I think it
applies here.

<tip author="Steve Lewis">
Use native language tools:
If your language provides you a native high-level method to complete a
task, use it.  Your code will be easier to write, easier to document,
shorter and less prone to bugs, and probably more efficient at run time.
  Leave the messy details to the folks who write compilers and parsers
and get on with your work.
</tip>

It is not easy to keep up, especially with the W3C, with all of the
language developments for all the dialects of markup and code. But,
learning how to do it right is probably a large part of our jobs if we
think about it (and is why those other jokers pay us to write this stuff
rather than doing it themselves).

--Steve

P.S.
The author spent a good portion of his Tuesday evening hunting down bugs
in a large web application (4,510 KB of code) because it became
necessary to change the file paths for the application's code relative
to the content it manages.  (see also: 'things change')

P.P.S.
The author gets to spend the rest of the week improving the CSS and
meta-content implementation of said web application because he was lazy
and didn't look up the right way to do it the first time. (see also:
'learning how to do it right is probably a large part of our jobs')