W3C home > Mailing lists > Public > www-svg@w3.org > January 2013

Re: SVG 2 Features and Approach

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 7 Jan 2013 14:09:01 -0800
Message-ID: <CAAWBYDCQ-dmUGJpehYsjZLH9RQbc3F-VFd_um=qGBmK0ws181g@mail.gmail.com>
To: David Dailey <ddailey@zoominternet.net>
Cc: Jelle <pjmulder@xs4all.nl>, www-svg <www-svg@w3.org>
On Mon, Jan 7, 2013 at 1:30 PM, David Dailey <ddailey@zoominternet.net> wrote:
> Well, those browsers happen to be wrong. It is not for the tail to wag the dog. The spec really should follow wisdom rather than caprice. There will be sound reasons to complain if SVG agrees to take a backward step in functionality and cogency of design. Because some individual at Mozilla decides he or she doesn't like SVG fonts is not exactly a groundswell of rationale for exclusion from a standard. Certain browsers are just not standards-compliant. It has always been this way with SVG. Should we remove SMIL animation because Microsoft says they don't like it. Should we remove text support because Firefox has a poor implementation of the 1.1 standard? Just allow some browsers to fail certain tests as they always have. Unless you want to be like HTML5 and remove things from the test suite so that all browsers are 100 percent compliant? Why not just roll back SVG to a least common denominator (that which all browsers support) and scrap initiatives to improve it.
>
> Accessibility is being gutted here, I think.
>
> Emoji in full color with animation will be rolled out in SVG format soon, and Apple learned that one can't sell i-phones in Japan without emoji.
>
> Enough rant! I had to get it out of my system since the rationale for SVG fonts is so much better than the rationale against them.

It doesn't matter whether you think SVG Fonts are superior to whatever
is happening now.  The job of a spec is to document reality, so other
people can come along and implement the same thing cheaply.  A lesser
job of a spec is to lead reality, showing implementations the desired
way forward, but you can only lead so far and so long before the
exercise stops being helpful and starts just being misleading.  If a
feature has been disavowed by the major implementations, there is no
sense in pretending that it's a real feature.  It doesn't belong to
the web, by definition.  Maintaining the illusion of it being a real
feature just saps editor resources and confused readers who aren't
intimately knowledgeable with current browser dev opinions.

Of the other things you mentioned, SMIL animation *is* being removed
(we're angling to replace it with Web Animations, which I think MS is
more favorable towards).  Text support being buggy is a minor issue -
note my "so far and so long" wording.  On the other hand, a bug that
is consistent between browsers and which has been around for a long
time *does* mean it should be written into the standard, unless
browsers agree that they can still change it and remove the bug.  (See
the Quirks Mode standard maintained by Simon Pieters.)

I'm not particularly interested in taking this conversation further,
as it's a tangent and is often unproductive, but always remember that
our job is solely to help interoperability.  Whatever else we do (like
trying to guide impls to a new feature) must be done in the service of
interop, and we must sacrifice our efforts if it hurts the interop
effort.

~TJ
Received on Monday, 7 January 2013 22:09:48 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT