Darren Duncan


HTML::EasyTags - Make well-formed XHTML or HTML 4 tags, lists


Perl Version


Standard Modules


Nonstandard Modules



        use HTML::EasyTags;

        my $html = HTML::EasyTags->new();
        $html->groups_by_default( 1 );

                        'This Is My Page',
                        $html->style( { type => 'text/css' }, 
                                $html->comment_tag( <<__endquote ) ),
        \nbody {
                background-color: #ffffff; 
                background-image: none;
                $html->h1( 'A Simple Example' ),
                        "Click " . 
                        $html->a( href => 'http://search.cpan.org', text => 'here' ) . 
                        " for more."
                        $html->tr( [
                                $html->th( [ 'Name', 'Count', 'URL', 'First Access' ] ), 
                                $html->td( [ 'Old Page', 33, 'http://www.domain.com', 
                                        '1999/04/23 13:55:02' ] )
                        ] )
                $html->form_start( method => 'post', action => 'http://localhost' ),
                        "What's your name? " . 
                        $html->input( type => 'text', name => 'name' ) 
                        "What's the combination?" .
                                -type => 'checkbox', 
                                -name => 'words',
                                -value => ['eenie', 'meenie', 'minie', 'moe'],
                                -checked => [1, 0, 1, 0],
                                -text => ['Eenie', 'Meenie', 'Minie', 'Moe'] ),
                        "What's your favorite colour? " .
                        $html->select_start( -size => 1, -name => 'color' ) .
                                -value => ['red', 'green', 'blue', 'chartreuse'], 
                                -text => ['Red', 'Green', 'Blue', 'Chartreuse'] ) .
                $html->input( type => 'submit' ),


This Perl 5 object class can be used to generate any well-formed XHTML or HTML tags in a format that is consistent with the W3C XHTML 1.0 or HTML 4.01 standards. See http://www.w3.org/TR/xhtml1 and http://www.w3c.org/MarkUp for references. There are no restrictions on what tags are named, however; you can ask for any new or unsupported tag that comes along from Netscape or Microsoft, and it will be made. Additionally, you can generate lists of said tags with one method call, or just parts of said tags (but not both at once).

This module's purpose is to be lightweight, easy to use, and whose results are well-formed and pretty-printed (should humans wish to read or debug it). At the same time, it is supportive of your existing knowledge of HTML and as such its interface closely mirrors the actual appearance of the resulting tags. This means that methods have the same name as the actual tags, and named parameters that you pass correspond directly to the tag attributes produced. This module saves you having to remember the little details on formatting. For your convenience, a majority of the methods and their arguments are backwards-compatible with those in CGI.pm, but you are saved 200K of code size.

As a reference, I strongly recommend that you check out Kevin Werbach's excellent "The Bare Bones Guide to HTML", which is available at http://werbach.com/barebones/. I found this document invaluable when making this module, as it provides a comprehensive list of all the HTML tags along with their formatting and extensions.

In this implementation, "well formed" means that tags are made as pairs by default, which look like "<tag></tag>", unless they are known to be "no pair" tags, in which case they look like "<tag />". Tags that I know to be "no pair" are [basefont, img, area, param, br, hr, input, option, tbody, frame, comment, isindex, base, link, meta]. However, you can force any tag to be "pair" or "start only" or "end only" by appropriately modifying your call to the tag making method.

Also, "well formed" means that tag attributes are formatted as "key=value". While the HTML standard allowed there to be "no value" attributes, XHTML does not. These were formatted simply as "key" because their very presence indicates positive assertion, while their absense means otherwise. Before release 1-06, attributes that were known to be "no value" attributes were formatted as "key" by default. Modifiers that I know to be "no value" are [ismap, noshade, compact, checked, multiple, selected, nowrap, noresize, param]. As of release 1-06, "no value" attributes are formatted as 'key="1"' when they are true and they are absent when false, to keep backwards compatability. "Well formed" means that attribute values will always become bounded by quotes, which ensures they work with both string and numerical quantities (eg: key="value").

Convenience methods start_html() and end_html() are provided to generate the required HTML that appears above and below your content; however, you can still make said HTML one tag at a time if you wish.


        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
        <title>This Is My Page</title>
        <style type="text/css">
        body {
                background-color: #ffffff; 
                background-image: none;
        <h1>A Simple Example</h1>
        <a href="http://search.cpan.org">here</a> for more.</p>
        <hr />
        <th>First Access</th></tr>
        <td>Old Page</td>
        <td>1999/04/23 13:55:02</td></tr></table>
        <hr />
        <form method="post" action="http://localhost">
        <p>What's your name? 
        <input type="text" name="name" /></p>
        <p>What's the combination?
        <input type="checkbox" name="words" checked="1" value="eenie" />Eenie
        <input type="checkbox" name="words" value="meenie" />Meenie
        <input type="checkbox" name="words" checked="1" value="minie" />Minie
        <input type="checkbox" name="words" value="moe" />Moe</p>
        <p>What's your favorite colour? 
        <select name="color" size="1">
        <option value="red" />Red
        <option value="green" />Green
        <option value="blue" />Blue
        <option value="chartreuse" />Chartreuse
        <input type="submit" />


This class does not export any functions or methods, so you need to call them using object notation. This means using Class->function() for functions and $object->method() for methods. If you are inheriting this class for your own modules, then that often means something like $self->method().

Methods of this class always "return" their results, rather than printing them out to a file or the screen. Not only is this simpler, but it gives the calling code the maximum amount of control over what happens in the program. They may wish to do post-processing with the generated HTML, or want to output it in a different order than it is generated. By default, all results are returned as a scalar, but methods which generate a list of tags can optionally return an ARRAY ref, with each element containing a single tag. This can aid in post-processing and possibly speed up the program because there is less copying done.

Through the magic of autoloading, this class can make any html tag by calling a class method with the same name as the tag you want. For examples, use "hr()" to make a "<hr />" tag, or "p('text')" to make "<p>text</p>". This also means that if you mis-spell any method name, it will still make a new tag with the mis-spelled name. For autoloaded methods only, the method names are case-insensitive.

If you call a class method whose name ends in either of ['_start', '_end', '_pair', '_mini'], this will be interpreted as an instruction to make just part of one tag whose name are the part of the method name preceeding that suffix. For example, calling "p_start( 'text' )" results in "<p>text" rather than "<p>text</p>". Similarly, calling "p_end()" will generate a "</p>" only. Using the '_pair' suffix will force tags to be made as a pair, whether or not they would do so naturally. For example, calling "br_pair" would produce a "<br></br>" rather than the normal "<br />". Calling "p_mini( 'text' )" results in "<p />text". When using either of ['_start', '_pair', '_mini'], the arguments you pass the method are exactly the same as the unmodified method would use, and there are no other symantec differences. However, when using the '_end' suffix, any arguments are ignored, as the latter member of a tag pair never carries any attributes anyway.

If you call a class method whose name ends in "_group", this will be interpreted as an instruction to make a list of tags whose name are the part of the method name preceeding the "_group". For example, calling "td_group( ['here','we','are'] )" results in "<td>here</td><td>we</td><td>are</td>" being generated. The arguments that you call this method are exactly the same as for calling a method to make a single tag of the same name, except that the extra optional parameter "list" can be used to force an ARRAY ref of the new tags to be returned instead of a scalar. The symantec difference is that any arguments whose values are ARRAY refs are interpreted as a list of values where each one is used in a separate tag; for a single tag, the literal ARRAY ref itself would be used. The number of tags produced is equal to the length of the longest ARRAY ref passed as an argument. For any other arguments who have fewer than this count, their last value is replicated and appended enough times as necessary to make them the same length. The value of a scalar argument is used for all the tags. For example, calling "input_group( type => checkbox, name => 'letters', value => ['a','b','c'] )" produces '<INPUT TYPE="checkbox" NAME="letters" VALUE="a"><INPUT TYPE="checkbox" NAME="letters" VALUE="b"><INPUT TYPE="checkbox" NAME="letters" VALUE="c">'.

All autoloaded methods require their parameters to be in named format. These names and values correspond to attribute names and values for the new tags. Since "no value" attributes are essentially booleans, they can have any true or false value associated with them in the parameter list, which won't be printed. If an autoloaded method is passed exactly one parameter, it will be interpreted as the "text" that goes between the tag pair (<tag>text</tag>) or after "start tags" (<tag>text). The same result can be had explicitely by passing the named parameter "text". The names of any named parameters can upper or lower or mixed case, as is your preference, and optionally start with a "-".

All static (non-autoloaded) methods require positional parameters.


Note that all the methods defined below are static, so information specific to autoloaded methods won't likely apply to them. All of these methods take positional arguments.


This function creates a new HTML::EasyTags object (or subclass thereof) and returns it.


This method is used by new() to set the initial properties of an object, that it creates. All page attributes are wiped clean, resulting in an empty page.

clone([ CLONE ])

This method initializes a new object to have all of the same properties of the current object and returns it. This new object can be provided in the optional argument CLONE (if CLONE is an object of the same class as the current object); otherwise, a brand new object of the current class is used. Only object properties recognized by HTML::EasyTags are set in the clone; other properties are not changed.

groups_by_default([ VALUE ])

This method is an accessor for the boolean "automatic grouping" property of this object, which it returns. If VALUE is defined, this property is set to it. In cases where we aren't told explicitely that autoloaded methods are making a single or multiple tags (using ['_start', '_end', '_pair', '_mini'] and '_group' respectively), we look to this property to determine what operation we guess. The default is "single". When this property is true, we can make both single and groups of tags by using a suffix-less method name; however, making single tags this way is slower than when this property is false. Also, be aware that when we are making a "group", arguments that are ARRAY refs are always flattened, and when we are making a "single", ARRAY ref arguments are always used literally.

prologue_tag([ VALUE ])

This method is an accessor for the scalar "prologue tag" property of this object, which it returns. If VALUE is defined, this property is set to it. This property is meant to be used literally and be the very first thing in an XHTML or HTML document. It tells the web browser such things as what version of the HTML standard we are adhering to. Citing backwards compatability with earlier versions of this class, the default prologue tag we make is for HTML version 4.0 and looks like '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">'.

comment_tag( TEXT )

This method returns a comment tag, which is only visible to people viewing the HTML source of a document, and not otherwise. It can take either a scalar or a list or an Array ref as its TEXT argument. If a single item of text is passed, then a comment tag that looks like "<!-- text -->" is made. If more than one item of text is passed, then a multi-line comment is made, which has each item of text on its own line and indented with a single tab. The latter is suitable for displaying CSS or JavaScript code in an elegant manner.

make_html_tag( NAME[, PARAMS[, TEXT[, PART]]] )

This method is used internally to do the actual construction of single html tags. You can call it directly when you want faster code and/or more control over how tags are made. The first argument, NAME, is a scalar that defines the actual name of the tag we are making (eg: 'br'); it is case-insensitive. The optional second argument, PARAMS, is a HASH ref containing attribute names and values for the new tag; the names (keys) are case-insensitive. The attribute values are all printed literally, so they should be scalars. The optional third argument, TEXT, is a scalar containing the text that goes between the tag pairs; it is not a tag attribute. The optional fourth argument, PART, is a scalar which indicates we should make just a certain part of the tag; acceptable values are ['pair', 'start', 'end'], and it is case-insensitive. This method knows which HTML tags are normally paired or not, which tag attributes take specified values or not, and acts accordingly.

make_html_tag_group( NAME[, PARAMS[, TEXT[, LIST]]] )

This method is used internally to do the actual construction of html tag groups. You can call it directly when you want faster code and/or more control over how tags are made. The first argument, NAME, is a scalar that defines the actual name of the tag we are making (eg: 'br'); it is case-insensitive. The optional second argument, PARAMS, is a HASH ref containing attribute names and values for the new tag; the names (keys) are case-insensitive. Any attribute values which are ARRAY refs are flattened, and the number of tags made is determined by the length of the longest one. The optional third argument, TEXT, is a HASH ref (or scalar) containing the text that goes between the tag pairs; it is not a tag attribute, but if its an ARRAY ref then its length will influence the number of tags that are made as the length of tag attribute arrays do. The optional fourth argument, LIST, is a boolean/scalar which indicates whether this method returns the new tags in an ARRAY ref (one tag per element) or as a scalar (tags are concatenated together); a true value forces an ARRAY ref, scalar is the default. This method knows which HTML tags are normally paired or not, which tag attributes take specified values or not, and acts accordingly.

start_html([ TITLE[, HEAD[, BODY[, FRAMESET]]] ])

This method returns a canned HTML template that is suitable for use as the top of an HTML page. It consists of the prologue tag (<!DOCTYPE...), the opening 'html' tag, the entire 'head' section, and the opening 'body' tag. The prologue tag looks the same as that generated by the class method prologue_tag(). The first optional argument, TITLE, is a scalar which defines the title for the document, and its default value is 'Untitled Document'. The second argument, HEAD, is an Array ref (or scalar) containing anything else you would like to appear in the 'head' section; it is flattened and the elements used as-is. The third argument, BODY, is a Hash ref containing attributes and values for the opening 'body' tag. As of release 1.05 this class supports frameset documents as well as normal HTML. If the fourth argument, FRAMESET, is true, then it is assumed we will be making a frameset document, whereby the body section is wrapped in a <noframes> pair and there is a <frameset> pair between the head and noframes/body sections. FRAMESET is a Hash ref that contains the attributes and values that go in the opening frameset tag (analogous to BODY argument), except that a 'text' attribute will be resolved into the text that goes inside the frameset pair, as with any autoloaded tag methods. So the 'text' attribute of FRAMESET is where the "frame" tag html that you previously rendered goes. If FRAMESET is true but not a hash, it will be taken literally as 'text' likewise as with autoloaded methods.

end_html([ FRAMESET ])

This method returns a canned HTML template that is suitable for use as the bottom of an HTML page. It consists of the closing 'body' and 'html' tags. As of release 1.05 this class supports frameset documents as well as normal HTML. If the optional argument FRAMESET is true, then there is a closing 'noframes' tag between the closing 'body' and 'html' tags.


The methods of this class and their parameters are designed to be compatible with any same-named methods in the popular CGI.pm class. This class will produce browser-compatible (and often identical) HTML from such methods, and this class can accept all the same argument formats. Exceptions to this include:


None of our methods are exported and must be called using object notation, whereas CGI.pm can export any of it's methods.


Autoloaded methods do not use the presence or absence of arguments to decide whether to make the new tag as a pair or as "start only". Also, CGI.pm does not do end-only tags.


Autoloaded methods that make html tags won't concatenate their arguments into a single argument under any circumstances, but in some cases the "shortcuts" of CGI.pm will do so.


We go further to make the generated HTML human-readable by: 1. having each new tag start on a new line; 2. making all tag and attribute names lowercase; 3. ensuring that about 20 often-used tag attributes always appear in the same order (eg: 'type' is before 'name' is before 'value'), and before any others.


Our textarea() method is autoloaded, and doesn't have the special symantecs that CGI.pm's textarea() does.


Our convenience method start_html() is very simple and only accepts the three positional arguments ['title', 'head', 'body']. Title is the most commonly used argument by far, and you can easily replicate the effects of missing arguments by making appropriate tags explicitely and passing them with the "head" argument. As of release 1.05, this method and end_html() also provided explicit frameset document support, and CGI.pm has no explicit frameset support.


Copyright (c) 1999-2003, Darren R. Duncan. All rights reserved. This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. However, I do request that this copyright information and credits remain attached to the file. If you modify this module and redistribute a changed version then please attach a note listing the modifications. This module is available "as-is" and the author can not be held accountable for any problems resulting from its use.

I am always interested in knowing how my work helps others, so if you put this module to use in any of your own products or services then I would appreciate (but not require) it if you send me the website url for said product or service, so I know who you are. Also, if you make non-proprietary changes to the module because it doesn't work the way you need, and you are willing to make these freely available, then please send me a copy so that I can roll desirable changes into the main release.

Address comments, suggestions, and bug reports to perl@DarrenDuncan.net.


Thanks very much to Kevin Werbach for publishing "The Bare Bones Guide to HTML", which I found to be an invaluable resource when writing this module (and at other times as well). The latest version of the document is available at http://werbach.com/barebones/.

This quick reference lists all the HTML tags that current browsers are likely to recognize, including all the elements of the official HTML 4.0 recommendation, and some Netscape and Microsoft extensions as well. Common attributes for these tags are also included in context, giving a good idea on how they are used.

When writing this module, I used the Bare Bones reference to verify the consistant formatting used by all HTML tags, including how tag attributes are formatted. I could see the proper formatting for prologue and comment tags as well; their formats are unique compared to all the other tags. The other main uses I had for the document was in determining all the HTML tags which were not used as a pair (most use pairs, few don't), and for determining which tag attributes made a positive assertion just by their presence, without need for any associated values (most have values, few don't).

Thanks to W3C for publishing their standards documents in an easy-to-understand manner. I made good use of their XHTML primer document when making release 1-06 of this module. The most recent version is at "http://www.w3.org/TR/xhtml1". The full title is "XHTML(TM) 1.0: The Extensible HyperText Markup Language -- A Reformulation of HTML 4 in XML 1.0 -- W3C Recommendation 26 January 2000". I used this document to determine what changes I needed to make for this module's output to easily support the new XHTML standard as it supported HTML 4 and previous versions before, while keeping backwards compatability.

Thanks to Lincoln D. Stein for setting a good interface standard in the HTML-related methods of his CGI.pm module. I was heavily influenced by his interfaces when designing my own. Thanks also because I borrowed ideas for my Synopsis program from his aforementioned module.


perl(1), HTML::FormTemplate, CGI::Portable, CGI::FormMagick, CGI.

5 POD Errors

The following errors were encountered while parsing the POD:

Around line 877:

Expected text after =item, not a number

Around line 883:

Expected text after =item, not a number

Around line 889:

Expected text after =item, not a number

Around line 896:

Expected text after =item, not a number

Around line 901:

Expected text after =item, not a number