- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 23 May 2012 11:18:36 +1000
- To: Erik Dahlstrom <ed@opera.com>
- CC: SVG public list <www-svg@w3.org>
OK, here are some differences that might be worth discussing. In SVG Tiny 1.2, the Computed Value line for fill says: "none", system paint, specified <color> value or absolute IRI What I have currently written for SVG 2 is: If a <color> value is part of the specified value, then it is computed as per the 'color' property. For anything else the computed value is as specified. I do need to add something about the absolutisation of the IRI. But what about the <color> part? Are you OK with keeping that in? It's probably good to be consistent with other CSS properties that take <color>s. In Tiny, fill-rule says: Specified value, except inherit (We can forget about the "except inherit" bit, since CSS already handles that for us.) I've currently got: as specified, but clamped to the range [0, 1] Here's a test: http://people.mozilla.org/~cmccormack/tests/fill-opacity-computed.svg The text shows what getComputedStyle returns for an element with fill-opacity="-1" on it. (Yes that's the used value, not computed, but still might be interesting.) Since CSS Transitions work on computed values, I used those to see transitioning from -1 to 1 looks like. Gecko seems to do the clamping as part of the computed value computation, as both rectangles transition the same, from 0 to 1. WebKit seems to clamp later than computed value and used value time, so the transition actually runs from -1 to 1. (The transitions aren't working for me in Opera.) In Tiny and currently in SVG 2, stroke-dasharray and stroke-dashoffset's computed value is "as specified". But it seems common in CSS properties to compute lengths to absolute values. I've asked about that here: http://lists.w3.org/Archives/Public/www-style/2012May/0818.html
Received on Wednesday, 23 May 2012 01:19:30 UTC