font-awesome integration

[Aetherinox]

Hey,

v1.49.10 modified the way colors were handled by manually adding "rgba" to the beginning of a color string, whereas the documentation states that that rgba will be converted over to hex.

[valenzine]

I believe this issue has to do with this: #568

(I am facing your exact same scenario).

[Aetherinox]

Ah, interesting.
I just picked apart the code, and I believe it is coming from

@function next-fa-glyph() {
    $fa-glyph-counter: $fa-glyph-counter + 1 !global;

    $lo-part: $fa-glyph-counter % 256;
    $hi-part: ($fa-glyph-counter - $lo-part) / 256;
    $hex-num-str: str-slice(#{rgb($hi-part, $lo-part, 1)}, 2, 5);

    $glyph: unquote('"\\#{$hex-num-str}"');

    @debug "divider offset: #{$glyph}";

    @return $glyph;
}

Most specifically, the line $glyph: unquote('"\\#{$hex-num-str}"'); so I have to see what has changed.

I can't tell, but it looks like it's some cut off part of rgb(2

[valenzine]

I used --no-charset to avoid the issue.

[Aetherinox]

I'll have to check the docs, is that even definable if you're using it as a node package and not CLI? Looked through the webpack options and didn't see that.

Only charset I saw was if I upgraded to 1.50.x something, and that was going to be my last ditch effort.

[Aetherinox]

Yeah, I've gone through the code and double-checked every little thing, for some reason, it's taking my unicode values generated in scss, and converting them over to an rgb value.

The prints inside the scss return fine:

debug:: f099

But since I'm using "rgb" for math, once I switch over to sass 1.49.10, it returns rgb instead of what it originally did.

Before 1.49.10

icon-font.scss:36:4: Level 1: #f00101
icon-font.scss:37:4: Level 2: str-slice(#f00101, 2, 5)
icon-font.scss:36:4: Level 1: #f00201
icon-font.scss:37:4: Level 2: str-slice(#f00201, 2, 5)
icon-font.scss:36:4: Level 1: #f00301
icon-font.scss:37:4: Level 2: str-slice(#f00301, 2, 5)

After

icon-font.scss:36:4: Level 1: rgb(240, 1, 1)
icon-font.scss:37:4: Level 2: str-slice(rgb(240, 1, 1), 2, 5)
icon-font.scss:36:4: Level 1: rgb(240, 2, 1)
icon-font.scss:37:4: Level 2: str-slice(rgb(240, 2, 1), 2, 5)
icon-font.scss:36:4: Level 1: rgb(240, 3, 1)
icon-font.scss:37:4: Level 2: str-slice(rgb(240, 3, 1), 2, 5)

[nex3]

Ah, interesting. I just picked apart the code, and I believe it is coming from

@function next-fa-glyph() {
    $fa-glyph-counter: $fa-glyph-counter + 1 !global;

    $lo-part: $fa-glyph-counter % 256;
    $hi-part: ($fa-glyph-counter - $lo-part) / 256;
    $hex-num-str: str-slice(#{rgb($hi-part, $lo-part, 1)}, 2, 5);

    $glyph: unquote('"\\#{$hex-num-str}"');

    @debug "divider offset: #{$glyph}";

    @return $glyph;
}

Most specifically, the line $glyph: unquote('"\\#{$hex-num-str}"'); so I have to see what has changed.

I can't tell, but it looks like it's some cut off part of rgb(2

To be clear: this code is wildly unsafe, as it assumes that colors will always be serialized as hex codes which was never guaranteed by Sass. It's also totally unnecessary; you can write a function to directly convert a number into a hex code like this.

Closing as this is a bug coming from that next-fa-glyph() function, not an issue with Sass.

[Aetherinox]

Oh, that's definitely another way to do it. Very simple.

I'm not completely up on SASS yet (still learning) but is the integer restricted to certain values? It appears if you type '256' in, it states the List index may not be 0. Unless there's a restriction with list.nth I need to read up on.

Appreciate the help and the sample.

[nex3]

That's a bug—I've just fixed it.