Implementing <use> without cloning

[Robert O'Callahan-3]

Fully implementing <use> without cloning content nodes or "render objects" seems rather difficult. Consider this testcase:

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:html="http://www.w3.org/1999/xhtml">
  <defs>
    <g id="f" style="display:inherit">
      <foreignObject width="100" height="80" style="display:inherit">
        <html:span style="display:inherit">Hello</html:span>
        <html:span style="display:inherit">Kitty</html:span>
      </foreignObject>
    </g>
  </defs>
  <use x="100" y="100" xlink:href="#f" style="display:block"/>
  <use x="100" y="200" xlink:href="#f" style="display:inline"/>
  <use x="100" y="300" xlink:href="#f" style="display:table-cell"/>
</svg>

For those of you not familiar with CSS, the correct rendering looks like this:
  Hello
  Kitty

  Hello Kitty

  HelloKitty

The first <use> styles the spans as blocks, so they are placed on separate lines. The second <use> styles the spans as inline elements, so they are placed on the same line and the whitespace between them is converted to a space. The third <use> styles the spans as table cells, and since they're only separated by whitespace they are placed in the same anonymous table row and the whitespace is discarded.

Firefox 3 and later display the correct rendering. Opera 10 displays the first and third <use> as if the spans were inline. Safari 4 displays nothing. I'd be interested to know whether any other UAs pass this test, especially ones that claim to implement <use> without cloning.

This testcase is hard because it requires more than just re-resolving style while painting. The different <use> instances actually need different CSS boxes created for them. You really don't want to be creating CSS boxes on the fly while painting ... at least, I don't. (In principle one could create separate CSS box trees for each <use> instance without cloning content nodes, but supporting multiple independent box trees for each content node is a large (potentially very large) increase in complexity, and cloning the content nodes is probably less expensive than creating the box trees, so this approach would add a lot of complexity for little gain.)

If the spec is going to allow implementing <use> without cloning, which I think is desirable, then how should the behaviour of this testcase be altered? One option is to simply say that <foreignObject> in <use> instances renders nothing. Another option is to say that the children of <foreignObject> in a <use> instance are given the style of the original nodes (which I think guarantees that the original CSS box tree can be used in every instance).

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Dr. Olaf Hoffmann]

Another interesting question is, what is expected,
if the display property of a use is animated -
does this mean, that the appearence of the
embedded XHTML changes?
Because XHTML and CSS themselves do not really define,
what is animatable or not, SMIL animation is not directly
applicable for XHTML+CSS (apart from the specific
XHTML+SMIL note from the SMIL group), however if an
animated property is inherited, the animation takes place
in the well defined SVG environment.
As far as I can remember, for example Opera did or does
something like a raster image of the XHTML fragment - could
be difficult to apply animated properties to such an image
as it is difficult to use forms and similar interactive content
from XHTML pretty relevant for SVG authors - even
more than inherited, animated styling, because the functionality
is not available in SVG at all in contrast to the presentation
of simple text like 'Hello Kitty' ;o)

Note, that the appearence of the XHTML fragment may
change as well, if width and height of the foreignObject
are changed with animation, therefore to get
something useful, maybe one has to clone these things
anyway separately for any use reference.


Olaf

[Alex Danilo]

Hello Olaf,

--Original Message--:
>Another interesting question is, what is expected,
>if the display property of a use is animated -
>does this mean, that the appearence of the
>embedded XHTML changes?

Yes.

>Because XHTML and CSS themselves do not really define,
>what is animatable or not, SMIL animation is not directly
>applicable for XHTML+CSS (apart from the specific
>XHTML+SMIL note from the SMIL group), however if an
>animated property is inherited, the animation takes place
>in the well defined SVG environment.

Correct.

>As far as I can remember, for example Opera did or does
>something like a raster image of the XHTML fragment - could
>be difficult to apply animated properties to such an image
>as it is difficult to use forms and similar interactive content
>from XHTML pretty relevant for SVG authors - even
>more than inherited, animated styling, because the functionality
>is not available in SVG at all in contrast to the presentation
>of simple text like 'Hello Kitty' ;o)
>
>Note, that the appearence of the XHTML fragment may
>change as well, if width and height of the foreignObject
>are changed with animation, therefore to get
>something useful, maybe one has to clone these things
>anyway separately for any use reference.

Semantically, cloning is the model. However, the choice whether
to actually clone is an implementation decision. It's still
possible to optimize using a raster as long as it's invalidated
in the presence of an active animation and the result is correct.

The method by which acceptable performance is achieved is an
implementation detail.

Alex

>Olaf
>
>
>