W3C home > Mailing lists > Public > www-svg@w3.org > May 2014

Re: Clean-up SVG2 spec

From: Dirk Schulze <dschulze@adobe.com>
Date: Tue, 20 May 2014 17:17:15 +0000
To: David Dailey <ddailey@zoominternet.net>
CC: Jeremie Patonnier <jeremie.patonnier@gmail.com>, Tavmjong Bah <tav.w3c@gmail.com>, SVG public list <www-svg@w3.org>
Message-ID: <0F816E23-BB2E-4A3A-96A5-45D447CF3C2A@adobe.com>

On May 20, 2014, at 3:31 PM, David Dailey <ddailey@zoominternet.net> wrote:

> My stance on this is, no doubt, highly predictable. Ease of use of a spec by
> authors is a fundamental concern. Though, clearly, implementers and writers
> of the spec need it too;) 
> 
> Dirk writes:
> 
> "SVG should not be a monolithic document but describe the core of SVG. Just
> as the HTML spec does for HTML. Special casing every property in SVG itself
> however is not a solution IMO. It is a huge burden to track all changes on
> other specs for the editors as well. " 
> 
> As I observe many things (both SVG and HTML) that used to work across
> browsers begin to crumble as HTML5 and CSS exert their influence, merely
> having examples of what is *supposed* to happen in SVG might help those who
> are more interested in CSS than in SVG stay honest and remember whence their
> origins emanate, I think. The fancy parts of SVG (filters, animate, masking,
> use and replicate, transforms, etc.) are of primary utility for those
> interested in geometry as semantics, not to those for whom hypertext is the
> fundamental metaphor of communication.
> 
> Using HTML's crazy Tower of Babel as an example of how specs should be
> developed, maintained, and thence propagated into incompatible
> implementations, does not, to me, seem to be model for anything admirable! I
> am suspicious that part of that incompatibility is by design, in hopes not
> of having interoperability, but rather in hopes of having a single Darwinian
> survivor in a new round of browser wars.
> 
> As I say, my perspective here is probably predictable, but hopefully
> charming nonetheless;)

It is very sad that you get this impression. The idea of removing duplicated property description will cause the opposite: more interoperability. The web platform needs to be consistent in itself. It doesn’t help authors and (as a result) it doesn’t help the web platform to develop little silos of web techniques that do not work together as expected. It is my impression that the work of the WG in the last years is heading to a more interoperable SVG specification.

Yes, it means that we integrate proven web technologies even more. One of these is CSS. That is nothing new for SVG. In fact, as you indicated, SVG shaped CSS a lot. CSS always has been a part of SVG. SVG 1.1 and the duplicated text that I would like to remove was added to allow non-CSS viewers to implement SVG. These viewers are no longer supported or won’t update to SVG2 anyway and most likely don’t even need to. (Most of these viewers are implementations for UIs on set-top boxes or old mobile devices.)

CSS continues to develop and the CSS specifications are no longer interoperable to the specced behavior in SVG. This is a huge problem. UAs usually do not differ between HTML or SVG content for CSS. They share the same CSS engine. That is one reason why behavior changes in UAs over time and diverges from SVG 1.1.

You mentioned in earlier messages that you fear that CSS is taking over SVG features. At least I can assure you that the SVG WG does not loose influence. All the specifications: CSS Compositing and Blending, CSS Color, CSS Masking, Filter Effect, CSS Transforms and Geometry Interfaces have SVG WG members as main editors.

Last but not least your argument about Tower of Babel. Quite ironically I see SVG 1.1 as the Tower of Babel. A huge monolithic document that tries to solve all problems at once. I indeed am more in favor for “divide and conquer”. Create smaller modules that progress in isolation of other modules and do not block each other. In the long term, SVG 1.1 is too big to move forward. With these modules, SVG will have more and interoperable features instead of less.

Greetings,
Dirk

> 
> Regards
> David
> 
> 
> 
Received on Tuesday, 20 May 2014 17:17:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:53 UTC