Re: new feature request

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

Received on Saturday, 21 March 2015 00:51:51 UTC