Improving SVG DOM: Modification request

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

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)

Using unions on attributes allows users to do feature support testing, rather then “versioning” checking. If new SVG DOM or old SVG DOM are not supported, the user gets an exception that he can handle easily.

Greetings,
Dirk

[1] http://www.w3.org/2013/11/14-svg-irc
[2] http://codepen.io/FWeinb/pen/djuIx

Received on Wednesday, 20 November 2013 15:56:59 UTC