CSSOM - background with css variable

[lofcz]

This is a weird inconveniece I've encountered. When styles are included in a component model definion and a rule contains background: var(--my-var) default css parser (BrowserParserCss) ommits this in the output.

editor.DomComponents.addType(...
model:
 ...
 defaults: 
   ...
   styles: `
      .myRuleA {
         background: red; // works fine
     }

      .myRuleB {
         background: var(--my-primary); // ommited
     }

      .myRuleC {
         background-color: var(--my-primary); // works fine
     }
   `

background: var(--my-primary) is a valid usage of shorthand so I would expect it to work, it's just counter intuitive. CSSOM is new to me so I wonder whether this is a bug.

@artf

[artf]

Yeah in Chrome I see the .myRuleB parsed in:

.myRuleB {
	background-image: ;
	background-position-x: ;
	background-position-y: ;
	background-size: ;
	background-repeat-x: ;
	background-repeat-y: ;
	background-attachment: ;
	background-origin: ;
	background-clip: ;
	background-color: ;
}

Did you try already https://github.com/artf/grapesjs-parser-postcss?

[lofcz]

I have not tried custom parser yet. Makes me wonder shouldn't it be used by default if it can fix this then? Because this sounds more like a bug than a new feature to me.

[artf]

Yeah, the default CSS parser is definitely weird but I think it's more than enough for basic features. Including a third-party CSS parser in the core would be definitely a huge overhead for many projects and I like the idea of having/making the core as light as possible and more close to native API (even if most of the time are not that great).
Including the PostCSS parser is a matter of one line plugins: [parserPostCSS], so honestly, I don't see it as a problem.

[lofcz]

I got the rationale, thanks for the tip. Native APIs are a double edged sword (execCommand plagues RTEs to this day).

[lofcz]

follow up: GrapesJS/parser-postcss#3