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

Reply via email to