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