If I have something like this for readability in the template: ============================== <TMPL_IF NAME="ERRMSG">
<p>Error: <TMPL_VAR NAME=ERRMSG> <TMPL_IF NAME="EMAIL_AVAILABLE"> (Forgot your password? <a href="">Reset and email it to yourself</a>.) </TMPL_IF> </p> </TMPL_IF> ================================ The resulting HTML has a lot of newlines. I'd like to ask if there should'nt be a feature in H::T that would let the template author selectively disable "rendering" linefeeds as meaningful (intended) whitespace? What I am suggesting is an attribute for TMPL_IF (and other operations?) named "NOLF" that would cause H::T to discard linefeeds? My reasoning is: in HTML authoring there are ways to increase legibility of the HTML without affecting the output of a parser. Or, more often, there are ways to instruct the parser to treat what would otherwise be considered whitespace for legibility of the HTML as whitespace intended for output by the parser. H::T is just another layer from authoring to rendering. Shouldn't it carry the same capability to provide for legibility without affecting output? It seems like there should be a way to express "TMPL_COMMENT" and "TMPL_PRE". Or, if explicitly marking up whitespace that should be passed to output is a bad idea, why not an attribute on some TMPL structures to indicate they should *not* be treated as preformated text? Sam, I noticed (in the archive) this was discussed before. At that time, it seemed like it was just a question of whether the unwanted whitespace added too much to the data being transferred. I agree that it's only a few bytes. For a long table inside a loop, with a lot of ifs, and a lot of columns, the bytes add up. But, more importantly, it seems like something is missing in H::T when I get something out of it vastly different than I expected and I have *no* way to prevent it. I could collapse my H::T statements. But, the resulting illegibility of the template would (in my mind) only further demonstrate that something is missing. Thanks! Mark ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Html-template-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/html-template-users