fix: handle unparseable @container conditions with error_recovery

[Larslllllll]

Summary

When parsing @container <name> { ... } (named container query with no condition), the lightningcss parser fails with "Unexpected end of input" because the { token is not recognized as a valid container condition.

This affects Turbopack (used by Next.js) which uses error_recovery: true in its CSS parsing configuration.

Root Cause

In src/parser.rs, the @container case has this error handling:

Err(e) => {
  if name.is_some() && input.is_exhausted() {
    // name only, no condition - allowed by new syntax
    AtRulePrelude::Container(name, None)
  } else {
    return Err(e);  // <-- This is the problem
  }
}

When input.is_exhausted() is false (i.e., there's a { token waiting), it returns an error instead of checking error_recovery.

Fix

Check self.options.error_recovery before returning the error. When error recovery is enabled, use ContainerCondition::Unknown for unparseable conditions:

Err(e) => {
  if name.is_some() && input.is_exhausted() {
    AtRulePrelude::Container(name, None)
  } else if self.options.error_recovery {
    self.options.warn(e);
    AtRulePrelude::Container(name, Some(
      ContainerCondition::Unknown(TokenList::parse(input, &self.options, 0)?)
    ))
  } else {
    return Err(e);
  }
}

Testing

The fix allows CSS like this to be parsed without error:

@supports (container-type: inline-size scroll-state) {
  @container scroll-content {
    .foo { max-width: 100cqw; }
  }
}

This CSS is generated by real-world libraries like nhsuk-frontend.

[devongovett]

We should probably fix the actual parser instead of relying on error recovery

[yisibl]

We should probably fix the actual parser instead of relying on error recovery

Yes, since I last updated the @container implementation, the syntax in the CSS specification has changed significantly, so I’ll implement the new syntax.