Preserve line breaks

[mathewpeterson]

Line breaks are not preserved when being outputed.

What should be outputed (note the line breaks): \n ${TotalPayments}

<tr>   <td class="tblsubframecontent" align="center"><input name="date[1]" id="date_1" size="10" value="1/1/11" type="text"></td>   <td class="tblsubframecontent" align="center"><input name="amount[1]" id="amount_1" size="10" value="22.2" type="text"></td>   <td class="tblsubframecontent"></td>  </tr><tr>   <td class="tblsubframecontent" align="center"><input name="date[2]" id="date_2" size="10" value="1/1/11" type="text"></td>   <td class="tblsubframecontent" align="center"><input name="amount[2]" id="amount_2" size="10" value="22.2" type="text"></td>   <td class="tblsubframecontent"></td>  </tr><tr>   <td class="tblsubframecontent" align="center"><input name="date[3]" id="date_3" size="10" value="1/1/11" type="text"></td>   <td class="tblsubframecontent" align="center"><input name="amount[3]" id="amount_3" size="10" value="22.2" type="text"></td>   <td class="tblsubframecontent"></td>  </tr><tr>   <td class="tblsubframecontent" align="center"><input name="date[4]" id="date_4" size="10" value="1/1/11" type="text"></td>   <td class="tblsubframecontent" align="center"><input name="amount[4]" id="amount_4" size="10" value="22.2" type="text"></td>   <td class="tblsubframecontent"></td>  </tr>

[Kissaki]

There is no input type textbox. http://www.w3.org/TR/html401/sgml/dtd.html#InputType

You are probably looking for ?

[mathewpeterson]

No, it was text.. However, that isnt the point. The actual generated output by this plugin does not preserve the line breaks that are in the template. I have the examples in this but github isnt recognizing the code..

[coiscir]

Is it safe to assume you mean the markup itself is not formatted when returned?

If so, why would it need to be? Considering it's generated content, is there really any benefit to having it come out pretty? Any further interaction with the resulting markup would normally be through the UI it creates or an element inspector (such as that in Firebug or Chrome) which display the DOM in a tree structure.

Am I missing something?

BTW: Indent your code by 4 spaces on every line to have it print out properly in your comments. See the docs for GitHub Flavored Markdown -- link at the bottom-right, under the comment textarea.

[Kissaki]

In those input[type=text] it wouldn’t matter, but for <pre>-style blocks it would.

But I dunno if he was referring to that, as he didn’t seem to …

[mathewpeterson]

@coiscir: Yes, you are correct. I believe this plugin should preserve the line breaks that are in the template. I don't want to be dependent on some third party plugin to auto-format my source code. It's much faster for me to ctrl+a ctrl+u to view my source.

@Kissaki: Again, it's not the value of the input I am talking about, merely the line breaks between the tags.

[kof]

@coiscir I have 4 points about it:

• as @kissaki already said about pre tags
• template engine shouldn't modify markup in places user doesn't expect it. I think the correct behaviour is also not to prettify the output, but to leave it as it is.
• practical example would be: if I want to debug the generated markup, I want to see its string representation, not a rendered by browser dom view, because its not the same. So if you cut the new lines etc. its all 1 line then and is difficult to read.
• another use case: I maintain nodejs port of jquery-tmpl, https://github.com/kof/node-jqtpl, html is rendered serverside and the output is always 1 line, which is difficult to inspect without to render it by browser and then use firebug.

[Kissaki]

Indeed, a template function should only do that, templating, and not more logic like minimizing. It should only do so if a parameter or the function(name) indicates it is also minifying.

[defunctzombie]

imho this is a very serious issue that doesn't seem to be getting any attention? Is there some reason that a simple fix isn't available? Seems like it wouldn't be too bad (but I don't know).

[ghost]

I want this as well, but for different reasons. I'm appending my output to a textarea and was expecting my linebreaks in my template to go over to my textarea. As it is right now it's all on a single line. Only way to work around this in the current state is to have separate templates for each section with manual line breaks inserted at the end. Be a lot nicer if white space was preserved.

[mathewpeterson]

I do believe the issue is here: https://github.com/jquery/jquery-tmpl/blob/master/jquery.tmpl.js#L326

Not able to test at the moment, let me know if anyone can confirm this.

[BorisMoore]

Yes, you are right. That line was there from the beginning - in John Resig's original prototype. It reflects the philosophy that the goal it to guarantee HTML visual layout, but not to preserve 'pretty printing' or similar of HTML.

We can consider changing that philosophy. I agree that there are scenarios where it is valuable to maintain that fidelity. I am happy to keep this issue, open, (so will open it again now), particularly as I am planning to make rendering to an HTML string a lot easier to achieve in the Beta2 version. (We hope to release a Beta2 in April.)

[Kissaki]

Allowing for pruning via a parameter(/option) would be a viable solution.

[alandecastros]

what happenned to this issue? is it solved?

[clarabstract]

@BorisMoore - how can the content of <pre> or <textarea> tags not considered as part of the HTML visual layout?

Why does the plugin bother stripping out the original linebreaks anyway? What purpose does that serve exactly?

[BorisMoore]

Several reasons, such as that in the conversion to code, for creating a compiled function, line breaks can lead to JS errors, missing string delimiters, etc. Supporting them would have added additional code for compilation.

In the ongoing work at JsRender and JsViews I am currently working on a different compilation approach which may allow me to provide a mode that preserves white space.... (See https://github.com/jquery/jquery-tmpl/issues/96 for context re: roadmap).

[clarabstract]

Oh right I forgot JS doesn't really roll with multiline strings. Having said that, why not a trivial fix like so:

diff --git a/data/js/jquery/other/jquery.tmpl.js b/data/js/jquery/other/jquery.tmpl.js
index 213d136..cc5ee0c 100644
--- a/data/js/jquery/other/jquery.tmpl.js
+++ b/data/js/jquery/other/jquery.tmpl.js
@@ -323,7 +330,9 @@
            // Convert the template into pure JavaScript
            jQuery.trim(markup)
                .replace( /([\\'])/g, "\\$1" )
-               .replace( /[\r\t\n]/g, " " )
+               .replace( /\n/g, "\\n")
+               .replace( /\r/g, "\\r")
+               .replace( /\t/g, "\\t")
                .replace( /\$\{([^\}]*)\}/g, "{{= $1}}" )
                .replace( /\{\{(\/?)(\w+|.)(?:\(((?:[^\}]|\}(?!\}))*?)?\))?(?:\s+(.*?)?)?(\(((?:[^\}]|\}(?!\}))*?)\))?\s*\}\}/g,
                function( all, slash, type, fnargs, target, parens, args ) {

[rdworth]

Thanks for taking the time to submit this issue. Just wanted to let you know this plugin is no longer being actively developed or maintained by the jQuery team. See README for more info.

[catamphetamine]

You should fix this issue