Unecessary Whitespace

[kpdecker]

I have come across an issue with the each block helper. It appears that it is creating unecessary whitespace. I copied the each block helper example (http://handlebarsjs.com/#iteration) exactly and my results were not the same. My results ended up like the following:

<ul>

  <li>ele1</li>

  <li>ele2</li>

  <li>ele3</li>

</ul>

instead of the expected:

<ul>
  <li>ele1</li>
  <li>ele2</li>
  <li>ele3</li>
</ul>

This might seem like a non issue but say we have a template like the following:

<script id="onlyEachTemplate" type="text/x-handlebars-template">
{{#each collection}}
<div>{{this}}</div>
{{/each}}
</script>

My expected output would be:

<div>ele1</div>
<div>ele2</div>
<div>ele</div>

but I instead get:

<div>ele1</div>

<div>ele2</div>

<div>ele3</div>

In an AJAX application where regular polling for data and rendering that data with a template like the previous can result in a large amount of unecessary dom growth. We actually encountered such an issue. All of the extra whitespace elements would spike the CPU usage under FF15 100% after 12 hours.
Here is a link to a set of tests I wrote to demonstrate the issue https://github.com/jayfunk/Handlebars-Whitespace-Test

[kpdecker]

This is the same number of whitespace nodes in both the examples, one just has additional newline characters.

If the whitespace is causing significant overhead or layout issues you would currently need to do something like this:

{{#each collection}}<div>{{this}}</div>{{/each}}

To get the rendering that you expected above you would need something like this:

{{#each collection}}<div>{{this}}</div>
{{/each}}

I could see some use for trimming whitespace around block elements but I'd also be concerned about this breaking existing code that is in the wild.

[jayfunk]

I did discover both of those solutions when I was writing the tests. Both work fine. However, I was hoping to find a solution at the source and one that side steps:
{{#each collection}}<div>{{this}}</div>{{/each}}

which would be some kind of template cleanup during packaging or:

{{#each collection}}<div>{{this}}</div>
{{/each}}

Which could make more complicated templates difficult to read.

[kpdecker]

#479 proposes a very interesting fix to this issue. Introducing a token on the mustache delimiter that specifies if whitespace should be trimmed in a particular block's output.

http://jinja.pocoo.org/docs/templates/#whitespace-control

[michaeljonathanblack]

Please add support for some sort of white-space control. My templates are looking a bit rusty because of this. #479 sounds reasonable to me. Some sort of white-space trimming flag for compilation might be easier and more intuitive, too.

[johtso]

This functionality would be fantastic! The fact that making your templates readable causes whitespace to be added can be a real pain. 👍

[quangv]

a

{{-#if true -}}
   b
{{-/if-}}

c

I believe that's how the Jinja2 whitespace control works... 4 possible whitespace area that can be removed... any thoughts on syntax? {{- -}} ?

[jayfunk]

My initial complaint was more that the mark up for handlebars will create unexpected spaces. The default in my mind would match the formatting as if the handlebars did not exist.
So:

<ul>
{{#if test}}
 <li></li>
{{/if test}}
</ul>

equals:
<ul>
 <li></li>
</ul>

or if we used the suggestions of all whitespace being removed:

<ul> <li></li></ul>

[quangv]

hey jayfunk, can you use a different example... all i see is bullets...

edited: thanks

[ralyodio]

so how do we handle this? I find css rules that use tbody:empty don't apply because of the whitespace issue.

[jonschlinkert]

Here is one example: https://github.com/assemble/assemble-docs/blob/gh-pages/index.html#L22-L25

However:

1. the example uses this helper: https://github.com/helpers/handlebars-helper-prettify, which depends on js-beautify,
2. Althougth js-beautify is pretty great, I had to do add some janky fixes (https://github.com/helpers/handlebars-helper-prettify/blob/master/prettify.js#L14-L24) to get the formatting to output the way I wanted it (which is part of the challenges with formatting... pleasing everyone)
3. I have learned to doing things in my HTML that don't format well, so you're seeing a really sanitized example.

Code comments in particular are the biggest PITA to get right, because they can be written in so many different ways. For example, Bootstrap does something like this:

      <!-- Component
      ================================ -->

Which never turns our right when it's "beautified". It usually ends up like this:

      <!-- Component================================ -->

or like this:

      <!-- Component
================================ -->

[kpdecker]

I think for that particular example you would not want to use whitespace control or at least not use it completely. It's all or nothing and doesn't have any knowledge of composed language semantics, which is by design.

<!-- Component {{foo ~}}

============== -->

Would serve those purposes but this would be left to the author to implement per their needs.

[kpdecker]

Released in 1.1.0

[jonschlinkert]

👍

[mcw0933]

Question - this behavior can only be specified in the template, and can't be invoked programmatically from a helper?

For example, if I have a helper that should conditionally collapse the whitespace in front of itself... I can't do that? I have to call it with {{~helper}} (to always collapse). And then instead conditionally add back any desired whitespace to the result?

[kpdecker]

@mcw0933 Within a helper I would just do a trim or regex replace to remove the whitespace in question.

[mcw0933]

Right - that I get. I'm thinking of cases where the helper could have preceding whitespace in the template. (Whitespace that isn't strictly under the control of the helper).

There's no way for the helper to force that whitespace to collapse? Right? The template implementer has to remember to either leave no whitespace, or use the {{helper}} syntax.

[kpdecker]

Gotcha. Correct it's up to the template and I don't think we want to implement something like that for two reasons.

1. The whitespace control behavior is done at compile time and adding runtime support would complicate things quite a bit.
2. Allowing a helper control anything other than it's own content feels very weird and it could lead to suprises for the users of the help who are wondering why their template isn't rendering things that to them appear to be there.

[mcw0933]

Sure - makes sense. Thanks!

[donaldpipowitch]

Hi,

this problem doesn't seem to be resolved. To come back to the original example: I want this template:

<ul>
  {{#each collection}}
  <li>test</li>
  {{/each}}
</ul>

to compile to this:

<ul>
  <li>test</li>
  <li>test</li>
  <li>test</li>
</ul>

But I get this:

<ul>

  <li>test</li>

  <li>test</li>

  <li>test</li>

</ul>

With {{~#each collection~}}{{~/each~}} I get this:

<ul>
  <li>test</li><li>test</li><li>test</li>
</ul>

[scurker]

@donaldpipowitch The whitespace control determine which side the whitespace is trimmed from.

{{~#each collection}} - trims whitespace before

{{#each collection~}} - trims whitespace after

{{#each collection}} - trims whitespace before and after

Depending on how your template is written, you need to determine where to place the white space controls in order to get your template looking how you want.

[stanmertens]

A bit late to the party but this might help some people.

I stumbled upon the same issue as @donaldpipowitch and @jayfunk seems to be having. There were empty lines after certain handlebars. The issue for me was not the whitespaces that this topic seems to be about.

In order to get rid of the empty lines, I opened the text block in the HTML editor and removed the <br> tags after the statements I don't want empty lines after. After saving, SendGrid will notify you that your text block will be changed into a code block.

Hope this helps.