Re: new feature request

I can comment on the most effective ways to convince browser developers
that feature X is important.

1. Show us a security reason to do something. Security reasons will also
prevent things from being implemented, which I think is how this whole
thread started.

2. Show us a lot of pain from an important group of content developers. The
most effective way to do this is to get something working, but in a way
that is obviously horrible. It may require complex tools, or perform badly,
or not work everywhere. "An important group of developers" is hard to
define, but in general we would consider someone with a large audience
reach or enterprise customers who would move software to the web. An
apropos example is CSS Animations, or CSS compositing, blending and
filters. More contentious examples include multi-column layout.

3. Show us something you can do in a mobile app or standalone piece of
software but cannot do on the web, that many developers would benefit from.
For example, Chrome is landing support for notifications. There is work on
custom scrolling behavior. And other cases.

SVG really does have a chicken and egg problem here, due to its perceived
importance to the general web community. Step zero, I think, is to get as
many people as possible using SVG on their sites. Many things would become
easier with a larger developer community. The focus on CSS interoperability
and the like is, as I understand it, part of an effort to make SVG easier
for the general web community to use, which is a decent tactic for
expanding usage.

Regarding finding a browser vendor that is "pioneering", you will run into
an ongoing effort among the major browser platforms to better coordinate
features. We tried the pioneering browser thing (see Internet Explorer,
webkit-blah, ...) and it didn't work out so well. Recent examples suggest
that, at a minimum, you need at least two browser vendors to agree on a web
platform feature before it moves forward (see, for example, snap points for
scrolling).

Stephen.

On Fri, Mar 20, 2015 at 8:51 PM, Charles Lamont <
charles@gateho.gotadsl.co.uk> wrote:

> On 2015-03-20 18:53, Stephen Chenney wrote:
>
> (See below)
>
> > When composing my initial response I thought of how one would address
> > the multiple SVG application domains, and both Paul's suggestions
> > came to mind. I think browser developers would be concerned about a
> > fork or web/non-web features for at least two reasons: in practice we
> > would undoubtedly have problems with "why doesn't my content render
> > in [your favorite browser]", and similar but not identical specs for
> > a single problem space leads to fragmentation and is just a pain for
> > content developers. My personal feeling is that the community can
> > decide what to do and as browser vendors we'll take part and then
> > deal with the consequences.
> >
> > There is no technical argument against having features in the spec
> > that no browser implements, but some other specialized, say CAD,
> > viewer might implement, provided those features don't impact browser
> > behavior or performance. There are non-technical problems, such as
> > maintaining browser vendor agreement on what features are in or out.
> > To avoid fragmentation and reduce developer confusion I think it
> > should be an extension or otherwise clearly delineated piece of spec.
> > And I think it will be hard to get traction on it within the W3C in
> > the current environment.
> >
> > Stephen.
> >
> > On Fri, Mar 20, 2015 at 1:23 PM, Paul LeBeau <paul.lebeau@gmail.com>
> > wrote:
> >
> >> Stephen Chenney wrote:
> >>> That's where we are and complaining about features being driven
> >>> by web
> >> usage is contrary to SVG's status as a web spec.
> >>
> >> So, you seem to be suggesting that W3C and all the browser
> >> developers wouldn't be that bothered if the CAD and other non-web
> >> interest groups went off and forked SVG?
> >>
> >> Does it really matter if there are features in the SVG spec that
> >> are useful to CAD people and not web browsers?  Couldn't there be
> >> features marked as "Web Profile" and others marked as "CAD
> >> Profile", "DTP Profile" etc?
> >>
> >> Paul
> >>
> >>
> >> On 21 March 2015 at 03:30, Stephen Chenney <schenney@chromium.org>
> >> wrote:
> >>
> >>> There is a fundamental issue with the SVG community in that not
> >>> everyone agrees on why the standard exists.
> >>>
> >>> Right now the spec is managed under the W3C process which to me
> >>> implies primarily a web spec. That's where we are and complaining
> >>> about features being driven by web usage is contrary to SVG's
> >>> status as a web spec.
> >>>
> >>> On the other hand, the point about usage invisible to web
> >>> crawlers is well known on the Chrome team, at least, and it
> >>> matters for all users, not just those using web formats in other
> >>> domains. We do try to adjust and have processes in place to
> >>> obtain feedback on feature implementation and deprecation. Feel
> >>> free to make use of that.
> >>>
> >>> Stephen.
> >>>
> >>>
> >>> On Thu, Mar 19, 2015 at 4:42 PM, Smailus, Thomas O <
> >>> Thomas.O.Smailus@boeing.com> wrote:
> >>>
> >>>> Consider that not all SVG usage is in a ‘web’ space, even if
> >>>> the standard is under W3C.
> >>>>
> >>>>
> >>>>
> >>>> SVG is a graphic file type and used as a graphic in a host of
> >>>> ‘non web’ domains.  For example, as a possible replacement for
> >>>> other vector diagram formats in industrial/engineering domains
> >>>> – a large set of uses that would NOT be visible to web scans or
> >>>> even surveys.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Thomas
> >>>>
> >>>> --
> >>>>
> >>>> Thomas Smailus, Ph.D.  P.E.
> >>>>
> >>>> Boeing Information Technology
> >>>>
> >>>> thomas.o.smailus@boeing.com
> >>>>
> >>>>
> >>>>
> >>>> *From:* Jeremie Patonnier [mailto:jeremie.patonnier@gmail.com]
> >>>>
> >>>> Well, I'm not sure about that. SVG/SMIL beyond the lack of
> >>>> support into browsers as many drawbacks that makes it less
> >>>> appealing to web developers than CSS animation:
>
> I think some of this misses the point. There should be no need to have a
> special viewer, or a special kind of SVG, for CAD or print applications.
> Rather, it is a matter of persuading browser developers that there is
> a big enough use case for these requirements, even though they may not
> see much evidence out on the web right now. That in any case is line of
> an argument equivalent to suggesting that eggs would be unnecessary
> because one can see no omlet.
>
> To my mind, the question is, what better mechanism can be devised for
> proving a case to the browser developers? Should the W3C be proactive in
> ensuring better representation of the end user community on its working
> groups? Might it be better to allow a feature to proceed to
> recommendation with just one working example, allowing a more pioneering
> and receptive browser developer to lead the field, and not be
> constrained by the relative inertia of others?
>
> --
> Charles Lamont
>
>