RE: SVGT 1.2: <use> and <foreignObject>

Maciej

I described behavior for foreign objects in the context of svg:use which
is consistent with how SVG treats non-foreign (i.e., SVG) objects. We
can't change the processing model for svg:use for cases when it
references SVG objects. This is behavior which has been specified since
SVG 1.0, in included in SVG Tiny 1.1, and is supported in commercial
implementations.

 

Remember that foreignObject is meant for *extensions*, not for standard
features. If CDF/WICD needs to define a standard way to integrate HTML
and SVG and hope to achieve interoperability across multiple
implementations, don't do it via foreignObject. To allow a future
version of CDF/WICD to have SVG reference XHTML, perhaps the CDF WG
needs to define an "svg:htmlObject" or something like that.

 

Regarding the complexities of svg:use with non-SVG content, based on
your list below, it sounds as if we need to include a warning in the SVG
spec about attempting to have an svg:use reference a subtree which
includes any svg:foreignObject elements (or when XBL kicks in, a shadow
tree with svg:foreignObject), saying that some of the processing model
for svg:use might not be possible, such as when an svg:foreignObject
references a browser plugin or native controls.

 

Jon

________________________________

From: Maciej Stachowiak [mailto:mjs@apple.com] 
Sent: Sunday, February 19, 2006 3:45 PM
To: Jon Ferraiolo
Cc: Eric Seidel; www-svg@w3.org
Subject: Re: SVGT 1.2: <use> and <foreignObject>

 

 

On Feb 19, 2006, at 3:00 PM, Jon Ferraiolo wrote:





Hi Eric,

This email is the official Last Call response to your comment at:

   http://lists.w3.org/Archives/Public/www-svg/2005Dec/0307.html

which is repeated at the bottom of this email.

 

The processing model for svg:use is such that, when multiple svg:use
elements reference the same original element, all of the svg:use
instances reflect the state of the original object. Here is the quote
from the spec (http://www.w3.org/TR/SVGMobile12/struct.html#UseElement):

 

Hi Jon,

 

I can't speak for whether Eric is satisfied, but I think the model you
propose means that <svg:use> on an <svg:foreignObject> that contains
(X)HTML elements is not implementable for some types of content, and for
others has bizzarre effects that violate expected code and UI
invariants:

 

1) If the HTML contains plugins (e.g. via Flash or QuickTime content in
<html:object>), you cannot get the same plugin instance to draw in two
different places. Nor can you keep two different instances of the same
plugin in sync - they run independenly and do not expose their state in
the UA. So <svg:use> on <svg:foreignObject><html:object ...></...></...>
is not implementable as specified.

 

2) The above may also apply to <video> depending on how it is
implemented - it would at the very least preclude using a plugin-style
approach for <video>.

 

3) If used with <audio>, should the audio play twice or once?

 

4) If the HTML contains a <select size=1> control, and the user pops up
the menu, this would apparently require the menu to pop up in two
different places, and each would have to track as if responding to mouse
movements in the other. This is not implementable for any UA that uses
native system menus, and would require putting a lot of svg-specific
code in the html <select> implementation for those that don't.

 

5) If the HTML contains any text input control, and one is given focus,
the caret would have to blink in two different places. This would
violate the invariant that the caret blinks in one and only one visible
location.

 

6) If the foreignObject contains any editable HTML, or for that matter
if the <use>d element contains an editable SVG <text> or <textArea>
element, the caret must blink in two different places on the screen.
This violates what had previously been an invariant, as above.

 

7) If the foreignObject contains a focusable HTML element and the UA
draws a focus ring, then the focus ring would have to appear in two
different places onscreen. This violates the invariant that the focus
ring must appear in one and only one place.

 

8) If the foreignObject contains selectable text (either HTML or SVG),
and the user selects some, the selection would have to be drawn in two
different places. This violates the invariant that there is one text
selection per document, and it is not obvious what should happen on
copy/paste. Should the text copy once, or twice?

 

9) If the foreignObject contains a simple tracking control, such as a
button, then the button would have to appear depressed in two places
when the user clicks one, and furthermore, dragging from one to the
other with the mouse down will still click the button. (Or will it? I
can't really tell if this is implied by sharing interaction state).

 

Is it really the SVG WG's intent to impose all of these requirements on
HTML+SVG UAs? If the WG proceeds to CR with these requirements, I
request the following:

 

A) Mark the features corresponding to scenarios 1-9 as "at risk" in the
CR.

B) Cover all of scenarios 1-9 in the test suite.

C) Drop the corresponding features for any where there are not at least
two UAs that both pass the test.

 

This is the bare minimum needed to ensure these inplicit requirements
are well-specified and feasible to implement. You may also wish to make
a similar list for XForms. 

 

Regards,

Maciej