Re: [Bug 29809] Accessing the offset of inner SVG elements

Hi Doug,

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?

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

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

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.

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.

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?

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.


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.

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.

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.

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 :)

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> wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29809
>
> --- Comment #11 from Robert Longson <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.
>