Preserve author's format

[GrimLink]

I am amazed that sass (in any form, ruby, lib and dart) all have similar issues around some formatting options.

While I don't mind all forms like the one from #30 by removing the quotes from attributes (Only in Dart).
One issue that is bugging me to this day is that sass will simply add a leading-zero to my css code and there is no way to tell sass to not do this.

Sass should not decide how we write our css.
Other tools should.

Please keep the author's format when not using compressed.
Like with colors #363
At Least stop adding leading-zeros!

P.S. yes there have been previous tickets for the leading-zero issue which all have been marked as a duplicate to each other and end up to the Ruby-sass version that is closed because Ruby Sass is deprecated

This is not just related to Ruby-sass.
I am using both Dart- and Lib-sass in my project.
And both also do this.

[nex3]

Why do you want this? Whether or not a leading zero is present doesn't affect the meaning of the generated CSS. Is this just an aesthetic concern? Because Sass's output formatting is not intended to be deeply customizable; it's intended to be readable and consistent.

We preserve the output format of colors because there were spec-violating inconsistencies in handling different forms of colors across browsers, but tracking the original format of each color object is quite expensive. Numbers are used even more often than colors, which means the performance hit would be even more substantial. There would have to be an extremely compelling reason to track their format.

[GrimLink]

@nex3

Why do you want this?

Smaller CSS, every byte counts.

Whether or not a leading zero is present doesn't affect the meaning of the generated CSS.

True it does not change the meaning the css code.

Is this just an aesthetic concern? Because Sass's output formatting is not intended to be deeply customizable; it's intended to be readable and consistent.

While I agree that all our CSS should be readable and consistent.
As mentioned I want my units to stay as I authored it.
It makes the file size smaller.
And many if not almost all styleguides say you should avoid using leading zeros.

With the change in Dart where sass now also removes quotes on attributes.
I am getting the feeling that Sass is changing allot of the formatting to a standard, what not all dev's want.
On what specific reason are these formatting rules based on, that Sass does this?

[nex3]

If you're looking for small CSS, use compressed mode, where Sass will always generate the smallest CSS it can. Otherwise, Sass will generate valid CSS that's readable and consistent. It doesn't make sense to add more choices than that.

[GrimLink]

Okay makes sense, if compressed mode did not add the leading zero.
Which it sadly does, no matter the mode I use.

[GrimLink]

@nex3 Sorry again, but your last comment is incorrect,
Why is this topic ignored?
And always closed so quickly?

Compresses mode also adds the leading zero.

If you're looking for small CSS, use compressed mode, where Sass will always generate the smallest CSS it can.

How is this the smallest CSS.

[nex3]

Compresses mode also adds the leading zero.

I can't reproduce this:

$ sass --version
1.12.0-dev
$ echo 'a {b: 0.1}' | sass - --style compressed
a{b:.1}

[GrimLink]

Okay to make sure on my side I ran just sass, no other npm packages.
Both versions on latest build.

❯ npm list -dept=0
..
node-sass@4.9.2
sass@1.10.0
..

The compressed mode did indeed leave number values allone.
For this part, I stand corrected →

But did not for rgba colors.
Maybe because also being an sass function?

Also wierd difference between dart and node sass for numbers passed via interpolation.
On dart the leading zero is added!?
On node it is not.

I need to use interpolation for sass variables that are passed as value for css variables.
If I don't use interpolation, the sass variable is output as is.

/* output without interpolation */
:root{--item-spacer: $item-spacer;}

[nex3]

But did not for rgba colors.
Maybe because also being an sass function?

This also works for me:

$ echo 'a {b: rgba(1, 2, 3, 0.1)}' | sass - --style compressed
a{b:rgba(1,2,3,.1)}

Also wierd difference between dart and node sass for numbers passed via interpolation.
On dart the leading zero is added!?
On node it is not.

In Dart Sass, the conversion of a value to a string that occurs during interpolation has no knowledge of the output style that will eventually be generated for it. This makes it much more efficient and modular, but it does mean that sometimes you may end up with leading zeros.

[Pavan1889]

Running $(npm bin)/node-sass ..... --output-style compressed
Yes I agree this is not problem for values like color etc.. BUT it is problem for generating classes as shown in below example:

$i: 0.1;
@while $i < 1 {
	.opacity-#{str-replace(#{$i}, '.', '_')} {
		opacity: #{$i};
	}
	$i: $i + 0.1;
}

Output:

.opacity-_1 {  // problem here, it should be .opacity-0_1
	opacity: .1; // not problem here
} .opacity-_2 { 
	opacity: .2;
} .............. so on

If anyone is able to find solution/workaround, please let me know.

[Pavan1889]

Fixed it by writing a function, I believe there is config available in node-sass itself, for now I don't know it yet!

@function get-name($decimal) {
    @if $decimal < 1 {
        @return str-replace(0#{$decimal}, '.', '_');
    }
    @return str-replace(#{$decimal}, '.', '_');
}

NOTE: This will break if not using --output-style compressed

[nex3]

The only guarantee Sass makes about the format of non-integer numbers—including when they're converted to strings using #{}—is that they'll have the correct value when parsed as a CSS number.

[Pavan1889]

@nex3, thank you for explaining the way it is implemented, it would be helpful if there is an config option available to add the leading zero based on developer interest, because even with such scss functions in above we *cannot detect if css is generated normally or in compressed mode.

*If possible, let us know

[nex3]

We generally don't add configuration options for language behavior. Doing so would mean that stylesheets couldn't be used across different projects with different configurations, which damages our goal of providing a platform for stylesheet libraries.

Generally, you shouldn't write your styles in a way that assumes anything about how non-integer numbers will be formatted beyond what Sass guarantees. If you want a consistent format, first convert them to integers.