Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ractive strips whitespace in HTML too aggressively #3330

Open
LeJared opened this issue Apr 8, 2020 · 3 comments
Open

Ractive strips whitespace in HTML too aggressively #3330

LeJared opened this issue Apr 8, 2020 · 3 comments

Comments

@LeJared
Copy link

LeJared commented Apr 8, 2020

Description:

Necessary whitespace between HTML elements gets stripped in loops such as:

<div>
    {{#each words}}
    <span>{{.}}</span>
    {{/each}}
</div> 

In this example all the elements get are placed right next to each other without any space between them, which makes them a single long line that won't break anywhere.

Versions affected:

1.3.11

Reproduction:

https://jsfiddle.net/lejared/yn8om1c9/14/

@evs-chris
Copy link
Contributor

This one is a little tricky, and I vaguely remember that it's been discussed a time or two before. On one hand, you have situations like this where some whitespace is desired, and on the other, you have situations where allowing the whitespace causes unwanted wrapping unless you format your blocks all on one line.

I believe there is precedent in other templating languages to have a sigil in the opening block tag to specify how it handles whitespace e.g. {{#each things -}} says don't eat whitespace in the body of this particular each. I'm not sure if there's a better way to handle that or if I have the cases reversed, but I'm pretty sure flipping the behavior without making it configurable will be breaking in weird and subtle ways.

Any thoughts on how to reconcile this?

@LeJared
Copy link
Author

LeJared commented Apr 9, 2020

Well, I see the point, that a change here might break exiting apps. But the way it's handled right now is just not right and I can not remember any template system (server or front end side) that just removes all spaces between html tags. If I, as a app author, don't want any spaces between tags than I just must not enter them in my template.

As from the discussion in #3165 on this example: <div>{{#if foo}}...{{/if}} <span>should the space there be removed?</span></div> this means, that if I want the space after that if-block to be conditional than I will have to put it in that condition like <div>{{#if foo}}... {{/if}}<span>should the space there be removed?</span></div>.
That's what I'm actually doing and that's how it is handled by any other template system I've used so far (not that many BTW). So It's up on the author if there is a space or not.

But regarding to the examples in the issue above I could not figure out a way to force the spaces to be there. So in the current state the author does not have a choice.

Any Ideas for e workaround until any decision was made on how to handle this issue?

Update: Just found a workaround by putting a space and an empty mustache or template comment to where I want to have the space.
https://jsfiddle.net/lejared/yn8om1c9/19/

@evs-chris
Copy link
Contributor

In this case, it's only the space inside block tags that gets stripped. So {{#each foo}} {{bar}} {{/each}} gets turned into {{#each foo}}{{bar}}{{/each}}, but <div> {{foo}} </div> just has the internal space collapsed to a single space - so left alone in this case.

As far as workaround, that will work, but there really should be a better way. I've used &nbsp; before, but I needed the line not to wrap. I was thinking &#32; would work, but apparently it gets eaten too.

I see three long term solutions:

  1. Caveat it in the docs and say that if you want to force a space, here are the ways you can do it.
  2. Break the existing behavior and collapse inner block space as is done with elements.
  3. Add a block sigil that says 'leave my internal space alone'.

So far, I'm leaning toward 3, but I'm definitely open to suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants