Fwd: [whatwg] Singular CTM and currentTransform

forwarding to public-canvas to get more feedback.
What do people think about standardizing matrix handling on the
WebKit/Blink behavior?

See proposal below.

---------- Forwarded message ----------
From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, Mar 25, 2014 at 12:46 PM
Subject: Re: [whatwg] Singular CTM and currentTransform
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.
>>>
>>
>>
>