http://www.perlmonks.org?node_id=1031923

space_monk has asked for the wisdom of the Perl Monks concerning the following question:

Monks, Nuns and Monkees,

How do I get CGI.pm to output the correct DOCTYPE (and any other HTML 5 specific content) for HTML5. Using the default_dtd doesn't seem to do it. Do I have to roll my own page headers?

I apologise if this question has been asked before, I feel it's so obvious it must have been. My only excuse for putting this question forward is that it's a Friday afternoon, I'm not feeling well and want to go home ;'(

Update: Thanks for all your suggestions. I'm not in a position to install libaries into the proper Perl installation, but I can probably slip one in as a local installation and will be trying this instead...

If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)

Replies are listed 'Best First'.
Re: CGI.pm and HTML5
by karlgoethebier (Abbot) on May 03, 2013 at 16:37 UTC
Re: CGI.pm and HTML5
by marto (Cardinal) on May 03, 2013 at 16:37 UTC

    It has been requested. Perhaps one of the modern frameworks already caters for this. CGI.pm is starting to really show it's age.

Re: CGI.pm and HTML5
by TomDLux (Vicar) on May 03, 2013 at 17:02 UTC

    Generating a web page with CGI is kinda like assembling a bookshelf by gluing chopsticks together. Yes, you get there, but you spend too much effort dealing with tiny details.

    Take a look at Catalyst, Dancer, Mojolicious, which greatly simplify the process of generating a set of pages for a website, including templating, common elements, authorization, and so on.

    As Occam said: Entia non sunt multiplicanda praeter necessitatem.

      Yes I would love to use more modern modules to do this but I'm a bit constrained by the environment I have to work in. None of those modules are installed. Its a fairly vanilla Perl 5.8.8 installation

      If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)

        I just installed Dancer on an old Solaris system with 5.8.8, no issues.

        While I can empathize with the need for infrastructure stability, relying on a seven year old release of any 'progressing' product is not good. Maybe you could use this bit friction to open a dialog with your 'powers to be' about modernizing the toolset?

        -derby
Re: CGI.pm and HTML5
by Anonymous Monk on May 03, 2013 at 17:44 UTC
Re: CGI.pm and HTML5
by sundialsvc4 (Abbot) on May 04, 2013 at 16:08 UTC

    The CGI module is exactly what it promises to be – which is to say, “not much.”   It literally consists only of “sugar” for the various elements of the HTTP protocol ... in the context of a vanilla-CGI script.   And yet, it is currently maintained, and everything that is said about it in the DESCRIPTION section of the CPAN page is still true:

    CGI.pm is a stable, complete and mature solution for processing and preparing HTTP requests and responses. Major features including processing form submissions, file uploads, reading and writing cookies, query string generation and manipulation, and processing and preparing HTTP headers. Some HTML generation utilities are included as well.

    CGI.pm performs very well in in a vanilla CGI.pm environment and also comes with built-in support for mod_perl and mod_perl2 as well as FastCGI.

    It has the benefit of having developed and refined over 10 years with input from dozens of contributors and being deployed on thousands of websites. CGI.pm has been included in the Perl distribution since Perl 5.4, and has become a de-facto standard.

    As you feared, if you want a DOCTYPE or anything-else in the HTML header, or anywhere else, you have to do it yourself.   You will need to use a debugger on the client side (e.g. Firebug) to actually examine precisely what the HTML returned is.   (Or, you can use curl.)

    It definitely would be worth your time to explore other options, like the CGI::Application family ... which, no surprise here really, uses CGI to do its heavy lifting, yet provides both a structured framework for “the whole enchilada” and introduces the concept of plugins, providing for a very helpful “separation of concerns.”   I suggest it because it is a relatively modest step from your present-state, yet offers excellent performance.