and its quirks

I’m a huge fan of the work­horse CGI Perl mod­ule (and pro­gram­mat­ic approaches to markup in gen­er­al). Why both­er your­self about ret­ro­fit­ting your present­a­tion tem­plates when new doc­types become avail­able — let the module/package/framework/whatever main­tain­er handle it for you. has an illus­tri­ous his­tory of sim­pli­fy­ing the hand­ling of input and out­put of HTTP data. There are numer­ous great recipes for build­ing and pro­cessing data flows, from the simple to the com­plex (the per­l­doc is very good too). Where can be some­what annoy­ing is in the some­what select­ively scant doc­u­ment­a­tion regard­ing cer­tain HTML tags — in this case for inline script­ing and styl­ing. So, take note of this par­tic­u­lar caveat. Whenev­er a HTML tag is added, with only para­met­ers passed and no actu­al con­tent, like a script tag to your markup that only ref­er­ences an extern­al source file (so dis­tant from the Uto­pi­anper­l­doc vis­ion of func­tions and calls being sep­ar­ated by head and body tags), make sure that you have an empty string in the block for to taste. Self closed tags oth­er than img and friends? Browser don’t play dat. Here’s a snip­pet of what I referred to: 
#!/usr/bin/env perl use strict; use warnings; use CGI; my $o = new CGI; print $o->script({-src=>'/path/to/script/file'},'');
Without that empty set of quotes, gives you this out­put: <script src="/path/to/script/file" />. Once the empty string is in there, how­ever, things work as expec­ted: <script src="/path/to/script/file"></script>.