This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
currently code such as: <rect x="20" y="15" width="250" height="268" fill="eee" /> validates. however it seems this is not correct (reference needed) at least one major browser barfs, and current blackberry fails reporting: java io exception color parser "eee" is an invalid string representation of SVGRGB color please move if this is wrong component please advise manufacturers, browsers if you believe vaildator is correct. regards
firefox/minefield/mozilla will not, and will 'never' accept rgb values that are not preceded by #. in addition to blackberry browser report in description
https://bugzilla.mozilla.org/show_bug.cgi?id=597974
(In reply to comment #0) > currently code such as: > <rect x="20" y="15" width="250" height="268" fill="eee" /> > validates. > > however it seems this is not correct (reference needed) > at least one major browser barfs, and current blackberry fails reporting: > java io exception color parser "eee" is an invalid string representation of > SVGRGB color > (In reply to comment #1) > firefox/minefield/mozilla will not, and will 'never' accept rgb values that > are not preceded by #. I would guess that this is allowed by the validator because it interprets it as an unknown X11 color keyword, not a malformed hex color (the Java exception mentioned is a #F00 herring). The Validator should check color values against the list in the CSS3 Color module http://www.w3.org/TR/css3-color/#svg-color and issue an error or warning based on that, if the string doesn't match the production for an RGB, RGBA, HSL, HSLA, or hexadecimal color notation, or one of the allowed color keywords like transparent or 'currentColor'.
the SVG 1.1 RelaxNG grammar currently used by validator.nu and thus by the W3C HTML validation backend was essentially taken straight from http://www.w3.org/Graphics/SVG/1.1/rng/svg-paint-attrib.rng That grammar defines the datatype for the "fill" attribute simply as "string". So validator.nu does not real checking on the value of that attribute at all. If there is a deficiency here, it is in the upstream schema. if the upstream schema is revised to do stricter constraint checking on that attribute, i will be happy to port the changes to valdiator.nu meanwhile, I'm changing the product on this bug to "SVG"