Treat property and attribute parse errors / invalid values as if they were not present
See https://github.com/w3c/svgwg/issues/639 where the SVGWG resolved that CSS values that fail to parse, or that parse correctly but fall outside the allowed range, should be ignored, and therefore should fall back to the default value. Also see the section on "initial value" and "invalid value" for attributes.
For example, the released version of SVG2 has the text "A negative value for rx must be treated as an illegal value", and that links to the CSS2 section on illegal values, which says, "User agents must ignore a declaration with an illegal value".
However, the ongoing SVG2 draft says, "A negative value for rx is invalid and must be ignored" instead, as for librsvg's recently fixed #718 (closed).
I think #718 (closed) happened because librsvg treats
rx as an attribute, not a property, and for SVG1.1 librsvg had a scheme where invalid values in attributes caused the whole element to be set "in error", and not rendered.
I think we ignored errors in CSS properties because of the way they are handed off to
properties.rs instead of parsed within each individual graphic element.
However, now that the behavior for properties and attributes is unified in the spec... I think we can simplify a lot of the code to deal with errors, and do the right thing as per the spec.
Try to parse a property, and on error, yield a
SpecifiedValue::Unspecifiedinstead. This will fall back to the default for the computed value.
Try to parse a property, and on error, yield a new
SpecifiedValue::Errorvariant. This will fall back to the default for the computed value. I think this may be semantically cleaner.
(It may be a good idea to do a sweep to see which attributes got converted to properties in SVG2, and do that.)
In theory this scheme would let us remove the
SetAttributes::set_attributes(), and just always succeed. Right now an element is just not rendered if any of its attributes has a parse error. As a point of note, the code tacitly assumes this:
impl Defaultfor an element, for example the
Rect, will generate that element's default attribute values for rendering time.
- Attributes that absolutely must be present at rendering time are not
Options, and we assume that their default value gets resolved as part of
impl Default. Attributes that can be omitted are
Option<T>, and the rendering code handles that and usually hardcodes a value for the default.
We may want to change some of those assumptions, I'm not sure yet how the refactoring will look.