Hi matija, You mention some good points, here is some more details to clarify. Detail Orange is new stuff, the rest is just background...
*detailOrange* RE: how about accepting *both* (aka either a sub ref or a string); This is a good idea. I expirimented with this prior to posting, yet the expirments revealed some caveats.
CAVEAT1: You have to declare your prototype with the 'typeglob' syntax (aka star, asterisk) 
    table(*){
        my  $vInput = shift;
        if(ref $vInput eq 'CODE')       {$vInput->(); }
        ### fill in the rest...
    }

[download]
CAVEAT2: You have to use the 'sub' keyword to indicate a code block. Some may feel this reduces readability and 'coolness factor' (entirely subjective). Failure to do so causes the curly brackets to be interpreted as a hashref. 
    table sub {
        for (0 .. 3){
            ### fill in the rest...
        }
    }

[download]

*detailX* RE: script 'execution'; this snippet is really meant to be a brief 'sketch'. Everything you see in the ### INIT section is just one (of many) possible way to support the concise syntax proposed by Juerd. The ### DISPLAY OUTPUT section is the main emphasis (proof of concept), to show that Juerd need not totally sacrifice 'reusability' 'parameterization' and 'nesting', as he first might have thought. (see original thread).
*detailFoo* RE: why to accept sub ref instead of a string; the main 'coolness factor' of Juerd's original idea was the fact that you could use concise curly-brace syntax to specify a table, and put things like 'for loops' inside of it. Q:Why would someone want to do that? A:Personal preference and readability (again, see original thread).
*detailQ* indeed, if this were a 'real world' implementation, my personal preference would be to: 0) make the code its own standalone package; 1) dispense with the $out variable altogether, and instead make output buffering an OOP-style method of the package; 2) use name-value-pair oriented parameters (aka hash, hashref, objects) instead of numerically-indexed oriented parameters (aka array) *although sometimes array is good too*; 3) support attributes on all output elements; 4) avoid obvious type mismatches like the one you correctly indicated in the assignment to $st *which I dont like as a variable name btw, like i said, this was a sketch* 5) avoid unduly restricting the caller of the types of parameters it can pass (aka allow string as well as subroutine ref) *this is just a general design principle that I like to follow in most cases, (the law of mutual satisfaction)*

In reply to Re: Re: Readable HTML tables (revisited) by dimar
in thread Readable HTML tables (revisited) by dimar

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.