It all depends on the way you work with CSSes - if you need to apply some small changes, first test them "live", in Firebug/similar tool. During the designing phase (when you don't have a finalized view of how you want to style your application yet), you might want to work with normal CSS files, but as soon as the general style clarifies, you should switch to ClientBundle/CssResource.
Why? Let me answer, by writing up some thought about the goals listed on CssResource's documentation page:
Primary
- Compatibility with non-GWT-aware CSS parsers (i.e. any extensions should be valid CSS syntax)
This does not imply that the stylesheet would necessarily make sense if you just displayed it in a browser - meaning, we want to only use valid CSS syntax, not some syntactic sugar that's gibberish to other parsers - might not be that important from your point of view (although, as a result, you don't need to change the syntax of your existing styles)
- Syntax validation - very important point, IMHO. You get stuff like checking for missing (possibly misspelled) CSS classes, syntax errors, etc. - something that had to be (usually, painfully) tracked down via some browser specific developer tool (Firebug). Here, you get those errors early, during compile time (or even faster, with the help of the Google Eclipse Plugin).
- Minification - this is not your run-of-the-mill minification, you get also selector and property merging. See the next point too.
- Leverage GWT compiler - if a CSS class is not used (the GWT Compiler can make such a distinction, since it has the overview of the whole application), it is pruned and not included in the compiled code. How many times have you found CSS classes that were left there after some design changes? This takes care of that (see also the CSS modularization point)
- Different CSS for different browsers, automatically - since the CSS generated this way is included with your JS code, it can (and is) optimized for the target browser - no need to include lengthy IE hacks in every permutation!
- Static evaluation of content - already mentioned it before
Secondary
- Basic CSS Modularization
- Via dependency-injection API style - you can inject CssResources as needed (for example, to facilitate custom themes in your application)
- Widgets can inject their own CSS only when it's needed - this is one of my favorite points, although at first I didn't see its significance - you divide your (usually) huge, monolithic CSS file into small modules, one for each Widget that uses UiBinder (which in turn uses
CssResource internally) plus probably one global CssResource for application-wide styles. This results in a much cleaner, easier to maintain CSS styles (at least, in my experience). This also means, that if your code doesn't use that particular Widget (maybe because you've used ocde splitting and it hasn't been loaded yet), you won't download those styles.
- BiDi (Janus-style?) - bidirectional text support, haven't used it but the docs look promising :)
- CSS image strips - automagical image sprites generation - what more can I say? ;)
- "Improve CSS"
- Constants - I've always missed this feature in the CSS specification - when you change your primary colour, you have to find & replace it in the whole file (possibly leading to some errors, where you want to use the old colour in some places) - this makes it more intuitive, IMHO, by introducing constants (via valid CSS syntax and without any runtime penalty)
- Simple expressions - you should skim through the docs to see the possibilities there, really cool stuff
Tertiary
- Runtime manipulation (StyleElement.setEnabled() handles many cases) - on stylesheet injection (during runtime), some values are evaluated - this allows for skinning, etc.
- Compile-time class-name checking (Java/CSS) - already mentioned the (obvious) benefits of this
- Obfuscation - this one is really cool too, the GWT Compiler can safely obfuscate all the styles in CssResources, because it has the overview of the whole application - thus, name clashes are impossible. This means that you can use long (but not too long ;)), meaningful class names, without worrying how that will impact the size of the application - it will all get obfuscated to nifty, short (even 1-2 character long), random strings. This also enables you to define a
.warning style in two Widgets and the compiler will understand that these two styles are in different namespaces (different Widgets) and thus should be treated differently (that is, obfuscated to different names).
About style injection
The class StyleInjector allows injecting styles at runtime. Additionally, the CssResource allows (at least according to the docs, I haven't tried it yet) for runtime substitution. For example, when you inject a CssResource containing the following:
@eval userBackground com.module.UserPreferences.getUserBackground();
div {
background: userBackground;
}
The userBackground will get evaluated and injected (as opposed to constants, which are resolved at runtime).