SVG 1.1 Appendix F section 4 says: "When out-of-range values are provided, the user agent shall defer any error checking until after presentation time, as composited actions might produce intermediate values which are out-of-range but final values which are within range." http://www.w3.org/TR/SVG11/implnote.html#RangeClamping For example, you could have a situation like: <animate attributeName="opacity" begin="0s" dur="1s" from="0" to="2"/> <animate attributeName="opacity" begin="0s" dur="1s" by="-1" /> or like this: <animate attributeName="stroke-width" begin="0s" dur="1s" from="5pt" to="-5pt"/> <animate attributeName="stroke-width" begin="0s" dur="1s" by="5pt" /> In both examples above, the first <animate> node has an endpoint that's outside the valid range for the animated property. However, if we do things correctly, the second "by" animation will add to the first and push the composed value back into valid territory, and so we'll get smooth animation between in-bounds values. In order for this to work correctly, we can't have the CSS parser do its normal range-clamping when it parses the <animate> node's to/from/by values. We need those potentially-out-of-range values to be faithfully preserved in order for our interpolation math to work out correctly. So, I'm filing this bug on adding a "relaxed range-checking mode" to the CSS parser, for use in parsing these values.