Color handling with the new CSS parser

[David Hyatt]

So Safari's page load tests had a lot of errors with colors with the 
new parser.  The basic issue is that the new parser is strict about 
requiring the # in front of color names, and it also ignores string 
values for colors (so not all of the named colors work).

The following patch fixes all the problems, but I don't really like it. 
  Basically I go ahead and handle all the crazy unit types I can get 
from having a malformed color...

The three examples I had to patch for:

000099 = a number, but you lose the "0000" so you have to pad back out 
to 6 characters.
ffffff = a string, so that unit type has to be checked (seems like this 
type needed to be checked
anyway, but wasn't, which i didn't understand)
99ccff = a dimension (not sure why it thought this was a dimension and 
not just a string)

The top of parseColor looks like this for me now:

     QRgb c = khtml::invalidColor;
     Value *value = valueList->current();
     if ( value->unit == CSSPrimitiveValue::CSS_NUMBER ) {
         QString numStr = QString::number( value->fValue );
         if (numStr.length() < 6) {
             QString colorStr = QString();
             int padding = 6 - numStr.length();
             while (padding) {
                 colorStr += "0";
                 padding--;
             }
             colorStr += numStr;
             numStr = colorStr;
         }
         c = ::parseColor(numStr);
     }
     else if ( value->unit == CSSPrimitiveValue::CSS_RGBCOLOR ||
               value->unit == CSSPrimitiveValue::CSS_IDENT ||
               value->unit == CSSPrimitiveValue::CSS_STRING ||
               value->unit == CSSPrimitiveValue::CSS_DIMENSION )
	c = ::parseColor( qString( value->string ));
     else
	...

Is there a way to perhaps fix this with a production in parser.y that 
would be cleaner than this?

dave