Re: Proposal: Nesting SVG Graphics Elements

I love this discussion (^_^)


2012/12/3 Dirk Schulze <dschulze@adobe.com>
>
> This sounds rather like the use case of transform-origin


You're right, I miss this.


> But IIRC you are not just changing the point of origin, but really
> translate the group in the current coordinate system.


Yes that why I propose to truly change the point of origine change but
visually speaking there shouldn't be any difference.


> I don't see why you would need to avoid the transform showing up in the
> transform list? What is the problem of the transformation list?


Just to avoid unnecessary complexity in the author point of view. The
proposal is is not a transformation therefor it shouldn't appear in the
list of transformations.


> At least we have a SVG DOM API that let you traverse the transform list
> (which is not the case for CSS3 Transforms).
>

Aaaah! This is typically a developer point of view (no offense, it's a
perfectly valid point of view). I totaly agree that the SVG DOM API is fare
more advanced than the CSS OM API in that case. However, if we are talking
about giving more flexibility to authors at the declarative level, using
DOM imply to use JavaScript therefor you are in an imperative mode. At a
declarative level, reseting nested transformation is something very
difficult because you have to perform all the computation by hand (more
precisely, you spend a crazy amount of time trying and failing). This is
another reason why authors do not use transform that often. Transform are a
mathematical tools that really suits imperative language, but in
the declarative world, it's really, really hard to hand edit something more
complexe than a translation and a rotation (and the combination of the two
can give serious headache to countless web dev).


> You brought up assumptions of HTML+CSS authors.
>

Ok, fare enough, sorry about that.


> However, we should not be stock on the knowledge of web developers today.
> If they don't understand transforms today, they will need to understand it
> tomorrow.
>

I disagree about this. If an author do not understand transform today, he
will not use it tomorrow. He will use instead JavaScript polyfills that
make his life easier and this will sign the death of SVG in favor of Canvas
because the guys that understand imperative languages feel better with the
Canvas API rather than with the SVG DOM API.


> Transforms are a fundamental part of SVG and will get it in HTML as well.
> If you want to write SVG code manually, you will catch up very fast on it.
>

I agree, it's no big deal but my point is that Web Dev have a crazy amount
of knowledge to learn. Among many French web dev I know I'm some sort of
an extraterrestrial, because I know HTML, CSS, SVG and JavaScript with
exactly the same level of expertise and it takes me a lot of time to
maintain that expertise. And for what is worth I see that not everybody is
okay to do it even high skilled professional. So everything that make the
life of author easier is always a good idea. If you have an idea for a
crazy simple API that cover 80% of the known use cases but fail on the 20%
remaning, Nevermind, you have a great API. That's what make CSS Transition
so successful where SMILE Animation just miss the point.


> dx and dy are very easy to implement, but the reason to support them seem
> to be wrong.
>

I do not pretend to be right. But finding something that will be easy for
author to position elements in a relative way from one to another is
definitely something that will help the adoption of SVG. Even if I'm not
comfortable with Doug's proposal (I found it to complexe because it's not
as intuitive as it looks) I strongly agree with the reason that lead him to
his proposal. Upgrading the positioning model of SVG by introducing a
simple way to bind the position of several elements to others element with
a simple declarative API that get rid of transformation will be a
great improvement for SVG.

Best,
-- 
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>