W3C home > Mailing lists > Public > www-svg@w3.org > November 2005

Re: [SVGMobile12] focus related methods in SVGSVGElement Interface

From: Andrew Shellshear <Andrew.Shellshear@cisra.canon.com.au>
Date: Tue, 29 Nov 2005 11:54:01 +1100
Message-ID: <438BA6A9.20704@cisra.canon.com.au>
To: fora@annevankesteren.nl
CC: kono.masahiko@canon.co.jp, www-svg@w3.org

Anne van Kesteren wrote:

> Quoting Andrew Shellshear <Andrew.Shellshear@research.canon.com.au>:
>>> SVGSVGElement interface has focus related methods(moveFocus(), 
>>> setFocus()).
>>> What happens when a SVG document has nested <svg> element?
>>> I think a focus is only one in document, not <svg> fragment.  I think
>>> Document Interface should have focus related methods.
>> We put them on SVGSVGElement and not SVGDocument (or Document) 
>> because there might not be an SVGDocument.  This can happen when we 
>> are in a multi-namespace XML application, and SVG is just one 
>> component of it, such as in CDF scenarios - here, the root element of 
>> the XML document isn't the svg element, and there is no SVGDocument.
> How does SVGDocument depend on the root element of the document? It 
> might very
> well be that the document object supports all specialized document 
> objects. So
> the document object has both HTMLDocument and SVGDocument implemented. (I
> believe this is the case in some UAs, at least.)

It *could* be the case that there is no SVGDocument at all.  It's 
allowed.  So we can't put focus-related methods on it.  (Sorry if I'm 
missing the point, here.)

> Also, this answer does not say if the second question, regarding 
> nested svg:svg
> elements, is addressed.

True.  This case applies only to SVG Full, of course - an SVG 
implementation inside a foreignObject will be a separate entity, and 
won't interact with the "parent" svg.  I suspect in the Full case, any 
calls to setFocus or moveFocus would not cross the SVGSVGElement 
boundary - they would only apply to descendants of this SVGSVGElement 
(stopping at any child SVGSVGElement).  SVG Full 1.2 is a work in 
progress, and we will address this comment before the next published draft.

Received on Tuesday, 29 November 2005 00:56:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:08 UTC