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

On Feb 19, 2006, at 4:31 PM, Jon Ferraiolo wrote:

> 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.
Fine by me, as long as you have test cases that show the caret  
blinking twice in <use>d editable text, selection appearing twice for  
selectable text (and copying twice or not), video playing twice,  
audio playing twice. Note that I did not ask you to change the spec,  
just provide test cases for these particularly tricky situations to  
ensure they are in fact implemented as specified. Scenarios 2, 3, 6  
and 8 below are the ones that could apply to SVG by itself.
> Remember that foreignObject is meant for *extensions*, not for  
> standard features.
The distinction is not clear to me. Does that mean that UAs that  
support HTML+SVG directly should not allow HTML in foreignObject? I  
think that would mean all existing HTML+SVG UAs are not compliant.
> 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.
I don't think the CDF WG should be defining new elements in the SVG  
namespace. I also don't think there are any html-specific needs here.  
The stated semantics and behavior of foreignObject are just fine,  
other than issues like <use> which would apply just as much to a  
hypothetical htmlObject.
>  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.
That would be satisfactory. If you specify the scenarios where  
behavior is undefined, then there is no need to have test cases for  
those scenarios.

I don't think XBL has any of these issues, since multiple instances  
of the shadow tree will be created and there is no requirement to  
keep DOM or interation state in sync.

Regards,
Maciej

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