Ember JS 1.8.1 + Chrome - extra spaces

I have a problem in the application I'm working on , since I upgraded EmberJS from 1.6.1 to 1.8.1 . This only happens in Chrome . The problem is that somehow my templates are being processed with a lot of extra spaces surrounding each html node. So to speak ... instead of:

<div> [tab]<span>Hello</span> </div> 

I get something like this:

 <div>[ ][ ][ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ]<span>Hello</span>[ ][ ][ ][ ] </div>[ ][ ][ ][ ] 

Or maybe you will see it here: An example

This clearly breaks the style. The funny thing is that when I remove at least one space from such a strange design, then the style for this section magically returns (although other spaces still exist).

Just to mention. I am using ember-grunt-templates 0.4.21 to compile . I know that there are new versions (0.4.23, I think ...), and I also tried to update it, but this does not help.

I know that the following was mentioned here: http://emberjs.com/blog/2014/11/04/ember-1-8-1-released.html error in Chrome, but it says that people get the opposite effect missing places due to some bug in Chrome .; > Is my Chrome instance consuming and collecting all other people's spaces or what ?:-)

Has anyone encountered a similar problem (like mine, not the same as the one mentioned in the Ember release notes)? Does anyone know how to get rid of this?

Update 1:

I tried to update:

  • Ember 1.9
  • Handlebars 2.0
  • Grunt-Ember 0.5 alpha Templates

This fixes a few errors in the gap, but some of them are still present. That is, which leads to a space before the displayed text:

 <span class="someClass"> {{#if condition}}{{someProperty}}{{else}}{{t 'translationKey'}}{{/if}} </span> 

And this is not so:

 <span class="someClass">{{#if condition}}{{someProperty}}{{else}}{{t 'translationKey'}}{{/if}}</span> 

: - |

+7
google-chrome grunt-ember-templates
source share
1 answer

It turns out this is a string encoding error. I reported this here: https://github.com/emberjs/ember.js/issues/9945

The solution is to make sure the end-of-line encoding must be Unix-like.

+1
source share

All Articles