Since *width and _width (using width as an example property root) are not valid CSS properties, the declaration is ignored by all browsers except IE. IE's parser, however, ignores the * (in the case of IE6 and IE7) and the _ (in the case of IE6), sees the remaining string as a valid property, and applies the value. 

So I can write a CSS block like this:

selector {

width:100px; /*all browsers */

*width:120px; /* IE6 and IE7 */

}

And have control over which value goes to which browser. The first line sets the width for all browsers. The second line is applied by IE6 and IE7, overwriting, for those values, the value from the first line. The third line is only applied by IE6. Therefore, this pattern lets me cleanly and clearly set different values for different browsers.

When you view the validator's report, you'll notice that this "invalid" syntax generates multiple errors per instance. It's initially flagged as a general parse error. Then often as an unknown property. Then, in some cases, the resulting empty declaration generates another parse error. So, this pattern and its derivatives account for all but a handful of the total count.

There are two other things in YUI CSS that generate errors.

First, YUI Fonts sets *font-size:small; and *font:x-small; after initially setting a pixel font size. They are both instances of what I described above for IE, however "*font:x-small;" is also flagged for a different reason. The "font:" syntax is shorthand for all of the various font- properties (family, weight, line-height, etc). It is an error to use shorthand without specifying all the values. When IE is in Quirks Mode is don't fail on this error, and instead applies the value. So, by taking advantage of this mode-specific behavior in IE I can efficiently pass one value to Quirks Mode and another value to Standards Mode. I need to do this because the default font size is different in the two modes.  (YUI recommends you use Standards Mode, but we strive for the library to work well in both modes.)

The final thing the validator complains about is our use of the zoom property. Zoom is an IE-only property and therefore the standards-based validator flags it as an unknown property. I don't use it to actually zoom the page, but rather as a convenient way to trigger IE's internal notion of "hasLayout." Triggering hasLayout helps clear floats (more on hasLayout: http://www.satzansatz.de/cssd/onhavinglayout.html) Note that a value of 1 for zoom means 100%, or normal; therefore, even if future browsers implement the zoom property, the value of 1 will be innocuous. 

I believe these four explanations cover all the errors reported by the validator. 

A final note: Some CSS developers advocate that non-standard or non-valid CSS used to accommodate a specific browser's peculiarities should be quarantined within a discrete  .css file that is provided to that specific browser only.  (For IE, it's often delivered via "conditional comments.") Another argument suggests that filters and hacks should always be isolated to facilitate long-term maintenance. I do not generally contest those points of view, however, I feel that when developing library/framework code (as opposed to authoring site-specific code), the decision has different criteria. I think keeping keeping all the CSS for all the browsers in a single file makes the library easier to use, and helps it perform optimally (because it reduces HTTP requests). And I think the maintenance issue is less critical for library code since the library has dedicated custodians tending to it permanently. 

Sorry that got a bit long. I hope it helps you understand what you're seeing. I welcome follow-up questions and comments.