[12029] in Perl-Users-Digest
Perl-Users Digest, Issue: 5629 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue May 11 14:07:26 1999
Date: Tue, 11 May 99 11:02:34 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 11 May 1999 Volume: 8 Number: 5629
Today's topics:
Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design <tchrist@mox.perl.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig (Aaron B. Dossett)
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <tchrist@mox.perl.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <tchrist@mox.perl.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <mkruse@rens.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <tchrist@mox.perl.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <propart@mediaone.net>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig (Charles R. Thompson)
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <tchrist@mox.perl.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <tchrist@mox.perl.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <propart@mediaone.net>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <mkruse@rens.com>
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig (Chris Nandor)
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig (I R A Aggie)
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig (Chris Nandor)
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig (Chris Nandor)
Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Desig <jeromeo@atrieva.com>
This code just wont run. Any ideas? <daniel.vesma@thewebtree.com>
Re: This code just wont run. Any ideas? (Charles R. Thompson)
Re: Warnings about uninintialised variables despite use (Charles R. Thompson)
Re: why won't this cgi script work? (Bart Lateur)
Re: why won't this cgi script work? <jeromeo@atrieva.com>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 11 May 1999 10:17:36 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <37385820@cs.colorado.edu>
+------------------------------------------------------+
| Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design |
+------------------------------------------------------+
by Tom Christiansen
It is extremely important that all information be maximally accessible
to everyone, even people who use systems different than your own.
If the choice ever comes down to making something should look nice for
some people at the expense of being virtually unusable to others, you
*must* choose the more humdrum look. This is about information sharing,
ladies and gentlemen, not about holding someone prisoner.
Here are ten simple guidelines I give to people designing HTML to help
them avoid unfairly discriminating against people who aren't like thems.
This provides optimal accessibility for all. I test all my web pages
under at least four different browsers: netscape, amaya, arena, and
especially lynx. Some people add emacs and opera as well. Think of it
as a form of "diversity compliance".
1) Have no absolute pixel widths for anything that isn't in pixels,
that is, pictures. No absolute widths for tables, table elements,
frames, or anything textual. This discriminates against people with
different sized windows or fonts than you have. Don't do that!
Test all pages by viewing them with both a large font (24pt) and a
small one (10pt), and both a large window (full 20" screen) and a
small one (small 4" window, like on a lap-top). I realize that the
smallest viewing areas are a something of an inevitable problem with
pictures, but you can at least minimize this risk by limiting it to
pictures alone, not to text.
2) Don't put everything in a table just because you're trying to
control widths (which you should *not* be doing). Doing so means
that nothing can be viewed until the whole page is downloaded, which
unfairly discriminates against people on modems. Don't do that!
Small embedded tables are ok, though. Break any large tables up
into manageable chunks. Test viewing of all pages over a 9600 or
at most a 19.2 baud modem connection. You might even try multiple
simultaneous loads over that connection for a taste of the real world.
3) All <IMG> tags must have useful ALT-text, and be navigable even
without pictures. Not doing this unfairly discriminates against
the visually challenged -- and the modemspeed-challenged as well.
Don't do that! Test this by loading the pages with lynx, or with
autoloading of graphics disabled.
4) Do not rely upon subtle color shadings to convey information. First
off, this unfairly discriminates against the color-blind, of
which there is no shortage in the male population. Don't do that!
Furthermore, what you see as a color is not absolute. People have
different monitors, and other applications might have stolen available
colors from the available palette. You might say "orange", and see
orange, but people on different systems who aren't even color-blind
might see yellow or red instead, just because this stuff is already
used in their X server. Most layout people don't realize this, but
it's the way the technology works; colors just aren't what you think
they are. And when used poorly, they are distracting.
4) Make sure that you use nothing but standard HTML. Never ever use
MS-HTML -- ever. It turns out that most tools that written by
Microsoft, or which target Microsoft systems, intentionally
employ non-standard, invalid extensions to plain ASCII text
and to the HTML character set. This unfairly discriminates
against people who do not wish to be locked into a closed,
proprietary systems. See http://mox.perl.com/misc/ms-ascii or
http://www.fourmilab.ch/webtools/demoroniser/ for further details.
5) Make sure the HTML validates. W3C has several validators, including
weblint -pedantic and more. It's very important to use these,
and to fix them if they've gone awry. Weblint is but one tool
out of many. Go to www.w3c.org for more validators.
6) Neal Postman wrote: "Contempt, rather than celebration, is the proper
response to advertising and the system that makes it possible." If you
do not wish to held in contempt, then don't force-feed readers adverts
they don't want to see it. If you feel you must use ads, these should be
subtly placed, low-key, and easily disabled by an opt-out strategy;
a good way to do this is to cluster them all on a separate page
that has only advertisements. Most importantly, there must be no
absolutely advertising on pages that are essentially informational,
like manpages or the magazine's articles.
This should not be misunderstood to be an admonition against
establishing standard headers and footers to provide a uniform look
and feel for the whole site are of course expected and fine, however.
Discrete textual footers are of course desirable.
7) There must be no moving pictures or pop-ups, *ever*, even if someone
wants to personally pay ten grand for it. These are unbelievably
disorienting -- even debilitating -- especially to that non-trivial
portion of hackers with attention-deficit disorder or task-switching
deficit disorder. The viewing of web pages must not put the reader
at risk of epileptic seizures.
8) Never use plug-ins of any sort. Are they available for all platforms?
Are they available for all browsers? Of course not. Therefore,
plug-ins only limit your audience. They probably violate several
of the other principles outlined about.
9) Eschew frames, javascript, java, and style-sheets. These are nearly
as bad as plug-ins for much the same reason. Additionally, some sites
completely disable javascript and java in the proxy at their corporate
firewall due to security concerns. If you can't avoid using these,
make sure you offer frame-free and javascript-free versions.
10) There is a special pit of hell reserved for those who use <BLINK>
tags. Don't even consider it. While not as bad as moving pictures,
it has similarly deleterious effects upon the target audience,
unfairly discriminating against the differently attented. You won't
want to be trapped in an elevator with a red flashing strobe light.
So don't do so to others.
--
"Even the most experienced programmers find faults in their programs"
HP-11C users's manual
------------------------------
Date: 11 May 1999 16:27:50 GMT
From: aarond@alpha.ewl.uky.edu (Aaron B. Dossett)
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <7h9lq6$jpb$1@news.uky.edu>
Tom Christiansen (tchrist@mox.perl.com) wrote:
:
: 6) Neal Postman wrote: "Contempt, rather than celebration, is the proper
: response to advertising and the system that makes it possible."
I believe you mean "Neil Postman".
-Aaron
------------------------------
Date: 11 May 1999 10:45:12 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <37385e98@cs.colorado.edu>
See also http://www.w3.org/WAI/GL/ and http://www.cast.org/bobby/
for style guides to help your diversity compliance. For example,
http://udl.cast.org/bobby?browser=AccEval&URL=www.yoursite.com will
prove highly instructive.
--tom
--
Mister Catbert, the company is trying to force me to use a different kind
of computer. You're the human resources directory. what are you doing
to sop this religious persecution?! What every happened to "Diversity"??
The longer you verk here, diverse it gets. next. --Scott Adams, "Dilbert"
------------------------------
Date: 11 May 1999 10:46:48 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <37385ef8@cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, aarond@alpha.ewl.uky.edu (Aaron B. Dossett) writes:
:: 6) Neal Postman wrote: "Contempt, rather than celebration, is the proper
:: response to advertising and the system that makes it possible."
:
:I believe you mean "Neil Postman".
I did. Darn it. Fixed in the master.
--tom
--
You have to admit that it's difficult to misplace the Perl sources. :-)
--Larry Wall in <1992Aug26.184221.29627@netlabs.com>
------------------------------
Date: Tue, 11 May 1999 11:49:55 -0700
From: "Matt Kruse" <mkruse@rens.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <7h9n93$3lj$1@ffx2nh3.news.uu.net>
While I would consider myself to be fairly "old-school-oriented" about
the web (having been active with it for over 5 years), I disagree
with your general attitude here.
You do NOT need to throw out all new technology because it doesn't fit
within your limited view of the web. There can be a happy medium between
using all the latest gadgets and writing HTML 2.0.
There has to be some expectation that people will keep up with technology.
People who write games don't expect to support 486's anymore, even though
there are plenty of people with them. Well, people who create web sites
these days can't be expected to support Netscape 2.0 with full
functionality either. People with out-of-date tools can only *expect* to
see things in a limited fashion.
Tom Christiansen wrote in message <37385820@cs.colorado.edu>...
>It is extremely important that all information be maximally accessible
>to everyone, even people who use systems different than your own.
It is not extremely important to everyone.
You must also remember that not everyone has the need to reach every
possible user on the Internet. Not everyone's information is so vital
that they can't afford to exclude a percentage of people from viewing
it properly.
>If the choice ever comes down to making something should look nice for
>some people at the expense of being virtually unusable to others, you
>*must* choose the more humdrum look.
This is simply not true.
>1) Have no absolute pixel widths for anything that isn't in pixels,
> that is, pictures.
I disagree. I hate it when sites use a centered, 500-pixel table for all
their content, but fixed-width tables are certainly nice for many things.
It doesn't exclude anyone from anything. You're generalizing *WAY* too
much on this one.
>4) Make sure that you use nothing but standard HTML. Never ever use
> MS-HTML -- ever.
Again, I disagree. I recently wrote a system which required IE5 to
function correctly. I required all users to use IE5. Either they chose
to comply and use the system, or they chose not to use the system. It's
that simple. Again... generalizing way too much.
>7) There must be no moving pictures or pop-ups, *ever*
This is ridiculous.
There are some valid reasons for animated gifs, and you shouldn't make
it sound so black-and-white. Also, pop-ups can be very handy tools for
context-sensitive help, etc.
>9) Eschew frames, javascript, java, and style-sheets.
Style sheets? Why would you not want people to use style sheets?
And javascript can be very handy to add functionality while also being
backwards-compatible for all browsers. You don't have to sacrifice
everything just to be backwards-compatible.
>10) There is a special pit of hell reserved for those who use <BLINK>
This is a moot point these days. Everyone knows this already, IMO.
------------------------------
Date: 11 May 1999 11:04:57 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <37386339@cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, "Matt Kruse" <mkruse@rens.com> writes:
:>9) Eschew frames, javascript, java, and style-sheets.
:Style sheets?
The style-sheet part was an error. Corrected.
:>10) There is a special pit of hell reserved for those who use <BLINK>
:This is a moot point these days. Everyone knows this already, IMO.
Then why do we have so many damned many epileptic strobepages now?
See my other followup for legitimate perl content.
--tom
--
"There lives more faith in honest doubt, believe me, than in half the creeds."
- Alfred, Lord Tennyson
------------------------------
Date: Tue, 11 May 1999 13:02:55 -0400
From: PropART <propart@mediaone.net>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <373862BF.D2D0A09B@mediaone.net>
5 Thoughts on 10 Tips
1. The web does not exist solely to be a delivery medium for information that is
simply formatted...
2. Design is more than making things look nice. Content and design are less
seperable than you think...
3. You can't design without controlling widths. Designing for a lowest common
denominator is also "discriminating". Every choice that you make has
consequences...
4. Yr. points on not using color to convey information, using ALT tags on
images, providing alternatives for older or specialized browsers (actually, this
is not *your* point, since a web author following yr. guidelines would never
have to provide an alternative), validating HTML, and not using <BLINK> are well
taken...
5. But, frames, javascript, and style sheets, and Flash are all good things
(however immature they may be at the moment)... If you truly want to do
something that requires them, you should use them, while making a decent effort
to provide alternatives for users who can't (or choose not to) support them...
-- William C.
------------------------------
Date: Tue, 11 May 1999 17:07:53 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <MPG.11a22f3bd6e562ff989690@news>
[This followup was posted to comp.lang.perl.misc and a copy was sent to
the cited author.]
In article <37385820@cs.colorado.edu>, Tom Christiansen says...
While I am guilty of skirting around a few of these, I offer some tidbits
you might consider adding.
> Test viewing of all pages over a 9600 or
> at most a 19.2 baud modem connection. You might even try multiple
> simultaneous loads over that connection for a taste of the real world.
Consider adding 'a total combined file size target of *less* than 30,000
bytes is considered desirable in most cases'.
A simple calculation of the transfer rate and combined file sizes will
give you a rough estimate for timing on different modem speeds. (A chart
here would be very beneficial of the 'wait' involved with 30,000 bytes
for 9600-? lines in optimal circumstances.)
> 4) Do not rely upon subtle color shadings to convey information. First
> off, this unfairly discriminates against the color-blind, of
> which there is no shortage in the male population. Don't do that!
> Furthermore, what you see as a color is not absolute. People have
> different monitors, and other applications might have stolen available
> colors from the available palette.
If you have to use lots of colors, invest some time in learning about the
'web safe color palette'. Combinations of 00 33 66 99 CC FF in RGB values
(example #CCFFFF) may give you the widest platform compatibility for
color. (Although your results are never guaranteed)
Color 'names' do not hold up between browsers. Period! An illustration of
this point is IE and Netscape, they only share about a dozen or so of the
'color names'. Not using the color palette can result in extreme
dithering on lower color systems and can can render your page totally
unreadable.
------
Tom... *Please* add this one. Even though I'm on a cable modem now, I can
remember this being my biggest gripe before.
10) When providing links to large files for download, report the file
size on the page so people know what they are getting into before they
click! While this involves an extra bit of maintenance, some people may
not want to download your 4 meg file with a 9600 modem. This information
should be provided as a courtesy. It's basically as frustrating as when
someone emails you an oversized file completely unannounced.
There were others, but they were picky and skirted on 'almost' compatible
ideas and didn't belong in there. :)
--
Charles R. Thompson
RainCloud Studios
"That? That's no script. That's your attempt at a rather complex README
file."
------------------------------
Date: 11 May 1999 11:10:41 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <37386491@cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, PropART <propart@mediaone.net> writes:
You, sir, are clearly a symtom of problem. If you want television,
you know where to find it.
--tom
--
"Thank heaven you can't buy happiness. We couldn't stand the commercials."
- Rick Jones
------------------------------
Date: 11 May 1999 11:11:23 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <373864bb@cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
PropART <propart@mediaone.net> writes:
:2. Design is more than making things look nice. Content and design are less
:seperable than you think...
:
:3. You can't design without controlling widths. Designing for a lowest common
:denominator is also "discriminating". Every choice that you make has
:consequences...
You are deeply confused about what HTML is. Followups to the
right newsgroup, please.
--tom
--
Chip Salzenberg sent me a complete patch to add System V IPC (msg, sem and
shm calls), so I added them. If that bothers you, you can always undefine
them in config.sh. :-) --Larry Wall in <9384@jpl-devvax.JPL.NASA.GOV>
------------------------------
Date: Tue, 11 May 1999 13:27:03 -0400
From: PropART <propart@mediaone.net>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <37386867.2E050236@mediaone.net>
> You are deeply confused about what HTML is. Followups to the
> right newsgroup, please.
>
> --tom
Not true... I understand the concept of seperating presentation from meaning...
This is a disagreement about whether design (in my sense) is important or whether
it's a relatively trivial "make it look nice" thing... whether the things that are
possible with DHTML and say, Flash, are (potentially, at least) worthy and
interesting, or whether they're just the gimmicks du jour... Off topic, probably,
but you made the original post...
-- William C.
------------------------------
Date: Tue, 11 May 1999 12:30:02 -0700
From: "Matt Kruse" <mkruse@rens.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <7h9pka$568$1@ffx2nh3.news.uu.net>
>You are deeply confused about what HTML is.
And you, Tom, are living in 1994.
Things change. People adapt. Technologies adapt. The world
advances.
If you wish to keep your head in the sand and continue living
in a fantasy world where everyone uses HTML 2.0 and text-based
browsers, that's your choice.
But, if you took your philosophy into a design meeting with a
client, you would get laughed at. IMO.
> Followups to the right newsgroup, please.
The only group I see on here is comp.lang.perl.misc. *shrugs*
Matt Kruse
mkruse@rens.com
------------------------------
Date: Tue, 11 May 1999 17:43:45 GMT
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <pudge-1105991343470001@192.168.0.77>
In article <37385820@cs.colorado.edu>, tchrist@mox.perl.com (Tom
Christiansen) wrote:
# 6) Neal Postman wrote: "Contempt, rather than celebration, is the proper
Neil :)
# 9) Eschew frames, javascript, java, and style-sheets. These are nearly
# as bad as plug-ins for much the same reason. Additionally, some sites
# completely disable javascript and java in the proxy at their corporate
# firewall due to security concerns. If you can't avoid using these,
# make sure you offer frame-free and javascript-free versions.
Style sheets aren't bad, as long as you follow the other guidelines well.
For browsers that do support them, you can get a nicer-looking page
without compromising your HTML.
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: 11 May 1999 17:30:19 GMT
From: fl_aggie@thepentagon.com (I R A Aggie)
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <slrn7jgqe9.s4e.fl_aggie@stat.fsu.edu>
On Tue, 11 May 1999 11:49:55 -0700, Matt Kruse <mkruse@rens.com>, in
<7h9n93$3lj$1@ffx2nh3.news.uu.net> wrote:
+ There has to be some expectation that people will keep up with technology.
+ People who write games don't expect to support 486's anymore, even though
+ there are plenty of people with them.
Before going off half-cocked, you need to understand something.
Some of us work for governmental agencies. It hasn't come down to serving
documents on the web, yet, but in the USA there's the ADA - Americans with
Disabilities Act. We're required to comply with it. That means serving up
content in such a manner that *any* citizen using *any* browser can
access the information, and that the information is still coherent.
A game developer doesn't have that looming overhead. I do.
+ >9) Eschew frames, javascript, java, and style-sheets.
+ Style sheets? Why would you not want people to use style sheets?
Ideally, style sheet are just formatting hints, and are optional.
If a browser doesn't understand a style sheet, it should ignore it.
James - Hey, Tom, more fodder for you sig file stash:
That beard, those suspenders, that smug expression! You're one of
those condescending Unix computer users!
Here's a nickel, kid. Get yourself a better computer.
-- Dilbert
------------------------------
Date: Tue, 11 May 1999 17:49:46 GMT
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <pudge-1105991349470001@192.168.0.77>
In article <37386867.2E050236@mediaone.net>, PropART
<propart@mediaone.net> wrote:
# > You are deeply confused about what HTML is. Followups to the
# > right newsgroup, please.
# >
# > --tom
#
# Not true... I understand the concept of seperating presentation from
meaning...
Please set the widths properly on whatever you use to post to this newsgroup.
Anyway, HTML by definition does define what something will look like.
Talking about defining presentation with HTML makes no sense. It's like
talking about playing baseball with golf clubs.
# This is a disagreement about whether design (in my sense) is important
or whether
# it's a relatively trivial "make it look nice" thing... whether the
things that are
# possible with DHTML and say, Flash, are (potentially, at least) worthy and
# interesting, or whether they're just the gimmicks du jour... Off topic,
probably,
# but you made the original post...
DHTML does not exist as a "thing". It is a mostly meaningless word used
to group together disparate technologies that people happen to use
together for some reason or another.
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Tue, 11 May 1999 17:51:55 GMT
From: pudge@pobox.com (Chris Nandor)
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <pudge-1105991351560001@192.168.0.77>
In article <7h9pka$568$1@ffx2nh3.news.uu.net>, "Matt Kruse"
<mkruse@rens.com> wrote:
# >You are deeply confused about what HTML is.
#
# And you, Tom, are living in 1994.
# Things change. People adapt. Technologies adapt. The world
# advances.
#
# If you wish to keep your head in the sand and continue living
# in a fantasy world where everyone uses HTML 2.0 and text-based
# browsers, that's your choice.
It has nothing to do with HTML 2.0. Again, HTML, by definition, cannot
define what something will look like, no matter what the version. HTML is
a *device-independent* markup language.
--
Chris Nandor mailto:pudge@pobox.com http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
------------------------------
Date: Tue, 11 May 1999 10:43:31 -0700
From: Jerome O'Neil <jeromeo@atrieva.com>
Subject: Re: Ten Tips toward *DIVERSITY COMPLIANCE* in Web Design
Message-Id: <37386C43.7C5BF7D@atrieva.com>
Tom Christiansen wrote:
>
> [courtesy cc of this posting sent to cited author via email]
> You are deeply confused about what HTML is. Followups to the
> right newsgroup, please.
Umm, Tom, you started this particular thread. What newsgroup should it
have been in?
--
Jerome O'Neil, Operations and Information Services
Atrieva Corporation, 600 University St., Ste. 911, Seattle, WA 98101
jeromeo@atrieva.com - Voice:206/749-2947
The Atrieva Service: Safe and Easy Online Backup http://www.atrieva.com
------------------------------
Date: Tue, 11 May 1999 18:49:13 +0100
From: "Daniel Vesma" <daniel.vesma@thewebtree.com>
Subject: This code just wont run. Any ideas?
Message-Id: <7h9qgv$h77$1@gxsn.com>
Hi,
This code for some reason doesn't want to run.
I tried to get it down to as small as possible, but it still doesn't run...
#!/usr/bin/perl
use CGI qw(param);
print "Content-type: text/html\n\n";
$ID = param("ID");
$PASS = param("PASS");
$body = param("body");
$to = "daniel.vesma@thewebtree.com";
$sendmail = "/usr/sbin/sendmail";
$sendmail_flags = "-oi -t";
######## I think this line is to blame ##########
open(MAIL,"|$sendmail $sendmail_flags") || &Exit("Could not execute
\"$sendmail\"");
#################################################
print MAIL <<"TAG";
X-Mailer: The Web Tree
From: $from
X-Ident-From: $real_remote_address
Subject: $subject
To: $to
Precedence: bulk
$body
TAG
close(MAIL);
print <<"END";
<HTML>
<HEAD>
<TITLE>private view 1.0</TITLE>
</HEAD>
<BODY">
<H1>Done</H1>
</BODY>
</HTML>
END
Thanks
Daniel Vesma
www.thewebtree.com
www.thewebtree.com/daniel-vesma
------------------------------
Date: Tue, 11 May 1999 17:59:22 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: This code just wont run. Any ideas?
Message-Id: <MPG.11a23b528171b8fd989693@news>
[This followup was posted to comp.lang.perl.misc and a copy was sent to
the cited author.]
In article <7h9qgv$h77$1@gxsn.com>, Daniel Vesma says...
> This code for some reason doesn't want to run.
s/want/can't/ Code cannot have a bad hair day.
> I tried to get it down to as small as possible, but it still doesn't run...
bigger isn't necessarily better holds true for smaller as well.
> #!/usr/bin/perl
#!/usr/bin/perl -w
use strict;
# look in your error logs for ... errors!
> use CGI qw(param);
#I've never seen it that way, I've always used...
use CGI qw(:standard);
$query = new CGI;
> print "Content-type: text/html\n\n";
print $query->header;
> $ID = param("ID");
> $PASS = param("PASS");
> $body = param("body");
> $to = "daniel.vesma@thewebtree.com";
my $to = "daniel.vesma\@thewebtree.com";
> $sendmail = "/usr/sbin/sendmail";
> $sendmail_flags = "-oi -t";
might ( read better) stick a my in front of all those variables.
> ######## I think this line is to blame ##########
maybe after it got through all the above.
I leave the rest to you and the error logs.
--
Charles R. Thompson
RainCloud Studios
------------------------------
Date: Tue, 11 May 1999 16:18:33 GMT
From: design@raincloud-studios.com (Charles R. Thompson)
Subject: Re: Warnings about uninintialised variables despite use strict
Message-Id: <MPG.11a223b254797c2998968e@news>
[This followup was posted to comp.lang.perl.misc and a copy was sent to
the cited author.]
In article <7h90hg$ntd$1@nnrp1.deja.com>, tertullian@my-dejanews.com
says...
> > You ought to be using CGI.pm, anyway.
> Now, I seem to be getting this from all angles so I'll look into it -
> thanks. Any good references and what are the advantages of using CGI.pm
> rather than the CGI::* Modules?
Features. The documentation gives you a pretty good clue as to what is
involved with each module. If you don't need a Perl interface to write
all your HTML output, javascript, etc... CGI_Lite is a much thinner
module. They both handle your CGI Forms and Uploads.
--
Charles R. Thompson
RainCloud Studios
"That? That's no script. That's your attempt at a rather complex README
file."
------------------------------
Date: Tue, 11 May 1999 16:03:32 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: why won't this cgi script work?
Message-Id: <37395474.1854707@news.skynet.be>
Ala Qumsieh wrote:
>Maybe perhaps he needs a chomp() there.
Well...
>open(COUNT, "> count.dat");
>$count += 1;
>print COUNT "$count";
>close (COUNT);
I don't think so. There's no newline there. And even it there were, it
would still work. It would give a warning when run using -w, though.
Bart.
------------------------------
Date: Tue, 11 May 1999 10:17:29 -0700
From: Jerome O'Neil <jeromeo@atrieva.com>
To: Care227@ibm.net
Subject: Re: why won't this cgi script work?
Message-Id: <37386629.8FCD8F06@atrieva.com>
Drew Simonis wrote:
> If you are doing this from a web page, you generally aren't going to use
> alot of file handles like that,
[ Snip ]
> Long stroy short, I am not saying it is improper or won't work, I was
> just asking why he was doing it.
For low intensity CGI work, I find it most beneficial to maintain
configuration data, select/options, layout data, and other common
information in configuration files. This is especially useful if you
have an application consisting of many scripts. You only have to make
changes in one place. In fact, I wrote a small package to handle just
this kind of stuff.
--
Jerome O'Neil, Operations and Information Services
Atrieva Corporation, 600 University St., Ste. 911, Seattle, WA 98101
jeromeo@atrieva.com - Voice:206/749-2947
The Atrieva Service: Safe and Easy Online Backup http://www.atrieva.com
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V8 Issue 5629
**************************************
