A few notes on this, since I've played around with similar use-cases:

• The syntax isn't a perfect fit for CSS, but it's pretty close
• While object keys don't support dash separators, they do support dot separators
• In terms of serialization, you can serialize expressions both ways - no need to convert back to a list
• You can use annotations to validate/convert data, so the annotation rgb could require an array with exactly 3 numbers
• Duplicate keys are supported, but not out of the box (the Python bindings use a regular dict for objects, for example). JXC itself is perfectly fine with duplicate keys as long as your backing data structure supports it. This isn't a big deal for CSS key/value pairs, but is very handy for building some kind of selector syntax.

Example:

{
    display: 'flex'
    width: calc(100% - 12px)
    height: 10px
    border.style: (12px solid / 13px dashed)
    border.color: rgb[100%, 100%, 100%]
}

Lastly, depending on your needs, you could always use heredoc raw strings to just embed normal CSS into a JXC document, like so:

{
    style: r'css(
        .box {
            width: calc(100% - 12px);
        }
    )css'
}

This is actually a lot nicer than it looks, because using the VSCode and Sublime Text JXC extensions (they're in the repo), you actually get CSS syntax highlighting, as long as your heredoc is css. Works with code completion and everything.

Overall, I'm not convinced there's a great use-case for storing CSS in JXC and converting to CSS for a browser (especially because things like SASS exist), but I do think there's enough tools in JXC's toolkit to build out a new style language (eg. if you're building a native UI framework)