16

I'm having some trouble getting CGI.pm to output to HTML5 instead of XHTML 1.0 or HTML 4.01. When I try "HTML5" or "HTML 5" as the -dtd argument in start_html() I get a document in HTML 4. I've also tried importing :HTML5, but that doesn't seem to work either. Any advice?

CyberSkull
  • 796
  • 1
  • 7
  • 16

4 Answers4

23

  1. The correct doctype for HTML 5 is just "html", not "html5" or "html 5", and does not use a DTD. CGI.pm only supports well-formed DTDs, not arbitrary strings. Since the HTML 5 doctype does not include a well-formed DTD, CGI.pm (as of the current version, 3.49) does not support the HTML 5 doctype.

  2. Using CGI.pm's HTML-generation functions is generally frowned upon these days. Templating systems such as Template::Toolkit or HTML::Template are preferred for their ability to cleanly separate your code's logic from the formatting of its output. They also, incidentally, allow you to specify whatever doctype and code to whatever version of (X)HTML you choose.

Dave Sherohman
  • 45,363
  • 14
  • 64
  • 102
  • Thanks. I've implemented a new version in using Template::Toolkit. Do you have any recommendations for HTTP handling modules? – CyberSkull Jun 11 '10 at 04:57
  • Personally, I've never had to do any low-level HTTP stuff myself beyond sending a Content-Type and some cookies, which is simple enough that you can get away with having CGI::Cookie generate the cookies, then just using `print` to send it all. If you post another question explaining exactly what kind of HTTP handling you want to do, I'm sure you'll get some good suggestions, though. – Dave Sherohman Jun 11 '10 at 08:13
8

Here's a fragment from some code where I 'solved' this problem using brute force.

# $html is accumulator for HTML string
my $html;

# <html> tag and <head> section
my $dtd      = '<!DOCTYPE html>';   # HTML5 DTD
my $title    = "Storage analysis of $HOSTNAME as of $TODAY";
$html    .= start_html(
    -title  => $title,
    -style  => {
        -code  => $css,
    }
);

# KLUDGE: CGI.pm doesn't support HTML5 DTD; replace the one it puts in.
$html    =~  s{<!DOCTYPE.*?>}{$dtd}s;
Dan Hale
  • 81
  • 1
  • 1
3

Here are some Perl5 frameworks that are HTML5 friendly:

Catalyst http://www.catalystframework.org/ Dancer http://perldancer.org/documentation Mojolicious http://mojolicio.us/

I'm leaning toward using Mojolicious for my newest Perl project.

All of these are more relevant for robust HTML5 apps than the CGI module. CGI still has its place and is still developed/supported but it does not address robust HTML5 apps as well as some of the frameworks that are out there.

Lance Cleveland
  • 3,098
  • 1
  • 33
  • 36
2

Patch the module to add support for HTML5 … or just output a Doctype manually, then use it as normal. If it is valid XHTML 1.0 or HTML 4.01 then it is valid HTML 5.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • Impressive, up to four people thinking this is worth voting down … but not yet any willing to say why. – Quentin May 13 '10 at 12:46
  • I think people are voting down because "patching" a CPAN module is generally a bad idea. Patching is likely bad advice. Inheritance or at least a monkey patch sound better. – codeholic May 13 '10 at 20:42
  • 5
    @codeholic First you write the patch, then you send the patch to the author ;) – hobbs May 13 '10 at 21:00
  • @hobbs ...and finally you wait for ages. – codeholic May 13 '10 at 21:22
  • If nobody patches it, where will version 3.50 come from? – Dave Sherohman May 14 '10 at 07:29
  • 1
    It's not that patching is a bad idea, but that using CGI.pm to create HTML is a bad idea. That makes patching CGI.pm to make HTML 5 a bad idea. – brian d foy May 14 '10 at 23:21
  • 1
    That's not really a helpful suggestion, I'm not in the mood to write a module, I just want to upgrade some old scripts. – CyberSkull May 15 '10 at 03:17
  • You're changing markup language to one which is in draft status because of your mood?! – Quentin May 15 '10 at 09:40
  • 1
    "Patch the module" generally isn't a useful answer all by itself, especially when it's said so matter-of-factly, as though it's something everyone does all the time. Now that I've looked in CGI.pm, it appears that it's *intended* to be edited locally to adjust various global defaults; this answer could have mentioned that. It also could have given some guidance about which of the more than 7600 lines of code would be a good place to start making changes. – Rob Kennedy May 15 '10 at 17:05
  • The point was that CGI.pm doesn't do HTML 5, so you'll have to add support for it if you want it to. – Quentin May 15 '10 at 18:56
  • 4
    Realize this is an old question (and comments), but time and time again people talk about how using CGI.pm to create HTML is a bad idea. If you're willing to take the performance hit, I don't see much of an argument these people have. It is functional programming, which is great since it's more future proof if you are delicate about maintaining the functions. -- I don't see how Catalyst/Mojolicious offer anything better over Mason, which is a pain to implement and use. – vol7ron Jan 09 '13 at 21:19