- From: Eric Seidel <eseidel@apple.com>
- Date: Mon, 20 Feb 2006 18:39:02 -0800
- To: Jon Ferraiolo <jonf@adobe.com>
- Cc: www-svg@w3.org
- Message-Id: <8D4B8DCE-D3FF-4529-84C8-B7C38B2E3FF6@apple.com>
As Maciej points out, this synchronization is not possible in certain cases such as plugin content inside an <html:object> tag in a <foreignObject> tag. Given that, the spec should add a line about the behavior of <use> referencing a <foreignObject> tag as being undefined. The current response is unsatisfactory w/o additional prose to cover the <foreignObject> case. Maciej raised a second (related) issue in his responses about what the proper behavior should be for <use> referencing a <video> or <audio> element. Thanks for your time. -eric 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): > > > > ---------------- > > The deeply-cloned tree, also refered to as the shadow tree, is then > kept in synchronization with the contents of the referenced > element, so that any animation or DOM manipulation occurring on the > referenced element are also applied to the 'use' element's deeply- > cloned tree. > > ---------------- > > > > If the referenced element is an svg:foreignObject or contains an > svg:foreignObject as a subelement or within an XBL shadow tree, and > the svg:foreignObject somehow contains interactive elements (e.g., > an XForms UI control or an HTML forms control), then all svg:use > instances will reflect the current interactive state of the > referenced element and its descendant elements. For svg:use, it is > *not* possible for two svg:use instances of the same referenced > elements to have different interactive states (e.g., different text > within text fields). Thus, svg:use has restricted flexibility. The > long-term vision to provide more flexibility is XBL, where it will > be possible to achieve re-usable interactive elements where each > instance is allowed to have different interactive state. > > > > Because there is a possibility in some cases that interactive state > might not fall into the category of “DOM manipulation”, we have > added a couple of words to the description of the “use” element for > more inclusive wording beyond just animation and DOM manipulation. > > > > Please tell us within two weeks if this response is not satisfactory. > > > Jon Ferraiolo > > SVG WG > > > > > > --------------------------------- > > > > From: Eric Seidel <eseidel@apple.com> > > Date: Wed, 28 Dec 2005 15:44:38 -0600 > > Message-Id: <FD4D268B-D2FE-49A5-BA09-0E6F69251386@apple.com> > > To: www-svg@w3.org > > > > == This message seems to have died somewhere in transit, resending. == > > > > Greetings, > > > > I understand that it is not the goal of the SVGT specification to > > cover all possible interactions between SVG and other languages. > > That said, I would still appreciate a comment from the working group > > as to the expected interaction between <use> <foreignObject> and tags > > in other languages (like html) such as forms (<input>, <textarea>, > > etc.) or plugins (<object>, <embed>, etc.) > > > > Should for example 2 copies of a plugin be created for a <use> (the > > original, non-rendered version in <defs>, as well as the used > > instance?) What happens when a user interacts with one used copy? > > Are all other copies expected to update (think of a flash game, > > instantiated multiple times on the page via <use> of a > > <foreignObject> containing an <embed>)? > > > > And what about forms? If I type text into one used copy of a form > > (<use xlink:href="url(#myForeignObjectWithForms)" />) are all the > > others expected to update? > > > > Thanks, > > Eric > > > >
Received on Tuesday, 21 February 2006 02:39:12 UTC