On a side note, I'd really like to use LESS or an equivalent, but the way I design/develop (and I'm an admittedly bad designer) is to tweak things in CSS, alt-tab, refresh the browser, and see the changes instantly. Likewise I can open up Firebug and tweak some style to see how it would look, then apply that change to the CSS file directly. LESS/SASS would introduce a compilation step there and essentially break my workflow. Am I wrong or is there a way around that while still being able to use a more-sane language to sugar up CSS?
It's pretty much the same workflow. I transitioned to this and found it pretty painless (no pun intended). Instead of changing CSS every time, you're changing your LESS stuff. Then, when you're ready to deploy, compile it and push it out.
compass has a watcher who compiles a new css when you change your sass/scss (if you like to copy-paste css, choose the scss syntax over sass), less has a less.js to compile client-side during dev.
To the refresh speed, with something like GWT these are only done on your final build, not during development. Certainly such a DevMode could be achieved in other frameworks as well. :)
I think that exposing your CSS source code with comments etc is more beneficial than detrimental. It helps us have a more open web and fosters an environment for new developers to learn from what's already great.
However, the overhead of always sending down the full CSS probably isn't worth it since so few people are actually interested. http://daneden.me/max-css/ suggests including a .max version of your css alongside the .min for this very purpose, which I think is a great idea.
I took a peak at your website's source, and it's strange that you micro-optimize the image while at the same time you have 6 separate uncompressed js files and you didn't bother to serve your assets from a separate cookie-less domain. What's the reasoning here?
btw since when is exposing CSS a problem? I don't get what OP means in that point.
We're relatively unconcerned about our website's (home page) source. Our actual application can be seen at https://www.lucidchart.com/demo. There you'll see a single large Javascript file served from Cloudfront, plus a few third-party-hosted files that we couldn't reasonably CDN (like Google Analytics and some other third-party APIs). There are also three CSS files. One is the bulk of the data (194KB over the wire) which is sent over the CDN. Then there is a separate file for jQuery UI (which will soon be removed) and one that is shared CSS with other parts of our app.
oh, ok. now it's not so weird :)
Exposing CSS is much less of an issue than exposing Javascript; that list was speaking about JS and CSS generally ("why a build process"). The post goes on to describe why CSS specifically is worth paying attention to.
Compare
.mixin (@a) when (lightness(@a) >= 50%) {
display: none;
to
@if $boolean
@debug "$boolean is #{$boolean}"
display: block
@else
@debug "$boolean is #{$boolean}"
display: none
If you need a bunch of objects to, say, have the same background color, that's why you can chain selectors. Your common background color would then only be defined in one place.
CSS doesn't have to be complex to get complex results. I would call a CSS file any longer than 200 lines a bad code smell.
As for browser-specific rules, in my mind they just plain don't exist. Add in an intelligent reset rule-set at the beginning of the file (and no, not one that destroys the margin, padding, and display rules of every single element, but only resets things as needed) then you can easily make completely cross-browser UIs.