Color handling with the new CSS parser

[David Hyatt]

So the idea is you're lax about HTML color parsing, but strict about 
CSS color parsing?  I wonder if people write lousy CSS though that does 
stuff like this:

.foo { color: 336699; }

I tested that in Mozilla and it honored the color even without the #.  
I wonder what WinIE does.

dave

On Friday, February 21, 2003, at 05:59 AM, Lars Knoll wrote:

> Hi Dave,
>
> did you also use the new color parsing code for HTML attributes? See
> HTMLElementImpl::addHTMLColor in our current code base.
>
> I first tried the same as you now did, but this turned out to be too 
> messy and
> broke standards compliance for CSS.
>
> I'm now using addHTMLColor everywhere and html color attribute is used.
> addHTMLColor is btw 100% IE compatible when it comes to color parsing 
> (at
> least all my tests in khtmltests/html/font/ pass).
>
> Lars
>
>> 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
>>
>> _______________________________________________
>> Khtml-devel@mail.kde.org
>> http://mail.kde.org/mailman/listinfo/khtml-devel
>
> _______________________________________________
> Khtml-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel