Update grunt-sass version & update grunt task sass options

[hnla]

Current Grunt-sass is behind in version release patch updates to latest version in package.json.

Compiled .css files are using spaces - add indentType: 'tab' to options block in gruntfile.js

Formatting of .css files was incorrect according to accepted conventions with output style outputting as nested despite 'expanded' set, updating version appeared to correct this and compile a fully expanded .css file

I need to re-run the compile tasks to produce better formatted .css file before we release.

[mercime]

Good find @hnla. Attached patch adjusts the two tab indents to one tab indent. Attaching also the before and two "after" pictures.

[mercime]

Added indentWidth: '1'

[mercime]

Spaces instead of tab

[mercime]

double tabs

[mercime]

One tab

[DJPaul]

I'm inclined to suggest this should wait until 2.4 because we're obviously in RC and this changeset involves a change in our tooling (pretty big version bump). A tabs-instead-of-spaces thing is really minor in the grand scheme of things ("does this CSS work?" - yes, it already does).

[hnla]

@DJpaul Yes less inclined to care too much over Tabs Vs. Spaces however the version update was more to do with the seeming issue with grunt-sass (libsass) not correctly parsing the format options, outputting nested style formatting when the main styles should be 'expanded' ( we are also being mindful here of WP's expected coding standards!)

However it is also possible that in this respect (formatting) it only matters that we have the version update and options updated locally we can then re-build the .css file and re-commit just those with now correct formatting and that oughtn't to upset anything, mercime has already re-generated these files and submitted as patches so a straightforward matter?

After things settle we can update gruntfile/package.json in core.

[DJPaul]

No, committing locally modded/generated files and not updating the configuration in the main project is not a good approach.

If #6462 proves to be a regression, and if the release is delayed a week(?) because of it, then we could probably add this in.

[hnla]

No, committing locally modded/generated files and not updating the configuration in the main project is not a good approach.

hmm ok get what you mean, although I could re-generate the css files based on my updated grunt-sass version anyone else i.e yourself needing to do so would possibly just revert the css file back to original format?

This is a bit of an annoying position though, I have need of fixing an issue in 2015 stylesheets which would have afforded prime opportunity to re-generate files to correct format, however I haven't updated my commit ccheckout thus far but would love to :(

[mercime]

My two cents is that grunt-sass 0.18.0 was added in this 2.3.0 dev cycle specifically to facilitate the processing of the scss files for the companion stylesheets. But using grunt-sass 0.18.0 generates results that are not up to par with WordPress CSS Coding Standards. So I vote upgrade to grunt-sass 1.0.0 in this same dev cycle :)

I have compared the generated stylesheets for both themes using grunt-sass 0.18.0 and grunt-sass 1.0.0 and the only changes are spaces rendering correctly to tabs.

[johnjamesjacoby]

In 9902:

Grunt: Update grunt-sass to 1.0.0.

• Add indentType property set to tab
• Add indentWidth property set to 1

Brings SASS output back inline with our spec and expectations.

Props hnla, mercime. See #6461.

[johnjamesjacoby]

In 9903:

Theme Compat: Update Twenty Fifteen and Twenty Fourteen styling.

Includes whitespace fixes from updated grunt-sass parameters.

Props mercime, hnla. Fixes #6461.