Re: SVG's future

Tab,


Don’t worry, now that you took the necessary time, attention, and
consideration in writing, you will not be insulted, if you ever had the
feeling you were.


I will comment later on the rest of your post.

Domenico Strazzullo



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