Re: SVG's future

On Tue, Feb 14, 2017 at 1:55 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

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

This we understand, with the reserve however that until fairly recently the
buy-in of browser implementers seemed acquired, hence the surprising effect
of the original post about Mozilla.

I don’t understand what you mean by “their own spec features” regarding
Google engineers.


>
> 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 don’t see why there should be a conflict between those two aspects of
SVG. What we call the web is certainly more important –under a certain
perspective– than that specialist usage you refer to, that which is more
common on the intranet, in proprietary applications, academic applications,
etc. Then it’s understandable that the browser vendors feel the bulk of new
features as a heavy load. Unfortunately this means that the implementation
of new features should have been less ambitious. More on this further down.


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


Perhaps it’s not the only way around, and in any case if it requires a lot
more work, then the solution could be found elsewhere. We’ll come back to
this later.


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

Do you now think that was a productive approach? It seems to me like making
complicated when it could be simple. We’ll come back to this too if the
communication will continue. For the moment I can say that the roots of SVG
are very specific, as are those of HTML. And that the roots are still there.


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


There seems to have been lack of communication and coordination.

Engineers who work with SVG and CSS overlapping and running behind, that
doesn’t seem like a good model in the light of what you are saying. Do you
think it could continue nevertheless?  I have the impression that you too
in some way think that the double mission CSS/SVG was kind of a hindrance
for the development of SVG, and perhaps for both? A genuine question.


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

Would it be possible to know what are the good practices the WICG is trying
to drive in place, given that it probably considers now some old ones as
not so good?

Was the WICG a successful enterprise with eight proposals in nineteen
months? Is the spirit of the Extensible Web Manifesto still valid? I’m
asking this because I’ve always been suspicious when seeing several
concurrent organizations in a same domain. In fact, when I read “We are not
planning on being the new powers-that-be” [
https://www.w3.org/blog/2015/07/wicg/], it looks rather like it ended up
being the opposite.


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

In my view, when the browsers started to shift a lot of effort into
extensibility so that the community could solve a lot of
their own problems, they were rather resuming old habits after the years of
efforts that it took to eradicate them.


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


I don’t understand this very well. The way SVG was and is specified is the
normal way, like any other language. If the quest for interoperability and
extensibility means to turn all this or parts of it into rocket science, it
all becomes overly complicated, with the end result that good things that
don’t fit that mold are dropped. SVG has enough stature of its own to be
considered a black box, that’s how it is. There’s no need to look any
further. I really wish the browsers would stick to the basics because
they’ve been for quite a while now in a high fly zone, and although you say
that the fruits are there, the result doesn’t seem that appealing,
honestly, when I see the public part of the web. In any case many efforts
have been consecrated for a while now to providing material to a category
of users. Wouldn’t it make sense now to give that a break, and also take
care of other aspects/categories of users?


> 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,
>

Yes, chances are, but that doesn’t seem like a good reason for definitely
closing the door. The size of groups can be the only criterion at times,
even most of the time, but not all the time. Other aspects also need to be
considered at some point, for the simple sake of balance.


> because that's how this sort of thing traditionally progresses.


It was not always so (see above). I think most will agree that when the
browsers were (finally and voluntarily) under control (of the consortium)
all the developers were relieved and happy about it.


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

That’s because if a feature is only available through the binding language
it remains hermetic. Traditionally, the programming languages have always
addressed pre-specified interfaces. Why should that model change? Are there
guarantees that a different model will be better? Are there guarantees that
the features were specified by proper competences? How many JavaScript APIs
were abandoned or rewritten? (My take: >90%).


The specification of new features needs to take its own time, and sometimes
if a path taken proves to be inadequate the feature needs to be reworked.
It takes patience, and the thing remains under control. Many APIs on the
other end are involved in a race, and sometimes tend to jump the gun. Now
if it’s true that some mistakes were made with SVG 2, that’s no reason to
trash it, or is it?

I took the time to read well all that you wrote, to really try to
understand where the break occurred (browsers/W3C). I’m still a bit
confused about what the browsers are trying to achieve through full
integration, interchange and interoperability (please reformulate if
necessary).


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

What you wrote was good information. I don’t think I or anyone else here
were ever uninformed. We do know these things, but here we got a clearer
idea of the motivations. We wish we could also hear from Microsoft, to see
if they have the same motivations, how they formulate them.

I don’t think implementing the new features of SVG 2 one at a time would be
that much of a weight for the implementers, in particular if the duties of
their engineers were organized differently from what you described above,
and if the engineers were split and affected to tasks that they believe in
and enjoy. But that, from what you say, seems to come from deliberate
choices, which seem unilateral. Would you agree that the resulting
situation (not just for SVG) is a little chaotic?

Best regards,

Domenico Strazzullo