- From: David Dailey <ddailey@zoominternet.net>
- Date: Wed, 22 May 2013 09:29:11 -0400
- To: "'Jon Frost'" <jonfrost2020@gmail.com>, "'David Leunen'" <leunen.d@gmail.com>
- Cc: "'www-svg'" <www-svg@w3.org>
- Message-ID: <005f01ce56f0$5918a450$0b49ecf0$@net>
The thought had always been (and I think we put that in the proposal) that there would be a repeatCount=indefinite option that would draw to sufficient resolution based on the viewport. Sort of like how a diagonal SVG line is redrawn and re-antialiased when zoomed in upon. The line is not really unscalable, even though it has pixels used in its drawing. Replicate seems much more in the spirit of SVG than the other dozen microfeatures that people are spec-ing to match its diverse utility. Cheers David From: Jon Frost [mailto:jonfrost2020@gmail.com] Sent: Wednesday, May 22, 2013 8:57 AM To: David Leunen Cc: www-svg Subject: Re: Thoughts about variable-width strokes in SVG2 I see, thanks. I was wondering if that was one of the primary concerns. I was thinking/hoping that something like requestAnimationFrame for svg-replicate would help to mitigate that issue (requestReplicationFrame) or some other similar feature. I am a bit out of my league here though as I have not work on any browser implementations yet. David Leunen <leunen.d@gmail.com> wrote: On Tue, May 21, 2013 at 9:28 PM, Jon Frost <jonfrost2020@gmail.com> wrote: The declarative syntax of 'svg-replicate' is concise and intuitive and seems to get the job done, and it has been on the plate for some time. It would be good to at least heard some counter-arguments articulated if someone has the time. It is not scalable. That's the main counter-argument I think. It denies the first letter of the acronym. I don't really know how it'd compare to another spec, performance-wise.
Received on Wednesday, 22 May 2013 13:29:49 UTC