Bubble directives that don't contain rules #870

Closed
srcspider opened this Issue Jul 30, 2013 · 8 comments

Projects

None yet

5 participants

@srcspider

Title edited by @nex3.

Bug Report Version (potentially simple fix)

@-webkit-keyframes needs to pop out of selectors.

Currently it's treated as any other rule.

Feature Version

The following may be very desirable for short one-time uses of this particular case.

example.scss

#x.y {
  .z {
     @-webkit-keyframes test {
        // ...
     }
    .example {-webkit-animation: test 5s infinite}
  }
}

example.css

@-webkit-keyframes x-y-z-test {
  /* ... */
}

#x.y .z .example {
  -webkit-animation: x-y-z-test 5s infinite
}
@robwierzbowski
Contributor

Why would you write keyframes in a context they're not allowed?

@srcspider

To keep them close to the use case; easier to read and follow and hence easier to maintain.

It would also be convenient for %rules since then they would only get inserted into the content when the relevant rules are actually in effect; as opposed to currently where since you have to place them outside the rules if you are limiting your rules on certain pages you'll still end up with all of them if they are part of a "library module."

Another reason for the feature suggestion is that I see coworkers use very very generic names which I'm pretty sure will cause stupid error and maintenance headaches eventually.

@nex3
Contributor
nex3 commented Aug 3, 2013

Bubbling makes sense for @-rules that can contain other rules. It doesn't make sense for @-rules that have their own custom contents that's different than that in a selector.

@nex3 nex3 closed this Aug 3, 2013
@jbalsas
jbalsas commented Jan 22, 2014

Hey, @robwierzbowski, @nex3,

We're hitting this same issue where we're wrapping some third party libraries inside a class. This is producing some invalid CSS for us.

Bubbling the @-rules would prevent generating invalid CSS in such a case.

What do you think?

Thanks!

@nex3
Contributor
nex3 commented Jan 22, 2014

@jbalsas That's a tough case, because it's not clear what the correct behavior is there. When you're wrapping an import in a class, it's clear that you want some sort of namespacing on the selectors etc that you're importing, but there's no good way to namespace @keyframes rules there. Putting them into the global namespace seems risky. It's not necessarily wrong, though, so I'll reopen this and mark it as "under consideration".

To be clear, if we support this, there would be no automatic prefix attached to bubbled keyframes directives.

@nex3 nex3 reopened this Jan 22, 2014
@natecavanaugh

@nex3 That would solve our (@jbalsas and I) use case, since I agree, there's no valid way to namespace @keyframes (but there's no valid way to namespace any at-rule, just any selectors inside of them).

IMHO, bubbling them out makes the most sense for no other reason than preserving the validity (and preventing a case where, while vendors are working with them being nested now, it possibly breaking in the future).

Thanks for reconsidering this :)

@jbalsas
jbalsas commented Jan 24, 2014

@nex3 Thanks a lot for considering this!

I'd like to add, that making sure we generate valid CSS will also improve interoperability between other tools. For instance, right now, we're having issues with a library that uses css-parse to go through our generated styles and fails because it can't parse them properly.

@nex3
Contributor
nex3 commented Aug 22, 2015

I think we'll go a different direction to handle this with the new import semantics.

@nex3 nex3 closed this Aug 22, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment