Fix at-rules nesting

[giuseppeg]

Fixes #214

[thysultan]

LGTM, also patched the @media prefixing in v3.0.6

span {}
      @media (min-width: 480px) { div { color: red } }

/* @media[prefix](min-width[prefix]:480px[prefix]) div[prefix]{color:red} */

[giuseppeg]

@thysultan thank you! I found another small bug

@-webkit-keyframes -[prefix]{0%{opacity:0}100%{opacity:1}}@keyframes -[prefix]{0%{opacity:0}100%{opacity:1}}

animations get an extra - :(

[thysultan]

I think that's by design since the key for name-spacing animations is extracted from the namespace and prefixed with a - incase the extracted key is a number, what is the input vs expected?

[thysultan]

In contrast the same key will be applied to the animation/animation-name property

[thysultan]

@giuseppeg Actually the way it handles it right now looks like incorrect behavior since it prevents you from using an empty namespace to mimic a global namespace with the guarantee that keyframe names are preserved. patched in v3.0.7

[giuseppeg]

@thysultan cool, however now (with 3.0.7) namespaced one don't get the prefix:

@keyframes hahaha {}
/* result @keyframes hahaha- {} */
/* expected @keyframes hahaha-[data-jsx="123"] {} */

I used [data-jsx="123"] or [data-jsx~="123"] as prefix which is invalid and can't be used in animations names unfortunately. Maybe you can hash those for animations?

[giuseppeg]

technically you could also do prefix.replace(/\W/g, '') instead of hashing

[thysultan]

For attributes it grabs just the part after = within quotes, then it converts every invalid character to a valid character. In this case numbers as leading characters are invalid so they are all converted to a single dash but there is also \s.#~+>@ as invalid characters, ex. putting a non-numeric character in front of those numbers will make them valid.

I wonder if we can avoid removing the leading number rule since the key is appended to the authored animation name making it valid in that context.

[giuseppeg]

I wonder if we can avoid removing the leading number rule since the key is appended to the authored animation name making it valid in that context.

Yes that's what I thought too, a string that matches the character class \w prefixed with the original (supposedly valid) animation name should be fine. It is not our problem if a user gives an invalid name to the animation.

I am fine with any solution :) as soon as it works with our data attributes too (whose value is numeric) – in general I think that this is a valid fix for the library in general.

[thysultan]

patched, v3.0.9