use prefixfree to get rid of CSS prefixes

[jancborchardt]

We should include prefixfree: http://leaverou.github.com/prefixfree/, a Javascript library which automatically adds the relevant browser-specific prefixes on the client.

That way we don’t need to add all the browser-specific prefixes manually in the CSS. Especially because we will always forget some, they might deprecate soon, and it makes the code messy.

cc @Raydiation

[blizzz]

I see that it eases development, but on the other side JS+CSS manipulation sounds like another performance slowdown.

[LukasReschke]

OT: http://caniuse.com/ is a nice website to check which prefixes you can safely drop.

[DeepDiver1975]

Can lesscss.org help us out here? (From the Rails world I know http://thoughtbot.github.com/bourbon/ and http://sass-lang.com/)

SASS and LESSCSS can be "compiled" to the real css and no js on client side is necessary (but also possible)

The necessary compilation step increases development and deployment overhead. (CI could help a bit - but still)

[LukasReschke]

Can lesscss.org help us out here?

Yes. But personally I prefer Compass:

#border-radius {
  @include border-radius(25px); 
}

becomes:

#border-radius {
  -webkit-border-radius: 25px;
  -moz-border-radius: 25px;
  -ms-border-radius: 25px;
  -o-border-radius: 25px;
  border-radius: 25px;
}

[jancborchardt]

Less or Compass or Sass (I don’t care) don’t solve the original problem because they just push all the prefixes in the files, which is 5 times as much as would normally be there for lots of selectors. prefixfree on the other hand checks what is needed and just appends those prefixes.

Also, these CSS preprocessors add a syntax everyone needs to learn and a compilation step. I honestly find them really annoying.

On a related note, from the prefixfree FAQ: »"Something like this belongs to the server-side" A server side script would need to add all prefixes, making the size of the CSS file considerably larger. Also, it should maintain a list of features that need prefixes, or add them all and unnecessarily bloat the stylesheet. -prefix-free automatically detects what needs a prefix and what doesn’t.«

[blizzz]

Technically, you could also check on server side which browser is used by checking the user agent (though it's not failsafe in case the value is modified by the user).

[jancborchardt]

Yes, but that will a) make it slow and b) be sniffing. There’s no reason to check the client on the server side if you can do it client-side, especially when there’s already a library which does what we need.

[blizzz]

You can cache on the server side, but not on the client. So from a performance perspective, I see problems rather on client side. I agree with b). The answer in the FAQ is just not 100% correct.

[jancborchardt]

You would need to cache client-specific stylesheets on the server-side. Then take a round trip to the server to return the correct one.

And of course you can cache on the client-side – and it makes way more sense when it’s client-specific like here. The browser does it automatically sometimes, and we should start to use AppCache anyway.

[raghunayyar]

@jancborchardt are we finally including prefixfree? Should I make a PR for the same?

[jancborchardt]

I thought about this more and, at least in core, there are not that many prefixes used. Only ~20 occurences. I don’t think this warrants adding another library, dependency and increase in load time. Most prefixes for the common stuff we use will be possible to phase out soon anyway.