If you think that was confusing, see below...

Sticking to the op, a lot of Pod I read is interwoven with the code within which it documents. Have you tried placing the function descriptions pods above each of the relevant functions? This may help you to keep clarity with which art of the pod is document which part of the module

I thought you may have been told not to include default exports. Which is fine. However in terms of the pod, your synopsis is an example in how to import routines, rather than how to use your module. So you need to show an example of how to use the module, something like the $tab example you did earlier in this thread. The import example is also the only place where all of the user functions are listed. I think these things need to be listed in a place which says, these are the modules routines. Not as at present, being a side effect of the synopsis.

Heading away from the op and back to tabs...

Looking at the $tabs implementation. There are a couple of issues I see with this.

• Indirectly conflicts with accessibility elements such as tabindex
• Currently user implemented due to module author being unable to determine and implement user requirement.

In the case of accessibilty, I would propose you choose a different name for this variable.

Further to the above, consideration of accessibilty attributes and elements to be included with the first release would be advantageous. The element <noscript> I notice does not appear. Also along with [qw(id class style)] consider including [qw(role)] as a default attribute.

Tab implementation. You say you do not know what level the user requires, however, if you did know how would you approach that. To keep this as short as I can, I will just say what I think, rather than explain my thinking.

keeping use base Exporter allows you to customise the import routine. By overriding and extending the routine, you can keep all the functionality of import, and provide a layout indentation pragma to determine the user requirement.

The problem now becomes one of detecting where the indentations are required. Starting with say, wherever a sub{} argument is provided a child element is produced and therefore an indentation would be required, you could effectively determine when the indentation should be increased. Returning from the sub{} argument would indicate a return to the parent element and therefore a reduction in the indentation variable. There is what I think the strategy for indentation implementation in your module should be thinking about.

An alternative may be to apply the indentation after the HTML has been produced, if the indentation pragma has been set. Like using CGI::Pretty, or Perl::Tidy, but as a setting rather than a module. By storing the html then running it throuhgh an indent parser after.

Customising the import routine to overide and extend would go something like this:

Disclaimer: untested code, probably broken, purely figurative. In a rush gotta go..

use HTML::LadyAleenaStyle qw(:all -in1);
# end -in with single digit for 'level'.
[download]

Package HTML::LadyAleenaStyle;
use strict;
use warnings;
#use Carp;
use deparse; #see corrupt code further down
use base Exporter;
use Base::Nifty qw(line sline);

our @EXPORT = qw(html body script noscript etc);
our @EXPORT_OK = qw(table form nonessential etc);

my $inflag; # indentation flag for checking.
my $in; # indentation depth variable.
# Expect indentation flag may need to be a constant for checking. 
# Need to review how to set the constant correctly. 

sub import{
# strip out the indentation pragma from the argument list;
 $inflag = ($1) = grep s/^-in(\d){1}$//, @_;     # untested
 $in = 0 if $inflag; # start indentation depth at 0 if flag set >= 1;
 
# pass arg list to Exporter for usual behaviour;
SUPER::import(@_);

}

# now if flag set, determine if child element and alter depth.
# this code is a suggestive starting point. 
# the depth decrement requirements would also need to be determined.
# this sub code is gibberish.
 
sub element{

  if($inflag){ 
    if(my $indent = map ref(CODE), @_){
        $in++ if( grep deparse(&{CODE}) =~ /CHILD ELEMENT SUB/ );   
    }
  }

# rest of sub
...

#return
line($in, $open,); 

}
[download]

hope these comments are helpful. I tried to stick to commenting on pod aspects, but somehow diverged into the implementation. I think you wanted a little input on both though.