W3C home > Mailing lists > Public > www-svg@w3.org > November 2013

Re: Improving SVG DOM: Modification request

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 20 Nov 2013 08:47:27 -0800
Message-ID: <CAAWBYDAyukMV9OPm+Uoj65FHaP-B+w2XpisDu7rU+qX7_MQ6-Q@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: SVG public list <www-svg@w3.org>
On Wed, Nov 20, 2013 at 7:56 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> Hi,
> Cameron wrote a great document with a proposal to improve the SVG DOM. You can find the document here: http://dev.w3.org/SVG/proposals/improving-svg-dom/
> To summarize: Cameron suggests that for every element in the SVG namespace, we create a second element in the HTML namespace (no namespace). The element in the SVG namespace would be preserved. Additions or changes just go to the new elements. The new elements on the other hand do not support the current SVG DOM as is but create a new SVG DOM that fits more into todays interface design concepts. Having two different elements allows easily to differ between the new concept of SVG DOM and the old concept of the SVG DOM. On the markup side, a new element called <graphics> would differ between the two SVG concepts. SVG markup would be nested in <graphics> instead of <svg>.
> I raised concerns to several parts of the proposal in the last F2F [1]:
> * It is unclear if and how one can mix SVG elements in different namespaces.
> * The proposal requires the implementation and specification to maintain not only two different SVG DOM concepts, but also two different elements (two for each original element)
> * It is recreating SVG with a clear breakage to the past. Content created according to the proposal is incompatible to todays SVG implementations. Not only JavaScript would not be processed, even the processing of the tags will fail.
> * A new, not yet existing, element <graphics> needs to be added in the HTML5 parser and in implementations.
> * It does not answer the question how SVG content can be added to HTML directly yet.
> I would like to suggest some modifications to the original proposal that makes it much more compatible to the current SVG DOM and backwards compatible to todays SVG implementations for the most part. Current implementations would not break on supporting basic functionality that is already in SVG today. Some of the modifications already exist as issues in the original proposal itself:
> * Remove SVG namespace. Elements or attributes explicitly created with SVG namespace will still end up with no namespace. Keep current object names (SVGNameElement)

Why not swap them into the HTML namespace like normal HTML elements?
This also makes things more compatible with simply reusing <style> and
<script>, which would be in the HTML namespace.

> * Remove elements <style>, <script> and reuse HTML tags. SVG specific attributes won’t be preserved.
> * Continue to differ between elements in an SVG context and in an HTML context with <svg> being the switch (as specified by HTML5 and done by browsers today). This still allows us easily to reduce the restriction later when we have a much more detailed proposal to mix them.

I don't understand this line.

> * Deprecate most of the SVG DOM interfaces
>      * Incrementally remove / replace interfaces as possible / as reasonable
>      * use unions to give some attributes a new meaning for an potentially new SVG DOM

We need to track usage of all the SVG DOM interfaces ASAP, so we can
kill off everything that's not necessary.

> * Transform x, y, width, height, rx, ry, r, cx, cy, viewbox into presentation attributes, as already done for transform, patternTransform, gradientTransform
>      * All attributes are SINGLE value properties defaulting to auto. It is less likely that <length-list>s will be accepted by authors or implementations… the biggest flaw of the proposal in the past.
>      * Reuse CSSOM instead of creating yet another way to access variable definitions
>      * Deprecate (but still make mandatory) x, y, rx, ry attributes on <text> in favor for multiple <tspan>'s and CSS transforms, or introduce :nth-letter [2] to address each single glyph individually. The attributes on <text> would NOT be presentation attributes.

No, you need x/y on <text>, as it works with text-anchor.  They should
be presentation attributes along with x/y on everything else.  I'm
fine with killing (but requiring support for) dx/dy in favor of

> Not necessarily related to the proposal:
> * Use HTML parser rules for standalone SVG documents as well (xlink definition not needed anymore, just <svg> at the root... XML style would still work)


Received on Wednesday, 20 November 2013 16:48:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:47 UTC