Re: SVG animations without SMIL


> On Jun 3, 2015, at 10:35 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Wed, Jun 3, 2015 at 12:34 PM, Chris Lilley <chris@w3.org> wrote:
>> Wednesday, June 3, 2015, 8:20:36 PM, Philip Rogers wrote:
>>> The SVG path syntax is pretty difficult to use (IIRC it was
>>> designed before gzip which is why it uses one-character commands)
>> 
>> That is incorrect. It was designed both to be short when sent without
>> compression, and also short(er) when used with gzip; SVG 1.0 mandated
>> that implementations support gzip which was unusual back then.
>> 
>> Of course, it compresses better with new compression methods such as
>> Brotli.
>> 
>> Since path data forms the bulk of most SVG illustrations and since it
>> was competing with binary formats such as Flash, shortness was
>> considered very important for SVG to be competitive.
> 
> While we're revisiting this...
> 
> The solution we ended up with seems like the worst of both worlds.
> It's hard to read and hand-edit (because it's so compact and
> obfuscatable, especially with unnecessary spaces removed) *and* it's
> still way bigger than a specialized compact format would be.  I
> suspect this discussion was had to death back in the day, but I think
> we could have done better with a slightly more verbose hand-authoring
> format, along with a well-defined algorithm for packing/unpacking it
> into a base64'd binary format, which tools could produce for us for
> production.
> 
> I dunno if it's worth it now, but it might be interesting to revisit this.

If we allow the `d` property to have either a string, or a function then

* a string can represent the current SVG path syntax
* a function can represent a special path description.

In an earlier mail I mentioned that we already have some path functions:

* circle(),
* ellipse(),
* inset(),
* polygon(),
* path() (with the old path syntax again).

Going forward we can experiment with ideas like

* Catmull-Rom,
* “turtle graphics”

also covered by new path functions. All strings and functions are animatable. The initial value would be `none`. (Since having no `d` attribute doesn’t render a path element.)

Going forward, I would really like to combine the descriptions of all path functions and the SVG path data string into one spec. This way the descriptions can be removed from CSS Masking, CSS Shapes and Motion Path.

Greetings,
Dirk

PS: I would really like to freeze the old SVG path syntax to the commands of SVG 1.1 but the syntax corrections of SVG2.


> 
> ~TJ

Received on Thursday, 4 June 2015 05:03:28 UTC