- From: Alex Danilo <alex@abbra.com>
- Date: Thu, 27 Sep 2012 22:49:22 +1000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Robin Berjon <robin@w3.org>, Cameron McCormack <cam@mcc.id.au>, www-svg <www-svg@w3.org>
--Original Message--: >On Wed, Sep 26, 2012 at 3:28 AM, Robin Berjon <robin@w3.org> wrote: >> On 25/09/2012 19:38 , Tab Atkins Jr. wrote: >>> Ooh, fill is a very good point - it's indeterminate which side is >>> inside and which is outside. >>> >>> Okay, then, I relent. In that degenerate case, we should say that no >>> path is drawn, and it simply moves to the end point. >> >> >> Ah, but doesn't that open the risk of there being a flicker if the point is >> animated? I guess that no path is drawn, but that animation ought to be >> careful to skip over the alignment position. > >If you were filling, it would flicker anyway when you crossed the >point. This is just a weird degenerate case with a lot of problems. >I'm not comfortable with this kind of flickering, or discontinuities >in behavior in general, but I don't see a good way to define the >behavior for this. I like the simple solution of moving to the end point since it does eliminate the infinite behaviour simply. The flicker is not ideal, but this is just another edge case that we need to specify, nothing more. We have prior issues with gradient focal points, etc. that aren't specified anyway, so it isn't something out of the ordinary. The convenience to authors of being able to specify a through and end point is _immensely_ more useful than the handful of edge cases where animation is concerned, and as long as we specify the expected behaviour, it should all be OK. If you animate your intermediate point outsided of the start->end line then you see junk, so be it... Alex >~TJ > > >
Received on Thursday, 27 September 2012 12:50:07 UTC