W3C home > Mailing lists > Public > www-svg@w3.org > June 2015

Re: SVG animations without SMIL

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 3 Jun 2015 13:35:03 -0700
Message-ID: <CAAWBYDCVNE3BW2mBbfboCrk0uG0CM0wnW881mQiR5tkL4V1maA@mail.gmail.com>
To: Chris Lilley <chris@w3.org>
Cc: Philip Rogers <pdr@google.com>, Dirk Schulze <dschulze@adobe.com>, "www-svg@w3.org" <www-svg@w3.org>
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

I dunno if it's worth it now, but it might be interesting to revisit this.

Received on Wednesday, 3 June 2015 20:35:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:01 UTC