Re: SVG's future

On Tue, Feb 14, 2017 at 12:55 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> SVG2 is a really useful effort in a number of ways - it tightened up a
> lot of definitions, and making the SVG DOM more consistent with HTML
> and CSS, along with a few other tightened integrations between SVG and
> HTML/CSS, have been extremely good.

[…]

> Additionally, the WG as a whole was somewhat starved for attention.
> An individual can only attend so many international meetings in a
> year; with CSS already eating up 4 of those meetings, and the heavy
> overlap between browser engineers who work with SVG and CSS, it meant
> that it was difficult to get the same sort of attendance from browser
> engineers.  (I personally haven't attended an SVGWG meeting for over a
> year for this reason; I budget my time away from home pretty
> carefully, and am definitely primarily a CSS person.)  The WG didn't
> adapt to this very well, still trying to do a lot of the work in
> face-to-face meetings, and as a result a lot of decisions got made in
> groups that didn't include proper stakeholders.  (This is a hard thing
> to solve, so I don't blame the WG much; WICG is trying to drive good
> practices for this route now.)

To mostly agree with Tab:

I definitely think SVG2 is a worthwhile effort, but at some point
there's some limitation of resources that browser vendors have: SVG2
is inherently always going to be in competition with other new
features when it comes to implementer time. Browser vendors aren't at
the end of the day bottomless pits of money and resources and some
prioritisation is inevitable.

The fairly small number of people at each vendor who primarily work on
SVG spend the majority of their time (AFAICT!) fixing interop bugs
which was in many ways in later years one of the major aims of SVG2
(through tightening up definitions). Looking through the highest
priority SVG bugs on Chromium[0], for example, almost all of the P1/2
bugs are about correctness, performance, and crashes.

To some degree the relatively low usage of SVG plays into this as
well; new CSS features tend to get far more uptake than new SVG
features (as far as I can tell, the majority of the SVGs on the web
remain very simple, but obviously implementation quality as a result
of low priority as a result of low usage will play into that).

That all said, I don't think anyone has any fundamental objects to any
of the new features in SVG2—it is purely a matter of prioritisation. I
suspect that all the open source browser engines would welcome more in
the way of contributions to SVG, both adding new SVG2 features and
fixing existing bugs.

/g

Received on Friday, 17 February 2017 16:30:31 UTC