Re: SVG's future

On 14 February 2017 at 01:55, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Feb 13, 2017 at 6:24 AM, Sebastian Zartner
> <sebastianzartner@gmail.com> wrote:
>> So, Tab, Rossen, Brian, whoever is responsible for SVG at Google,
>> Microsoft, Apple, and Mozilla, could you share your companies'
>> official opinions on this topic, please?
>
> I'm hesitant to explain anything in this thread; I've seen nothing but
> abuse and conspiracy theories so far.

I don't think I did that.

> 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.
>
> However, the spec also rushed ahead of implementors fairly
> significantly, speccing complicated features without the buy-in of
> browser implementors.  (As SVG is intended to be a web format, it's
> browser implementors that need to be brought on board; unfortunately,
> Inkscape itself, while a good product, doesn't suffice for this
> purpose.)  We run into situations like these all the time in web
> standards; it's something Google engineers are explicitly cautioned
> against falling into with their own spec features, because it almost
> always results in a failed spec that nobody (or at least, nobody
> *else*) implements, and that webpage authors thus can't use.  There
> was a definite sense of "SVG has been stagnant for years, we're making
> up for lost time" with the effort, but that doesn't automatically make
> impls eager to catch up.

Thank you for the detailed response!

> Somewhat exacerbating this is the conflict within the WG between "SVG
> is a web language" and "SVG is a general drawing language that has
> lots of potential viewing programs".  The latter impulse encourages
> the development of powerful new features that might have specialist
> usage, but not wide web usage; it's politically difficult/awkward to
> say "we can't add that until you get some browsers to support it as
> well".  *Not* doing this, tho, just means the spec is almost
> guaranteed to fail as a web standard.  It's a real
> rock-and-a-hard-place situation, as I've personally experienced at SVG
> meetings.  I think the only way around it is to explicitly separate
> out "SVG: The Web Parts" from "SVG: And The Kitchen Sink", but that
> requires a lot more work.

This sounds like a good approach. Though, I assume "SVG: And The
Kitchen Sink" then would be out of the scope of W3C's goals, right?

> 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.)

Sounds like this requires people dedicated to SVG-CSS, or more
generally, working on "SVG: The Web Parts".

> Additionally additionally, the SVG2 work ramped up right at a time
> when the browsers were, collectively, starting to shift a lot of
> effort into extensibility so that the community could solve a lot of
> their own problems, rather than relying on a standards body to do it
> all (and take forever to do it, and not address all use-cases, etc).
> The fruits of this are CSS's Houdini effort, HTML's custom elements,
> and a bunch of lower-level JS APIs that encourage building on top
> rather than being an end-point solution.  SVG didn't end up doing
> *any* of this, tho - it's still quite unclear if/how custom elements
> work with SVG, and all the major systems of SVG (shape elements, paint
> servers, etc) are still completely black-box, with not even a serious
> proposal for opening them up to extension.  This makes browser vendors
> a little twitchy - even if they add the current slate of features,
> there's a very good chance there will continue to be large feature
> requests that are trying to serve relatively small user groups,
> because that's how this sort of thing traditionally progresses.  (And,
> unfortunately, saying "this feature is cool but niche; we should
> enable it via JS, but don't need to build it into the language"
> receives pushback from the non-browser implementors; see my point two
> paragraphs back.)

I get your point. As you say, opening up SVG the way CSS Houdini and
HTML's custom elements do it, require a JS engine, which is obviously
too much of a requirement for non-browser implementors.

On the other hand, browser vendors obviously still drive non-Houdini
CSS specs and their implementations forward. Some its features are
even part of other specifications, like the shape-* CSS properties,
which are also defined in CSS Shapes 2 Editor's Draft[1]. So, SVG not
having an extensibility model, is not an general excuse for not
implementing most of SVG 2's features.

Also, unfortunately even features targetting bigger user groups
receive implementation reluctance from the side of browser vendors.

Regarding the discrepancy between Web and non-Web or niche features,
would it make sense to let another organization take over the
standardization of SVG and let the W3C only cover the parts that
extend SVG to work together with the Web?

Sebastian

PS: I just found a blog post from Tavmjong Bah, SVG 2 editor and
Inkscape programmer, which also explains the current SVG 2 situation:
http://tavmjong.free.fr/svg2_status.html

[2] https://drafts.csswg.org/css-shapes-2/

Received on Friday, 17 February 2017 11:17:36 UTC