gulp-sass inserts byte order mark EF BB BF in output

I’ve been getting this odd issue where Chrome ignores some of my @font-face declaration.

After checking the output, I’ve noticed an odd character preceding the declaration, which a hex editor revealed to be EFBBBF (byte order mark).

It is only apparent because i’m piping the output with gulp-header.

My build task is like this:

gulp.task('sass-style', function () {
  return gulp
    .src('scss/build.scss')
    .pipe(sass({outputStyle: 'compressed'}).on('error', function(err) {notify().write(err); this.emit('end');}))
    .pipe(rename('style.css'))
    .pipe(header('/*! <%= name %> - <%= version %> - <%= author %>  <%= (new Date()).getFullYear() %> */',pkg ))
    .pipe(gulp.dest('build/'))
    .pipe(browserSync.stream())
  ;
});

The BOM gets placed right after the header, but it isn’t inserted by gulp-header itself, which just concatenates the header with the piped output.

I’ve tried to remove some of the stream handler to make sure they’re not the culprit.

gulp.task('sass-style', function () {
  return gulp
    .src('scss/build.scss')
    .pipe(sass({outputStyle: 'compressed'}).on('error', function(err) {notify().write(err); this.emit('end');}))
    .pipe(gulp.dest('build/'))
    .pipe(browserSync.stream())
  ;
});

And checked the out with Text Wrangler (osx) and it confirms that a BOM is added.

Unless i’m missing something in my build script, there seems to be an BOM incorrectly inserted in the output.

(There was a vague mentioned of the BOM in this other issue https://github.com/dlmanning/gulp-sass/issues/82 which said it was marked as fixed in the 2.x branch, but I’m on the latest – 2.0.4 – and it’s happening)

I’ve got the following gulp packages in my build setup:

    "gulp": "^3.9.0",
    "gulp-concat": "^2.6.0",
    "gulp-footer": "^1.0.5",
    "gulp-header": "^1.2.2",
    "gulp-notify": "^2.2.0",
    "gulp-rename": "^1.2.2",
    "gulp-sass": "^2.0.4",
    "gulp-uglify": "^1.2.0",
    "gulp-util": "^3.0.6",
    "gulp-webpack": "^1.5.0",

Happy to test further if you have any suggestions.

[shockthetoast]

Interestingly in compressed mode the @charset isn’t being generated which could be why Chrome is unhappy.

@doginthehat, it turns out that in compressed mode, sass uses the BOM instead of @charset rule because… it’s shorter. https://github.com/sass/sass/issues/1449

The Unicode Guidelines state that using the BOM is allowed in utf-8, but not recommended. (Source: this Stack Overflow answer which links to the official docs.)

The concatenation issue is one reason it’s a terrible idea. I love saving space as much as the next guy, but I don’t feel the savings sixteen characters is worth it. (From the 17 characters of @charset "UTF-8"; to the one BOM character.)

Of course, this being done by sass itself, and not gulp-sass, so it can’t be fixed here. But hopefully this information is helpful to someone.

[kapooostin]

@shockthetoast Thanks a lot!