Re: Improving SVG DOM: Modification request

On Nov 20, 2013, at 5:47 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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

Are you mixing up object names and namespace here? Using the HTML namespace is exactly what Cameron and I suggested. We just shouldn’t change the object names IMO. First, it doesn’t buy anyone anything to do a s/HTML/SVG/g. Second, if we would do it, we have the problems of SVGImageElement which suddenly already exists with HTML prefix. Third, it doesn’t buy anyone anything :) The same namespace is the important part.

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

You can still mix up elements as you wish and as you can do today. They just don’t get rendered, also as done today. The HTML parser doesn’t need to change just for SVG2. It could though if we have a sane model how to render SVG elements as child of arbitrary HTML elements and the other way around: <div><g></g></div> - <g><div></div></g>. That is something we can do for the next level or even independent of SVG. (Parser changes must be done by the HTML WG. I am sure they have other things to do ATM.) 

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

Yes, that would be extremely helpful. I talked with Philip Rogers on Blink, but it seems more difficult to get accurate data then I initially thought it would. It needs more investigation.

> 
>> * 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
> <tspan>s.

x, y as positioning without lists is fine for me and would still work. x, y as attributes would mean something different. That is what I am saying with not turning them to presentation attributes. Like for <canvas> where width and height attributes mean something different then the properties.

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

Greetings,
Dirk

> 
> ~TJ

Received on Friday, 22 November 2013 19:08:16 UTC