RE: SVG2 polyfill

Yep, Doug, I think that is what I understood as well. SMIL is not universally interoperable and so long as one is polyfilling it one might as well extend it too until SVG n.0 catches up ¿que no?

Cheers
D

-----Original Message-----
From: Doug Schepers [mailto:schepers@w3.org] 
Sent: Thursday, August 25, 2016 3:45 PM
To: David Dailey; 'Amelia Bellamy-Royds'; 'Frédéric Guimont'
Cc: 'www-svg'; 'David Leunen'
Subject: Re: SVG2 polyfill

Hi, folks–

David, just to be clear, what Frédéric is suggesting is a polyfill, which is a specific kind of javascript library. An SVG 2 polyfill would provide a temporary patch for new SVG features in browsers that don't yet support them, so that people could use SVG 2 even before it's universally interoperable across browsers.

Frédéric, I'm not sure how possible this would be for some features, but I think it's a great idea.

Regards–
Doug

On 8/24/16 6:30 PM, David Dailey wrote:
> Fwiw, David Leunen has been working on FakeSmile [1] that is sort of a 
> polyfill for SMIL-ish things. Am not sure if he’s still actively doing 
> it or not.
>
>
>
> Then there is the <replicate>[2] and <random>[3] stuff that allows 
> Processing.js type to create interpolations, replications, 
> randomizations, tessellations, nonlinear gradients and 2.5D stuff. 
> Both FakeSmile and <replicate> involve parsing out the modifiers of 
> SVG elements (pattern, filter, gradient, etc) so that as objects are 
> replicated they can be incrementally changed (even using keySplines to 
> adjust the rate of change). See example [4]. It also allows for values 
> of quantitative attributes (not just x and y) to be controlled by 
> values taken from a user-defined SVG path, providing much more precise 
> and intuitive shaping of curves than keySplines would affort.
>
>
>
> The desire to have declarative randomness in SVG has been often 
> expressed, and this addresses the ability to run skeins that have 
> either fixed or randomized start-seeds.
>
>
>
> The core business of parsing values lists, as well as from-to, and 
> interpolation is common between <animate> and <replicate> being based 
> on the same conceptual model of the universe, so some of the code used 
> in replicate could prove useful to new work on polyfills. Replicate 
> also has the advantage that it extends concepts present in SMIL in new 
> directions very consistent with original design intentions of SVG.
>  Several of these extensions to SMIL’s functionality are things I hope 
> that SVG3 may be willing to consider since a lot of the HTML/CSS/SVG 
> playground rules have been established by SVG2.
>
>
>
> I think we may have used some of FakeSmile in <replicate> , I can’t 
> recall, but the .js stuff in <replicate> here [5] is open source. 
> Since I’ve recently figured out how to parse CSS rules [6] (never 
> tried it before, but CSS is actually starting to work with SVG in some 
> places now, so I have started to get interested), I’ve been 
> considering extending <replicate> to include the parsing of CSS rules, 
> so that one might take those things that CSS offers that SVG doesn’t 
> yet (like 3D rotation, text flow, and blend modes[7]) and somehow 
> modify during the process of extrapolation along a path.  Not quite 
> sure yet, what gradually modifying a perspective transform along a 
> Bezier curve would give us that modifying an affine one doesn’t, but 
> it could prove interesting! I’ll see if any students are interested in 
> such, and that project may have a bit of new life.
>
>
>
> Am also interested in using SVG + Replicate +random as a declarative 
> syntax that could then be cross-coded into WebGL, so that a 3D model 
> is quickly sketched in that declarative environment and then poofed 
> (technical term) into a full blown WebGL with wireframe and shaders.
> Again a fun project, though I think it might require something like a 
> summer-of-code project rather than just an undergrad volunteer or two.
>
>
>
> Cheers
>
> David
>
>
>
>
>
> [1] https://leunen.me/fakesmile/
>
> [2] 
> http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2010/replicate.htm
>
> [3] http://cs.sru.edu/%7Eddailey/svg/RandomTalk.html
>
> [4] http://cs.sru.edu/~ddailey/svg/svg2.svg
>
> [5] http://granite.sru.edu/~svg/rep.js
> <view-source:http://granite.sru.edu/%7Esvg/rep.js>"
>
> [6] http://cs.sru.edu/~ddailey/svg/3Dsimple0b.svg
>
> [7] https://ello.co/ddailey/post/hwqd8hmolnwx7-vp4zocfq
>
>
>
> *From:*Amelia Bellamy-Royds [mailto:amelia.bellamy.royds@gmail.com]
> *Sent:* Wednesday, August 24, 2016 5:24 PM
> *To:* Frédéric Guimont
> *Cc:* www-svg
> *Subject:* Re: SVG2 polyfill
>
>
>
> I don't know of any polyfills currently being worked on, although I've 
> heard a few people talk about maybe making polyfills for particular 
> features.  It's something I'd like to work on myself, but that's 
> probably not going to happen without funding.
>
>
>
> It is certainly something working group members would like to see. I'm 
> not sure how much support would be available to help with the project, 
> but do keep us informed if you start work on it.
>
>
>
> And please file spec issues (https://github.com/w3c/svgwg/issues) if 
> any sections are unclear or inconsistent about what the behavior *should* be.
>
>
>
> Best,
>
> Amelia Bellamy-Royds
>
>
>
> On 24 August 2016 at 14:41, Frédéric Guimont 
> <frederic.guimont@savoirfairelinux.com
> <mailto:frederic.guimont@savoirfairelinux.com>> wrote:
>
> Hi all,
>
> Is there anyone working on an SVG2 polyfill? If not, would there be 
> any interest in such a project? I'm thinking of proposing an R&D 
> project on the topic but I need more info first.
>
> Thanks,
> --
> Frédéric Guimont, Consultant en logiciels libres Savoir-faire Linux
>
> Téléphone  : 418-525-7354 #362 <tel:418-525-7354%20%23362>
> Ring ID    : d9396b8004d26120f1e948ac7a075ab7dd165077
> www.savoirfairelinux.com <http://www.savoirfairelinux.com>
>
>
>

Received on Friday, 26 August 2016 02:10:43 UTC