search

w3c / svgwg

SVG Working Group specifications
Other
707 stars 133 forks source link

[svg-native] inner svg, symbol or use elements supported? #671

Open dirkschulze opened 5 years ago

dirkschulze commented 5 years ago

SVG OT does not support the <symbol> element and I believe that it is a good choice.

<symbol> creates a new SVG viewport which adds a huge amount of complexity. We should not support it.

Same applies to inner <svg> element. It should be ignored in SVG Native.

The correct implementation of the <use> element is essential otherwise it adds a security threat to implementations. Implementations must detect cyclic dependencies, not only between elements but between CSS properties that reference elements (like clip-path) as well. Authoring tools use <use> primarily in combination with <symbol>. If we do not support the one we might consider not using the other. (Though there of course is hand crafted SVG content as well... it is just negligible in comparison to the masses of generated SVGs.) I am fine if we move the discussion about <use> to another issue if it is controversial.

svgeesus commented 5 years ago

Seems okay for not supporting inner svg, and symbol.

I'm not sure about not supporting use.

litherum commented 5 years ago

which adds a huge amount of complexity

Just for background information, can you describe the complexity?

dirkschulze commented 5 years ago

For one there is the issue with the forward declaration. Either you scan the document up-front for id attributes to have an ID - XML element map or you add a placeholder and revisit use later but need to keeps its "rendering tree" in memory.

Then there is the general "as if the use gets replaced by a group and a copy of the referenced element added as child of that group"-behavior which requires the same referenced element to be part of different document sub-trees. So you can not resolve the style of that element on its first appearance. As a matter of fact, any element that has an id is a potentially referenced element and the style inheritance tree ("render tree") changes when it gets referenced.

A use-element referenced element can have a clipping path (CSS property) that clipping path (element) may have a child which references our use element. So the cycle detection code does not simply need to check the element referencing (use-element directly or indirectly via more use-elements references itself) but also needs to check the resolved style. IMO that is a major hold up on implementing <use> since that would cause an stack overflow.