Re: New SVG WG Charter (was: [Bug 29809] Accessing the offset of inner SVG elements)

Hi Doug,


Thank you for replying so quickly. However, in the premise of my post “A
few thoughts and questions” suggests an invitation to reflection for future
direction. The thoughts and questions remain written, for consideration.


Three clarifications.

> Minor correction: between SVG 1.1 and SVG 2, there have been 2 other

> major updates to SVG:

The timespan between SVG 1.1 and SVG 2 is about fifteen years indeed. By
that I mean that 1.1 was not fully implemented, not that the WG didn’t do
anything during that time! The strategic choices and priorities were
already questioned at intervals during that period.

> HTML+CSS has always been more widely used than SVG, so these features

> are now seeing more use and developer/designer demand. This has led to

> them getting more emphasis and optimization by the browser makers, not

> only for use in HTML and CSS, but in SVG as well.

The fact that the W3C, like any institution, is also submitted to the laws
of corporatism (more than developer\designer demand), is a truth. The
question is then where is the tolerance limit. The category of developers
or designers involved in what I called the all-advertising web, fatally
includes a number of amateur or occasional developers. Then it seems you
are implying the W3C should favor that category, in a trend following
manner, because of the corporate agents’ supposed audience target and
demands,  to the detriment of other categories of developers, those
involved with institutions, academy, technical, etc., the ones that have
the most use of SVG. If this is true, as it seems to be, then this
governing body is being partisan.


>> A further positive step would be an information campaign to disprove the

>> doctrinal belief that an SVG application be better off within an

>> html/canvas environment. It is very precisely the opposite. I will be

>> happy to support this argument with irrefutable hard proof if this

>> statement raises doubts.



> Personally, I think SVG is more powerful and useful when it's combined

> with other features of the Web Platform, like HTML, CSS, JavaScript, and

> at times even Canvas. But I respect your opinion that standalone SVG is

> powerful enough on its own.



Here with application I refer to programs of the desktop type (not to app
in its current meaning). Applications are necessarily written with a
programming language (JavaScript here), and that is independent of which
virtual device interface is used for rendering. An application of that type
cannot be written with HTML+CSS, or Canvas, or SVG, whether alone or in
combination. In any case my point was not about if an SVG application is
“more powerful when it's combined with other features of the Web Platform”,
it was about “the doctrinal belief that an SVG application be better off
within an html/canvas environment”, the thing for which I advocate an
information campaign (as opposing to the misinformation campaign that went
on for a long while).




Now I would like you to please consider the following points and then reply
to the last question.


The rumors circulating a few years ago that SVG was bound to become first a
subset of HTML, and subsequently eventually replaced by CSS, proved well
founded for the first part, and therefore could prove well founded for the
second part, as well.


This situation is not very different from the one that we experienced with
ASV. Companies and developers felt a level of anxiety in having to decide
whether to invest in SVG or not, while Adobe entertained doubts for a few
years in keeping an obscure position.


Seeing the results of SVG maintenance, what was added or removed from the
specification, it’s demotion to an inferior rank, and what has been added
to CSS, all this seems to point in one direction.


A project was started of a 3D editor using JavaScript and pure SVG,
straight no chaser. It’s a huge endeavor requiring commitment. We need to
know if it’s a sensible commitment.


Here is the fundamental question:


Are you able, as an official spokesperson, to confirm that after its
demotion the removal of SVG is not in the W3C agenda?


Not meaning to put pressure on you in particular, a clear answer is welcome
from any official.


Thanks.

Domenico

On Mon, Oct 17, 2016 at 7:22 PM, Doug Schepers <schepers@w3.org> wrote:

> Hi, Domenico–
>
> Thanks for the opportunity to further clarify…
>
> On 10/17/16 12:06 PM, Domenico Strazzullo wrote:
>
>>
>> Premise:
>> A few thoughts and questions. Even though some may not correspond to
>> what anyone would like to hear, I keep the right of expressing them,
>> while not seeking a confrontation or dispute. My goal is to try to give
>> a contribution for the adoption of a valid strategy for the future of SVG.
>>
>> In the charter history I can see that deliverables for the FX Task
>> Force-CSS were attributed to the SVG WG from March 2012 to October 2016,
>> and that they are removed for the coming year. How was SVG the
>> beneficiary of the efforts made towards CSS?
>>
>
> I'm not sure I understand the question, but I'll attempt an answer.
>
> SVG introduced several features that were not necessarily specific to
> vector graphics, including transforms, filter effects, masking, compositing
> and blending, animation, and geometry interfaces.
>
> Because these features had value outside SVG, including application to
> HTML or raster images, they were factored out of SVG for shared use with
> CSS.
>
> HTML+CSS has always been more widely used than SVG, so these features are
> now seeing more use and developer/designer demand. This has led to them
> getting more emphasis and optimization by the browser makers, not only for
> use in HTML and CSS, but in SVG as well.
>
> So, because they have been factored out of SVG, SVG benefits from their
> improved performance and interoperability.
>
> In terms of standards, this also means that these features can progress
> independently of a monolithic specification, and updated more frequently
> (theoretically… it also comes down to active participation), without
> slowing down the development of other features. Review of modular
> specifications is also easier for developers and implementers, and also the
> WGs. This model has been used by the CSS WG to great effect, and it's the
> model the SVG WG would like to follow.
>
> These specs are now going to be worked on by the CSS WG alone.
>
>
> If I consider the time elapsed between the finalized SVG 1.1
>> specification and the status of candidate recommendation of SVG 2 (about
>> fifteen years),
>>
>
> Minor correction: between SVG 1.1 and SVG 2, there have been 2 other major
> updates to SVG:
>
> * SVG 1.2 Tiny (December 2008): a lot of work went into this mobile
> version of SVG; unfortunately, the mobile landscape (both hardware and
> business models) changed in the meantime, and SVG 1.2 Tiny was never
> adopted as widely as hoped; however, most of the work was reused for later
> version of SVG;
>
> * SVG 1.1 2nd Edition (August 2011): this sounds like a minor release, but
> it wasn't (this is probably a failure of "branding" and communication on
> our part); it doesn't introduce new features, but it greatly improves SVG
> in terms of interoperability and even performance, in much the same way CSS
> 2.1 improved CSS.
>
> There were also many modular specifications that were also created and
> implemented in parallel (see the CSS-SVG TF specs).
>
>
> I question myself on: what were the goals; whether and
>> when they were achieved; whether the mission was fulfilled, partially or
>> completely, and if partially, what parts in the mission statement
>> benefited principally.
>>
>> If I make an assessment (subjective interpretation) of what was done,
>> based on what I have seen, I note that a considerable effort was
>> consecrated to CSS in the last few years, with concrete results. If I
>> compare with the achievements in the SVG domain, the work on CSS seems
>> to have attracted more attention and results, including from the
>> implementers’ side.
>>
>
> Agreed.
>
>
> I do know that this situation (subjective interpretation) results from a
>> strategic choice. The intention (I think) was to make a set of
>> sophisticated tools available to the greatest number of developers,
>> targeting a rich web. The rich web, as we can witness now, is primarily
>> the all-advertising web. But no objection to that (who could object
>> anyway).
>>
>> But just like any good coin, the web has at least two faces, one other
>> face being its vocation of platform for fully portable applications. SVG
>> serves this purpose, among a variety of other interesting uses. SVG was
>> also the legitimate replacement for Flash, and more than that. SVG is
>> monumental, already in its 1.1 declination. Unfortunately it seems it
>> had to remain relegated (subjective interpretation) for a long period to
>> be the dark side of the moon, when instead it’s a planet in its own
>> right. What would motivate the perseverance of this choice? I see with
>> pleasure then that the FX Task Force was closed.
>>
>
> Actually, it's not yet technically closed. But pragmatically, most of the
> work has been done by the CSS WG in recent years anyway.
>
>
> Are we sure that
>> everyone among the members/invited experts/participants is aware, and
>> earnestly committed to the new charter? For example some who notoriously
>> suffer from the CSS Dependency Syndrome.
>>
>
> We are currently in the process of making sure everyone is informed.
> That's what we've been doing in recent announcements on this mailing list
>
>
> At this stage, in my opinion, there are only two choices: either sustain
>> the efforts for SVG to progress properly, unconditionally, or let it
>> stagnate until it will eventually fade out.
>>
>
> I see a 3 option: focus specifically on features and improvements that
> incrementally improve SVG, which have commitments from implementers. That's
> not unconditional, and I think it's the most pragmatic path forward.
>
>
> Referring to your intention expressed in this post
>> https://lists.w3.org/Archives/Public/www-svg/2016Oct/0023.html, I
>> sincerely hope that “most likely” will become a reality as soon as
>> possible.
>>
>>
>> Regarding your statement:
>>
>> “At some future point, we might consider closing the SVG WG and
>> replacing it with a Graphics WG. That future point might be 6 months, a
>> year, several years, or never.”
>>
>> I think that’s utopic. Crossing the domains of competences (in its
>> negative connotation) is inevitable in those scenarios. It is like birds
>> from different species laying eggs in the same nest. I think that for
>> SVG it’s no time for such radical structural experiments, for the time
>> being. Besides, even if you concentrate things you will still need
>> specific units; more of a formal change than a substantial one. It could
>> generate confusion and that is not what we need.
>>
>
> Okay, I can see your perspective. At this point, I no longer think a
> Graphics WG is likely to form.
>
>
> I would expect the leaders of this group to assume their
>> responsibilities for the actual state of things, whatever that state may
>> be objectively. A simple gesture, since we’re not talking a criminal
>> case either! And from there, your directional choices could take into
>> account some wise advice that was regularly proposed. I would suggest
>> sticking to realistic and pragmatic choices to achieve short term
>> reparation goals (motivate the agents for full implementation of 1.1
>> above all), rather than brainstorming. Assuming of course that all the
>> concerned parties (including developers) truly share the same agenda,
>> otherwise forget it.
>>
>> But maybe your recent post cited above is a proof that this is already
>> happening?
>>
>
> Yes, that's what we're working on.
>
>
> Regarding your statement:
>>
>> “ … Graphics WG that would help unify or normalize features between SVG
>> and Canvas”
>>
>> I think that if canvas needs to be normalized, the people in charge can
>> just do that if they need. When it was created they didn’t seem to care
>> much for what SVG stood for. I’m sure that it makes more sense to have
>> the SVG WG focus their attention solely on its maintenance and
>> development. But then again, admitting that is what is truly wanted. At
>> this stage anything else would continue to be a dispersion, I’m afraid,
>> and the current state of things is a proof of that.
>>
>>
>> Same closing remark here as above.
>>
>> I also think what Amelia proposes in her replies makes sense, and that
>> steps could be taken in that direction. I read complaints on the status
>> and level of participation by the different participants, and the time
>> constraints, in this group.
>>
>> About the current status of the SVG implementations.
>>
>> It was said (publicly and privately) by quite a few in the past and as
>> recently as a few days ago on this list “why bother about SVG 2 (or 1.2)
>> when SVG 1.1 is not yet fully implemented” or something of the kind.
>> Maybe the agents need to be motivated for terminating their task with
>> more diligence. I suppose they are probably overwhelmed with all the
>> proposals/recommendations/brainstorming from different technologies
>> –some of which not being under direct control of the W3C– and
>> considering that some cool enhancements (once again, targeting
>> particular niches of developers) become probably a must, they find
>> themselves involved in a make or break race. Of course at some point it
>> becomes insane if there is even only some level of anarchy. There is
>> certainly not a magic wand for this. I think that only a big effort of
>> coordination (vs dispersion) can eventually lead to a complete SVG
>> implementation.
>>
>
> The current plan is to push for a complete SVG implementation by removing
> features from SVG that haven't got ubiquitous support. This is a hard
> choice, because it removes features that I love like SMIL Animation and SVG
> Fonts, but it's the only path we see to an interoperable SVG that can be
> used reliably in all browsers and authoring tools.
>
> Any new features that aren't already implemented (or in the implementation
> pipeline) will be developed as modules for incremental development and
> implementation in their own time.
>
>
>
> About the list of constituents in the Scope section of the charter draft.
>>
>> Third item regarding the style properties. The capability of expressing
>> presentation attributes through the style attribute has always been a
>> grammatical feature, its official purpose being that of offering a
>> syntax alternative as an incentive. The question of compatibility with
>> CSS remains dependent of the fact that a given attribute is or is not in
>> the SVG grammar. If and when a new presentation attribute needs to be
>> created, it remains implied that it can be expressed through the style
>> attribute, since that is a prerogative. What really counts then is
>> whether the parser identifies an attribute as pertinent or not, not
>> whether an attribute, in its essence, is compatible with CSS. Similarly,
>> if a new SVG-specific presentation attribute is needed and implemented,
>> the parser will validate it whether expressed as style property or
>> presentation attribute. I hope everyone agrees that the dual expression
>> capability is only formal. It is not the parser that checks for
>> consistency with CSS; that condition is necessarily a prerequisite set
>> by the governing body upstream. We then have three distinct cases:
>>
>>
>> 1) The new SVG-specific attribute feature is not compatible in its
>> essence with CSS (as relating to some HTML element). Result: it will
>> live with its non-compatibility with CSS, while it can still be
>> expressed through the style attribute, because it’s a grammar
>> prerequisite, and because either way the parser will formally validate it.
>>
>> 2) The new SVG-specific attribute feature is compatible in its essence
>> with CSS. Result: it can be ported to CSS at discretion by the CSS WG.
>> The SVG WG can consult other groups about the naming of the attribute
>> (not an issue).
>>
>> 3) Some CSS specific property needs to be ported to SVG. Result: just do
>> it. The name may need to be accommodated to be expressed as presentation
>> attribute (hyphen vs camelCase or whatever).
>>
>> Finally on this subject, I contest the wording. It should read: “A set
>> of presentation attributes, compatible with CSS, and expressible as
>> style properties, …” even though under the hood the parser may check for
>> style first.
>>
>> But this is already detailed in the specification, and therefore should
>> have no place in the charter’s scope. Apart from the redundancy, it
>> suggests some need to make a case, still.
>>
>
> If you have a concrete suggestion for revised wording in the charter, I'm
> open to it. A WG charter isn't meant to be interpreted with legal precision
> (except for the case of scoping of Intellectual Property contributions);
> it's only suggestive of what the group intends to work on, and the WG
> ultimately decides what it will do and how it will do it.
>
>
> Please see how the CSS priority and its omnipresence produced cascading
>> consequences, not the least of which that of causing the agents to give
>> priority to CSS effects implementation. See how it was a hindrance for
>> the completion of implementation and for adequate development of SVG.
>> Please reorganize the group to keep or appoint only persons who have a
>> truly scholarly and unbiased approach, with the sole mission of
>> maintaining SVG. If we really care about keeping SVG, that is the way to
>> go.
>>
>
> I'm not sure I agree with all of the premise. The SVG-CSS modules were
> both good and bad for SVG. They got emphasis on certain features that was
> good, but arguably drew attention away from the core of SVG. In either
> case, though, I think modularizing these features was inevitable.
>
> Our current goal in reorganizing the group is to focus on what we think we
> can finalize in implementations in the next year, based on the
> feature-complete SVG 2 Candidate Recommendation draft.
>
>   https://www.w3.org/TR/2016/CR-SVG2-20160915/
>
>
> A further positive step would be an information campaign to disprove the
>> doctrinal belief that an SVG application be better off within an
>> html/canvas environment. It is very precisely the opposite. I will be
>> happy to support this argument with irrefutable hard proof if this
>> statement raises doubts.
>>
>
> Personally, I think SVG is more powerful and useful when it's combined
> with other features of the Web Platform, like HTML, CSS, JavaScript, and at
> times even Canvas. But I respect your opinion that standalone SVG is
> powerful enough on its own.
>
>
> Finally, I read in your note “it was interesting for me to took back on
>> the group's efforts through the years, and see priorities change… and
>> makes me want to be better about finishing things more quickly!”
>>
>> Maybe priorities that have the bad habit of changing were not priorities
>> :)
>>
>
> Maybe. The world has a way of changing around us, though, and I think we
> need to adapt to that.
>
> Regards–
> Doug
>
>
> Domenico
>>
>>
>> Hi, Amelia–
>>>
>>> You know this already, from the SVG WG telcons, but I thought I'd expand
>>> on it here.
>>>
>>> This charter is a short-term (1 year rather than 2 year) "extension" to
>>> let us focus on finishing SVG 2.
>>>
>>> At some future point, we might consider closing the SVG WG and replacing
>>> it with a Graphics WG. That future point might be 6 months, a year,
>>> several years, or never.
>>>
>>> Personally, I like the idea of a Graphics WG that would help unify or
>>> normalize features between SVG and Canvas, including perhaps a single
>>> shared Web Graphics API, but that's not the intended scope of this
>>> particular charter.
>>>
>>> Regards–
>>> Doug
>>>
>>
>> On 9/13/16 12:45 PM, Amelia Bellamy-Royds wrote:
>>
>>> *SVG Working Group versus Graphics Working Group ?
>>> *
>>>
>>> Re Doug's draft charter for the SVG WG 2016/2017. [1]
>>>
>>> One area to discuss on the charter is whether it makes sense to expand
>>> the group's responsibility beyond SVG markup.
>>>
>>> When the HTML WG re-organized into the Web Platform WG, the Canvas 2D
>>> API was left without an W3C host.  I don't think work is terribly active
>>> at WHATWG, either (although their spec is still much more up-to-date).
>>> Last July, the SVG WG was asked if they'd take over responsibility.  The
>>> request was turned down at that time, partly because we didn't want to
>>> distract from SVG 2, but partly also because there wasn't room in the
>>> SVG charter for non-markup-based graphics specifications. [2]
>>>
>>> I would love to see better coordination between SVG and canvas.  Authors
>>> and user agents both benefit if rendering details are consistent between
>>> the two syntaxes.  The accessibility work would also benefit from
>>> greater coordination.  But it depends on whether there will actually be
>>> people & organizations able to devote resources to the work.
>>>
>>> Of course, since this charter extension is only for 1 year, any decision
>>> now is not final.  But I thought I would bring it up so that people who
>>> will be at TPAC can discuss with colleagues there.
>>>
>>> [1]: https://w3c.github.io/charter-drafts/svg-2016.html
>>> <https://w3c.github.io/charter-drafts/svg-2016.html>
>>> [2]: https://www.w3.org/2015/07/16-svg-minutes.html#item01
>>>
>>>
>>>
>>
>> On Sun, Oct 16, 2016 at 11:34 PM, <bugzilla@jessica.w3.org
>> <mailto:bugzilla@jessica.w3.org>> wrote:
>>
>>     https://www.w3.org/Bugs/Public/show_bug.cgi?id=29809
>>     <https://www.w3.org/Bugs/Public/show_bug.cgi?id=29809>
>>
>>     --- Comment #11 from Robert Longson <longsonr@gmail.com
>>     <mailto:longsonr@gmail.com>> ---
>>     The fill CSS property does not apply to line elements, try modifying
>> the
>>     stroke.
>>
>>     And yes you can select individual elements with CSS selectors.
>>
>>     I don't see any bug here. You'd probably be better off asking this
>>     kind of
>>     question on some other forum e.g. stackoverflow
>>
>>     --
>>     You are receiving this mail because:
>>     You are the QA Contact for the bug.
>>
>>
>>