Re: new feature request

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]
>>> *Sent:* Monday, March 16, 2015 3:40
>>> *To:* ddailey
>>> *Cc:* Tab Atkins Jr.; Philip Rogers; Dirk Schulze; Smailus, Thomas O;
>>> Boris Zbarsky; www-svg
>>> *Subject:* Re: new feature request
>>>
>>>
>>>
>>> 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:
>>>
>>>
>>>
>>
>>
>