Support RRGGBBAA / RGBA hex colors

[lepe]

Edited by @nex3

Specs: sass/sass-spec#1262

Tracking issues:

• Support hex colors with alpha channels dart-sass#371
• Support hex colors with alpha channels libsass#2674
• Parse hex colors with alpha channels ruby-sass#67

---

SASS version: 3.4.22
Example:

body {
    background: linear-gradient(45deg, #02010110 5%, #02010180 77%, #08030310);
}

Error display:

Error: Invalid CSS after "...radient(45deg, ": expected function argument, was "#02010110 5%, #..."
on line 2 of test.scss

Same error is shown if 4 digits are used (e.g. #0008) or if its used inside radient-gradient().

[nex3]

According to Fyrd/caniuse#2249, it looks like this has already landed in some browsers, so we should support it ASAP.

[lepe]

Thanks nex3!

[nex3]

Hmm, this is technically a breaking change. CSS defines an ID as a valid declaration value in the basic user interface module, so Sass already parses tokens like #abcd as strings. To be thorough here, we'd need to do a deprecation cycle. Because this is a CSS compatibility issue we don't need to wait until 4.0 to fix it, but we should at least wait until 3.6 so we can have deprecation warnings for some amount of time.

I'm leaving this tagged as 3.5 because we should get the deprecation warning in place before we release.

[nex3]

We also won't support colors like #0123 in 3.5, despite the fact that they aren't ambiguous with IDs. I don't want to create confusion where some hex alpha colors are supported and some aren't.

[jhpratt]

@nex3 Any updates?

[nex3]

This has landed and been released in 3.5.

[jhpratt]

@nex3 I've updated to 3.5.1, and I'm still receiving the warning that it's parsed as a string, not a color. It's not just that the warning hasn't been removed, it's being copied verbatim into the compiled code (i.e. not turned to rgba)

[nex3]

Oh, sorry, you're right. This is waiting on 3.6, because we need to have a release's worth of deprecation for the existing string parsing.

[jhpratt]

@nex3 Just an FYI it landed in Chrome 61 today.

[jniac]

Any news for that feature ? 3.6 landing ?
It's really much more convenient to append AA to any existing hexadecimal color to apply any opacity than converting #RRVVBB to rgba(). I'm using it in dev tools, and when i'm back in sass file, i can't simply paste my value. Sass (for once) complicates the development.
(Btw great job, since Sass is a great tool, we have great expectations!)

[HamptonMakes]

Sounds like we've done a solid deprecation cycle now... time to get this into master!

[verdy-p]

For me, parsing "#xxxx" as a string identifier is valid, but RGB(A) colors specified using these strings should be valid: strings are already parsed to know if they match a color name or some known patterns of #ID to see if they can ba unambiguously converted to a color type: this is a case similar to a conversion constructor. Basically CSS does not need to have a specific and distinctive token type for colors, it just has to recognize known "name" or "#ID" or "functionname( parameters )" to see what they designate. It's not to do at token level (i.e. lexer). Color specifiers will continue to have some new forms in the color module, but the basic syntax is still stable, and each identifier is then queried to see if they can match some type constructor and then have some distinctive relevant properties that allow combining them or not.
Simplify things: remove the token type distrinction from #ID and #RGB(A) specifiers: just tokenize them the same, then use a dictionary lookup or constructor lookup to see if they match sometinh meaningful with known semantics.: this must be done at parser level, not a token-level, possibly by using parser-fallbacks to resolve "shift-reduce conflicts" in the LR automata of the parser if needed, when you have seveal parsing possible from the same suite of lexer tokens).
I know this causes difficulties notably in CSS shorthand properties like "border:" or "font:" where there may be multiple values specified in random order, but only one for segregated subtypes (e.g. "dotted" is not a color type, but a border-style type, you have to try parsing "dotted" as a color, see that it fails, then retry with a border-type, where it will succeed; when you'll see the "black" token and you try parsing it as a border-type, it will fail, but you'll retry with a color type: when parsing the "border:" property, you can try constructing all subtypes from the specified value and must see that only one will match (otherwise you'll have an assertion failure, meaning your parser syntax is incorrect or ambiguous), then you'll check that only one border-style type was specified (to override the initial unspecified value for the border-type) if the borde-style was parsed succcessfully (if not, you can then report a syntax error). So the final syntax of the "border:" property value is just a space-separated list of items whose exact type is unknown and unspecified but will be set by using a custom local parserrule that will check their semantic and additional requirements)