Compiler: Support for emitting prefixed css-functions about garden HOT 12 OPEN

I'm inclined to agree. The only question I have is what should the output look like in that case? Let's suppose we have

{:some-property ^:prefix ^:vendors [:webkit] (some-css-fn ...)}

Do we compile separate declarations for each vendor?

lol {
  some-property: -webkit-some-css-fn(...);
  some-property: some-css-fn(...); 
}

from garden.

Yes, that's the correct way of doing this according to MDN. See
https://developer.mozilla.org/en-US/docs/Web/CSS/calc#Examples

On Sat, May 24, 2014 at 9:15 PM, Joel Holdbrooks
[email protected]:

I'm inclined to agree. The only question I have is what should the output
look like in that case? Let's suppose we have

{:some-property ^:prefix ^:vendors [:webkit](some-css-fn ...)}

Do we compile separate declarations for each vendor?

lol {
some-property: -webkit-some-css-fn(...);
some-property: some-css-fn(...); }

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-44096853
.

from garden.

You might also want to consider the following: transtion: all 1s, -webkit-transform 2s;

from garden.

OK. I think this is doable but it's going to require a bit of forethought and planning before we can make this happen. One concern is

^:prefix {:some-property ^:prefix (some-css-fn ...)}

I suppose we could make the assumption that if, for example, the vendors were [:moz :webkit] we'd compile three lines: one for -moz-, one for -webkit-, and one unprefixed.

from garden.

@jeluard I think we can handle that case during declaration expansion but that's kind of gross. The compiler needs to be reworked to operate on a data format like tools.analyzer has. I've been toying with that idea and I'm willing to bet we could make a lot of these problems go away by moving in that direction.

from garden.

I suppose we could make the assumption that if, for example, the vendors were [:moz :webkit] we'd compile three lines: one for -moz-, one for -webkit-, and one unprefixed.

Sounds reasonable.

from garden.

@the-kenny @jeluard If you guys think of any more edge cases be sure to post them here. I want to close out some of the other stale issues before moving on this.

from garden.

Also not sure how it fits here but I've been thinking it would be really nice to leverage CSS.supports for the ClojureScript implementation. It would allow to generate the proper flavor at runtime and skip the useless ones.

from garden.

@jeluard Yes! That definitely needs to get added!

from garden.

...two years later this has been fixed (734e494).

from garden.

seems like this never got closed?

from garden.

@awkay it's fixed on the 2.0.0 branch (which is still in the works).

from garden.