[23238] in Perl-Users-Digest
Perl-Users Digest, Issue: 5459 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 8 00:10:45 2003
Date: Sun, 7 Sep 2003 21:10:11 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 7 Sep 2003 Volume: 10 Number: 5459
Today's topics:
Re: HTML or XHTML in CGI [was: Help configuring Perl... <postmaster@castleamber.com>
Re: HTML or XHTML in CGI [was: Help configuring Perl... <noreply@gunnar.cc>
Re: HTML or XHTML in CGI [was: Help configuring Perl... <postmaster@castleamber.com>
Re: HTML or XHTML in CGI [was: Help configuring Perl... <noreply@gunnar.cc>
Re: HTML or XHTML in CGI [was: Help configuring Perl... <postmaster@castleamber.com>
Re: HTML or XHTML in CGI [was: Help configuring Perl... <flavell@mail.cern.ch>
Re: HTML or XHTML in CGI [was: Help configuring Perl... <postmaster@castleamber.com>
Re: <bwalton@rochester.rr.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 08 Sep 2003 03:09:19 +0200
From: John Bokma <postmaster@castleamber.com>
Subject: Re: HTML or XHTML in CGI [was: Help configuring Perl...]
Message-Id: <1062983463.224571@halkan.kabelfoon.nl>
Gunnar Hjalmarsson wrote:
> [sorry for my previous post - pushed the Send button by mistake. :( ]
:-)
> John Bokma wrote:
>
>> Gunnar Hjalmarsson wrote:
>>
>>> Defaulting to a more recent W3C recommendation does not appear
>>> odd or bad to me.
>>
>>
>> To me it does. It used to output HTML, now it switches to XHTML
>> "suddenly". This happens under the hood.
>
>
> <snip>
>
>> It means that an update of CGI.pm changes the output of CGI scripts
>> which is bad bad bad. Especially since CGI.pm belongs to the core
>> (IIRC). It means people have to update *all* their CGI scripts to make
>> it behave as it did in the past. Doesn't that strike you as somewhat odd?
>
>
> I see your point, but it rather strikes me as a natural consequence of
> using a module in such a dynamic area as generating HTML. (Personally
> I don't do that.)
>
> What would the alternative be? Never change anything, even if 'the
> outside world' changes?
There are two possibilities:
[1] stick to HTML unless told otherwise
[2] adapt to what is hot
The problem is that [2] changes the output of scripts each time CGI.pm
has a new idea of what is "hot".
Since there are some problems related with XHTML I don't think switching
to XHTML is such a good idea at the moment, especially since HTML is
still supported and probably will be supported for the next several
years by most if not all browsers.
Basically it means when somewhere a hosting provider updates CGI.pm a
customer of mine can get unexpected output from his script which can
make browsers of his customers behave odd...
--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: http://johnbokma.com/ ICQ: 218175426
John web site hints: http://johnbokma.com/websitedesign/
------------------------------
Date: Mon, 08 Sep 2003 03:31:51 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: HTML or XHTML in CGI [was: Help configuring Perl...]
Message-Id: <bjgmb3$isfdi$1@ID-184292.news.uni-berlin.de>
John Bokma wrote:
> Gunnar Hjalmarsson wrote:
>> I see your point, but it rather strikes me as a natural
>> consequence of using a module in such a dynamic area as
>> generating HTML. (Personally I don't do that.)
>>
>> What would the alternative be? Never change anything, even if
>> 'the outside world' changes?
>
> There are two possibilities:
>
> [1] stick to HTML unless told otherwise
> [2] adapt to what is hot
>
> The problem is that [2] changes the output of scripts each time
> CGI.pm has a new idea of what is "hot".
>
> Since there are some problems related with XHTML I don't think
> switching to XHTML is such a good idea at the moment, especially
> since HTML is still supported and probably will be supported for
> the next several years by most if not all browsers.
I can understand that you question the _timing_ for the change,
especially after having studied the documents you and Vlad pointed us
to. (Thanks for those links!)
> Basically it means when somewhere a hosting provider updates CGI.pm
> a customer of mine can get unexpected output from his script which
> can make browsers of his customers behave odd...
To me that appears as an unavoidable problem - sooner or later.
Possibility [1] would of course be an option for the time being.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 08 Sep 2003 03:39:22 +0200
From: John Bokma <postmaster@castleamber.com>
Subject: Re: HTML or XHTML in CGI [was: Help configuring Perl...]
Message-Id: <1062985266.249046@halkan.kabelfoon.nl>
Gunnar Hjalmarsson wrote:
> John Bokma wrote:
[snip CGI.pm outputting XHTML]
>> There are two possibilities:
>>
>> [1] stick to HTML unless told otherwise
>> [2] adapt to what is hot
>>
>> The problem is that [2] changes the output of scripts each time
>> CGI.pm has a new idea of what is "hot".
>>
>> Since there are some problems related with XHTML I don't think
>> switching to XHTML is such a good idea at the moment, especially
>> since HTML is still supported and probably will be supported for
>> the next several years by most if not all browsers.
>
>
> I can understand that you question the _timing_ for the change,
> especially after having studied the documents you and Vlad pointed us
> to. (Thanks for those links!)
You are welcome.
>> Basically it means when somewhere a hosting provider updates CGI.pm
>> a customer of mine can get unexpected output from his script which
>> can make browsers of his customers behave odd...
>
> To me that appears as an unavoidable problem - sooner or later.
> Possibility [1] would of course be an option for the time being.
Indeed. But even [2] say in 2005 means it will going to change the
output of scripts. It changes the output without the programmer doing
anything. I consider that weird.
Maybe I am biased since I remember one of my scripts almost bringing a
web server on its knees because "while ($line = <FILE>) {" suddenly
wanted a defined around the $line=<FILE> part. Hence the error log was
flooded with warnings.
--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: http://johnbokma.com/ ICQ: 218175426
John web site hints: http://johnbokma.com/websitedesign/
------------------------------
Date: Mon, 08 Sep 2003 03:46:45 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: HTML or XHTML in CGI [was: Help configuring Perl...]
Message-Id: <bjgn73$iumnk$1@ID-184292.news.uni-berlin.de>
John Bokma wrote:
> ... even [2] say in 2005 means it will going to change the output
> of scripts. It changes the output without the programmer doing
> anything.
Unless you - by then - have modified the scripts to output XHTML. :)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 08 Sep 2003 04:05:33 +0200
From: John Bokma <postmaster@castleamber.com>
Subject: Re: HTML or XHTML in CGI [was: Help configuring Perl...]
Message-Id: <1062986837.691978@halkan.kabelfoon.nl>
Gunnar Hjalmarsson wrote:
> John Bokma wrote:
>
>> ... even [2] say in 2005 means it will going to change the output
>> of scripts. It changes the output without the programmer doing anything.
>
>
> Unless you - by then - have modified the scripts to output XHTML. :)
No no, that it already (!) does. The weird thing is that I, if I had
used the HTML generating abilities of CGI.pm have to contact several
customers and send them an update of the script (forcing CGI.pm *not* to
output XHTML). And I am afraid that I can not charge them for that.
"Since your provider has updated a library I had to modify your script(s)".
--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: http://johnbokma.com/ ICQ: 218175426
John web site hints: http://johnbokma.com/websitedesign/
------------------------------
Date: Mon, 8 Sep 2003 03:37:04 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: HTML or XHTML in CGI [was: Help configuring Perl...]
Message-Id: <Pine.LNX.4.53.0309080321560.8401@lxplus007.cern.ch>
On Mon, Sep 8, John Bokma inscribed on the eternal scroll:
> There are two possibilities:
>
> [1] stick to HTML unless told otherwise
> [2] adapt to what is hot
>
> The problem is that [2] changes the output of scripts each time CGI.pm
> has a new idea of what is "hot".
>
> Since there are some problems related with XHTML I don't think switching
> to XHTML is such a good idea at the moment,
Neither do I, as it happens; but I'm not sure that was so evident at
the time the change was made to CGI.pm. L.S was clearly relying on
the so-called Appendix C compatibility - which I rate as a mistake,
but that's not to impute that there wasn't an honest intention behind
it.
> especially since HTML is still supported
Well, that rather depends on what you understand "HTML" to be. The
W3C's specifications are self-contraditory, as they on the one hand
define HTML to be an application of SGML, while on the other hand
outlawing things which SGML doesn't allow to be outlawed.
> and probably will be supported for the next several years by most if
> not all browsers.
It's pretty clear that the key features of XML (specifically:
declaring erroneous content to be unusable and quitting) will never be
"supported" by browsers. The merchants of tag-soup couldn't allow it.
So the choice is between HTML-flavoured tag soup, which was the
problem that XML was aimed to solve; or quasi-XHTML-flavoured tag
soup, which brings us the worst of both worlds.
But at the time that CGI.pm made the change, this might not have been
so evident ;-}
> Basically it means when somewhere a hosting provider updates CGI.pm a
> customer of mine can get unexpected output from his script
Well, I don't think that old versions of CGI would mind if you told
them not to generate XHTML. Then you'd be all set for an update.
In an ideal world, it might not have happened that way, but the CGI.pm
change to XHTML isn't exactly new - you appear to be fighting last
year's battles, to be fran^W honest.
all the best
------------------------------
Date: Mon, 08 Sep 2003 04:28:42 +0200
From: John Bokma <postmaster@castleamber.com>
Subject: Re: HTML or XHTML in CGI [was: Help configuring Perl...]
Message-Id: <1062988226.98771@halkan.kabelfoon.nl>
Alan J. Flavell wrote:
> On Mon, Sep 8, John Bokma inscribed on the eternal scroll:
[snip HTML]
>>and probably will be supported for the next several years by most if
>>not all browsers.
>
> It's pretty clear that the key features of XML (specifically:
> declaring erroneous content to be unusable and quitting) will never be
> "supported" by browsers.
Indeed. I even don't want to think about how many websites would be made
unusable by that sadly. One of the reasons for me switching to XHTML was
the forced well formedness and such. I am going to switch to one XML
file which is transformed to the HTML 4.01 files for my site. I want to
start with Perl for this (and several XML related modules of course).
> But at the time that CGI.pm made the change, this might not have been
> so evident ;-}
I can understand that. To be honest I rarely used the HTML abilities (if
ever, I can't remember) of the CGI module. The reason it had my interest
(again) was that I discovered two rather stupid mistakes in a script I
wrote that generates HTML files based on directory structure, image
files in it and a file that contains descriptions. I wrote twice <tr>
instead of </tr> which could have been prevented if I used the tr (?)
function / method.
>>Basically it means when somewhere a hosting provider updates CGI.pm a
>>customer of mine can get unexpected output from his script
>
> Well, I don't think that old versions of CGI would mind if you told
> them not to generate XHTML. Then you'd be all set for an update.
:-). Imagine updating 20-30 scripts for 10-20 customers all for free
:-(. I am lucky that I used templates or other ways to generate the HTML.
> In an ideal world, it might not have happened that way, but the CGI.pm
> change to XHTML isn't exactly new - you appear to be fighting last
> year's battles, to be fran^W honest.
All thanks to me not using CGI.pm's abilities to generate HTML :-D.
--
Kind regards, feel free to mail: mail(at)johnbokma.com (or reply)
virtual home: http://johnbokma.com/ ICQ: 218175426
John web site hints: http://johnbokma.com/websitedesign/
------------------------------
Date: Sat, 19 Jul 2003 01:59:56 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re:
Message-Id: <3F18A600.3040306@rochester.rr.com>
Ron wrote:
> Tried this code get a server 500 error.
>
> Anyone know what's wrong with it?
>
> if $DayName eq "Select a Day" or $RouteName eq "Select A Route") {
(---^
> dienice("Please use the back button on your browser to fill out the Day
> & Route fields.");
> }
...
> Ron
...
--
Bob Walton
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
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.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.
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 V10 Issue 5459
***************************************
