Failed to parse css variables without trailing semicolon

[hucsmn]

Input:

.item {
  --min-height: 66px
}

.item::placeholder {
  font-size: 24px;
}

Produces:

{
  value: '.item',
  root: null,
  parent: null,
  type: 'rule',
  props: [ '.item' ],
  children: [
    {
      value: '--min-height:66px}.item::placeholder{font-size:24px;',
      root: [Circular],
      parent: [Circular],
      type: 'decl',
      props: '--min-height:66px}.item::placeholder{font-size',
      children: '24px',
      line: 6,
      column: 19,
      length: 46,
      return: ''
    }
  ],
  line: 1,
  column: 8,
  length: 0,
  return: ''
}

This corner case is reproducable in both 4.0.3 and 4.0.6.

Interestingly, there was no problem if simply replace --min-height with min-height:

{
  value: '.item',
  root: null,
  parent: null,
  type: 'rule',
  props: [ '.item' ],
  children: [
    {
      value: 'min-height:66px;',
      root: [Circular],
      parent: [Circular],
      type: 'decl',
      props: 'min-height',
      children: '66px',
      line: 3,
      column: 2,
      length: 10,
      return: ''
    }
  ],
  line: 1,
  column: 8,
  length: 0,
  return: ''
}

[Andarist]

The reason is that we are turning off } handling when consuming the value of a CSS variable:
https://github.com/thysultan/stylis.js/blob/457a9fd29eb75cfe58002937a3b3924d62601d48/src/Parser.js#L66
which is done to handle this bizarre edge case:
https://github.com/thysultan/stylis.js/blob/457a9fd29eb75cfe58002937a3b3924d62601d48/test/Parser.js#L829

Not sure how to best approach fixing that in a minimal amount of code - I'm crying when thinking about those CSS variable edge cases.

[thysultan]

I've always had a (╯°□°)╯︵ ┻━┻ vibe with those css variables edge cases.

[layershifter]

Just met the same issue, the easiest repro is below:

Input

.foo { --bar: var(--baz) }

Output

.foo {
--bar:var(--baz)}
}
	
;
}

[thysultan]

Although it is useable if you just add an explicit semicolon. @Andarist I think this issue is more important as is mentioned in frontity/frontity#753 than the css-variable edge case of --at-keyword-unknown-block: @foobar {}; so we should revert to not supporting that?

[thysultan]

Also i wonder what does the css spec say about h1{--example: {} is it h1{--example:{;} or h1{--example:{} the later of which is an unterminated block.

[Andarist]

@Andarist I think this issue is more important as is mentioned in frontity/frontity#753 than the css-variable edge case of --at-keyword-unknown-block: @foobar {}; so we should revert to not supporting that?

Agreed that this is more important. Question is - is Stylis aiming to parse all valid CSS or are we not caring about edge cases like this? I'm fine with both - if we don't care then this should be mentioned in the docs. It's a fair tradeoff but has to be acknowledged.

Also i wonder what does the css spec say about h1{--example: {} is it h1{--example:{;} or h1{--example:{} the later of which is an unterminated block.

Quite frankly - I don't want to dive deep figuring this out from the spec. I've checked 2 things though:

1. Prettier claims that:

SyntaxError: CssSyntaxError: Unclosed block (1:1)

2. Chrome allows this:

var s = document.createElement('style')
document.head.append(s)
s.sheet.insertRule(`h1{--example: {}`)
s.sheet.cssRules[0].cssText // "h1 { --example: {}; }"

[thysultan]

A better test for that would be

var s = document.createElement('style')
document.body.append(s)
s.innerHTML = 'body{--example:{} body{background:red;}'

Which results in

body {
  --example: {} body{background:red;};

Whereby body{background:red;} ends up being part of the --example variable and not another rule.