- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 25 Mar 2014 12:46:47 -0700
- To: Justin Novosad <junov@google.com>
- Cc: Dirk Schulze <dschulze@adobe.com>, whatwg <whatwg@lists.whatwg.org>
On Tue, Mar 25, 2014 at 12:35 PM, Justin Novosad <junov@google.com> wrote: > On Tue, Mar 25, 2014 at 3:15 PM, Rik Cabanier <cabanier@gmail.com> wrote: >> >> >> I agree. That issue has the same root problem as currentTransform. >> It would be nice to get closure. >> >> Justin, you hinted that you would be willing to follow the spec which >> would make you match Firefox and IE. >> Are still planning on doing that? >> > > I'm in a holding pattern. I prepared a code change to that effect, but > then there was talk of changing the spec to skip path primitives when the > CTM is not invertible, which I think is a good idea. It would avoid a lot > of needless hoop jumping on the implementation side for supporting weird > edge cases that have little practical usefulness. > > Right now, there is no browser interoperability when using non-invertible > CTMs, and the web has been in this inconsistent state for a long time. The > fact that this issue has never escalated (AFAIK) is a strong hint that no > one out there really cares about this use case, so we should probably just > go for simplicity. Maklng path primitives and draw calls no-ops when the > CTM is non-invertible is simple to spec, implement, test, and understand > for developers. > Great to hear! I volunteer to update the Firefox implementation if we can get consensus. (see https://bugzilla.mozilla.org/show_bug.cgi?id=931587) > Note that Firefox is still non-compliant if there's a non-invertible >> matrix during filling/stroking/clipping >> >> >>> > PS: This is one reason I prefer a getter over an attribute because the >>> > getter does not return a mutable (live) SVGMatrix. But even than the >>> > problem above is not fully solved of course. >>> >> >> >
Received on Tuesday, 25 March 2014 19:47:19 UTC