Re: SVG's future

On Mon, Feb 13, 2017 at 6:24 AM, Sebastian Zartner
<sebastianzartner@gmail.com> wrote:
> On 13 February 2017 at 11:47, Domenico Strazzullo
> <strazzullo.domenico@gmail.com> wrote:
>> Please let's earn some respect for one another! Different opinions and valid
>> arguments can be expressed in an objective way, as well as in a subjective
>> way, let’s leave it to the free will.
>
> What I meant is that people in this thread should stop insulting each
> other. I agree, respect needs to be earned, but insults rather reach
> the opposite.

In particular, I will not respond to insulting messages, and will call
down further moderation resources if it continues.  Rudeness and abuse
is not allowed on this mailing list.  We're adults, act like it.

> 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.  But let's pretend for a moment
that everything's ok. Here's my personal opinions:

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.

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.  (CSS does this a tiny bit, in its
separation of a small number of Selectors features into a "static"
profile, where they're explicitly defined to not be valid in
stylesheets; this lets us introduce features that are super-useful for
querySelector() and related JS functions, but are way too expensive to
evaluate live on a dynamic page.  This list is intentionally kept very
small; it's a single feature right now.)

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

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 could probably point at a few more things that cause problems, but
this is already way more text than is reasonable for people to read,
and I've been working on it all day and don't have the time to say
less. ^_^

~TJ

Received on Tuesday, 14 February 2017 00:55:54 UTC