I've been investigating ways to 'improve' the ExtJS 4 CSS file ext-all.css. I would appreciate any feedback.

This isn't about fixing 'bugs' as such. I had two motivating objectives:
  • A smaller CSS file would be a good thing.
  • The ExtJS CSS file should be a shining example of the best practices that lie between standards compliance and pragmatism.

All of my findings relate to the latest ext-all.css. Though each one constitutes a relatively minor issue I feel that taking them as a whole suggests there's an overall build up of avoidable cruft in the CSS files. This raises a handful of questions...
  • Does anyone agree with me?
  • What's the best way to report so many minor issues to get them fixed?
  • Do people feel these are issues that should be detected or even automatically optimized by a step in the build process? Most can be found with a regex.

I grouped the issues I found into 3 groups below. No doubt there will be CSS experts out there who can find fault with some of my suggestions. Bring it on, always good to learn new tricks.

I believe the items below are invalid CSS and unsupported by any browser:
  • Value null appears in several places. e.g. color: null;
  • -o-border-radius and -ms-border-radius have never been supported by any released browser, nor does it seems likely they ever will be.
  • As far as I can tell, none of user-select, -o-user-select and -ms-user-select are actually implemented by any browser. You could argue they're future proofing but, other than user-select, I don't think that argument holds up in practice if you consider the circumstances that would need to arise for them to be of any use.

I believe the items below are only needed to support browsers that ExtJS 4 does not officially support:
  • cursor: hand; is only needed for IE 5.5 and below, just use cursor: pointer;. See http://www.quirksmode.org/css/cursor.html
  • -moz-outline hasn't been needed since FF 1.5. Just use outline.
  • -khtml-border-radius isn't needed, -webkit-border-radius does the same job in supported versions of Safari and Chrome.
  • -khtml-user-select isn't needed, -webkit-user-select does the same job in supported versions of Safari and Chrome.

I believe the items below represent areas that could be further reduced or minified with equivalent results:
  • 0px can be reduced to just 0.
  • border-radius: 5px 5px;, and all the vendor-prefixed versions, don't require the second length, e.g. border-radius: 5px;. The Webkit version of this property, -webkit-border-radius, doesn't even support multiple values specified in this way. Similarly, padding and margin values such as padding: 3px 3px 3px 3px; could be reduced down to padding: 3px;.
  • There are, for example, two .x-window-default blocks immediately after each other, which could be merged. Also...
  • ...the two .x-window-default blocks find imaginatively verbose ways to set a border-radius of 5px.
  • A padding such as .x-dd-drag-ghost {padding: 5px;padding-left: 20px;} can be expressed more concisely as .x-dd-drag-ghost {padding: 5px 5px 5px 20px;}
  • A border such as .x-mask-msg {border: 1px solid;border-color: #99bce8;} be expressed more concisely as .x-mask-msg {border: 1px solid #99bce8;}
  • Hex color declarations such as #3399bb can be reduced to #39b.
  • The colors black and white are more verbose (albeit only by 1 byte) than their hex equivalents.
  • .x-tab-top-disabled has background-image: none; twice.
  • .x-tab-bar sets the background-color twice for no apparent reason.
  • .x-column-header uses the shorthand of font: 11px/15px ...;, then also sets it to font: 11px ...;. Why bother with both? Further, this shorthand seems to be supported by all the officially supported browsers so it could be used in many other places, e.g. .x-form-invalid-under.

No doubt many of these issues are a consequence of using SASS and Compass. In such cases I feel that makes finding a way to optimize them even more important so that all users of those frameworks can benefit.

I couldn't find much in the way of related forum posts:
Thoughts?