Support for the CSS Color Module Level 4 (Editor's Draft)

[jeddy3]

It's very exciting to watch so many of the 1.0 roadmap items get ticked-off!

I was wondering if support for the CSS Color Module Level 4 (Editor's Draft) was under consideration, in particular, the color() function (playground here)?

Currently the following CSS:

a { 
  color: color(#eef6f8 alpha(50%));
  border-bottom: 2px solid color(#eef6f8 alpha(30%));
}

Produces the following warnings:

2:2  ✖  Invalid value for `color`   csstree/validator
3:2  ✖  The rest part of value can't to be matched on `border-bottom` syntax   csstree/validator

@lahmatiy's response:

In short, it's a bit complicated and therefore postponed for a while (it's good to have an issue still). CSSTree supports things are supported by browsers first. As I know level 4 is not supported by any browser yet (correct me if I'm wrong). It may be an extension for default syntax still.
I read this module a while ago. While color() looks simple, I found a problem with color-mod syntax. In current form, it's unusual and requires improvements in lexer syntax matcher. Now it is not known exactly that the syntax will be the same in the future (it's a draft). So it's unclear should we do these improvements or not. Supporting for a part of the module looks odd. One more solution to rewrite a color-mod syntax in a regular way and then suggest those changes to the module. But this requires an unknown amount of time. That's why I decided to focus on more obvious things.

---

Migrated from csstree/stylelint-validator#8.

[jeddy3]

it's a bit complicated and therefore postponed for a while

I figured as much!

(it's good to have an issue still).

Agreed.

CSSTree supports things are supported by browsers first.

A sensible approach :)

As I know level 4 is not supported by any browser yet (correct me if I'm wrong).

I think the 4 and 8 digit hex values bit of the level 4 spec has some upcoming browser support. I haven't seen any mention of the other bits like color-mod, gray etc though.

it's unusual and requires improvements in lexer syntax matcher

I'm pretty ignorant of the inner workings of the parser, so forgive me if this isn't feasible, but would it be possible to skip over the contents of the color function? Or does the lexer require that contents of the color function be parsed in their entirety? I guess so as the lexer needs to identify the terminating ) of the function, right?

What I'm asking is, would it be feasible to introduce an ignore option, like you did in csstree/stylelint-validator#5 (comment) for properties, which would allow color functions to be skipped over by the validator?

That's why I decided to focus on more obvious things.

That makes complete sense.

From a stylelint user's perspective, not having support for these Editor Draft specs isn't necessarily a blocker to using stylelint-csstree-validator as it is quite feasible for the user to process their source files before passing them into stylelint... in this instance using postcss-color-function to resolve the color() functions before running the sources through stylelint-csstree-validator.

stylelint-csstree-validator is shaping up to be a powerful tool and I think a user having to preprocess a bit of their Editor Draft CSS is a small price to pay to use it :)

[lahmatiy]

I think the 4 and 8 digit hex values bit of the level 4 spec has some upcoming browser support.

Yep, it's supported by last browsers with the exception of Edge. Therefore it's supported by csstree lexer. Also commaless rbg() and rgba() are supported. Other parts of the module are quite complex and don't support yet.

I'm pretty ignorant of the inner workings of the parser, so forgive me if this isn't feasible, but would it be possible to skip over the contents of the color function? Or does the lexer require that contents of the color function be parsed in their entirety? I guess so as the lexer needs to identify the terminating ) of the function, right?

Lexer uses syntaxes described with a grammar defined by CSS Values and Units Module Level 3. You can see how <color> is defined now here. To support color() and others we need extend that syntax.
The problem is that color-mod syntax contains parts like that

[hue( | h(] ['+' | '-' | '*']? <angle> )

The hard place here is that functions start is grouped and the closing parenthesis belongs to any of function. Since lexer builds an AST for syntaxes and represents a function as a single node, it should be changed to handle this case. But I don't how, should it generates two function nodes with the same content or a single node with a list of names. Both solutions look abnormal.
It's a first time I see that kind of syntax description. Functional notation nothing say about it. So I still don't know it's correct or not. In my opinion, the color-mod syntax should be rewritten.

What I'm asking is, would it be feasible to introduce an ignore option, like you did in csstree/stylelint-validator#5 (comment) for properties, which would allow color functions to be skipped over by the validator?

Yes, we can add some ignorance or so. As an option is to define color() as a generic type, which never returns an error. But I think that's a bad solution.
Currently ignore option is the temporary solution until we've done with syntax extensibility.

stylelint-csstree-validator is shaping up to be a powerful tool and I think having to preprocess a bit of Editor Draft CSS is a small price to pay to use it :)

Well, I want to quote stylelint docs: since there are infinite processing possibilities, the linter cannot support everything. It should be clear that CSSTree or any other tool can't validate every syntax extension. I believe any extension should be moderated. Therefore I've implemented the extensibility feature to CSSTree. With that feature, anybody can extend syntax as needed, e.g.

var csstree = require('css-tree');
var mySyntax = csstree
    .fork(CssColorLevel4)
    .fork(CssModules)
    // and so on

mySyntax.validate(csstree.parse(css));

API is subject to change, but an idea should be clear. stylelint-validator would have an option to set a list of syntax extensions in future. You just need to wait a bit ;)

[jeddy3]

Since lexer builds an AST for syntaxes and represents a function as a single node, it should be changed to handle this case.

Thank you for taking the time to explain how things work! I've a much better understanding now.

Yes, we can add some ignorance or so. As an option is to define color() as a generic type, which never returns an error. But I think that's a bad solution.

Yep, I agree with you.

Well, I want to quote stylelint docs: since there are infinite processing possibilities, the linter cannot support everything. It should be clear that CSSTree or any other tool can't validate every syntax extension.

Definitely. We wrote that CSS Processors docs around the time when the number of PostCSS (language extension) plugins exploded, and we realised that we needed to draw a line somewhere.

Therefore I've implemented the extensibility feature to CSSTree. With that feature, anybody can extend syntax as needed... stylelint-validator would have an option to set a list of syntax extensions in future. You just need to wait a bit ;)

That sounds awesome! I'll wait patiently :)

[lahmatiy]

Starting with v1.0.0-alpha.30, processing of syntax definitions like color() or color-mod() is not a problem anymore. However, color() and color-mod() are excluded from spec drafts currently (but may back in the future). Anyway, adding support for new syntaxes is possible in the following ways:

• (Preferred) Contribute changes to mdn/data
• (Undesirable) Contribute to CSSTree's patch dictionary. That's undesirable since we'll drop this file one day, I believe.
• Extend syntax dictionary on your side using lexer's API.

I believe, issue can be closed now.