Re: SVG12: svg in foreignObject

While I am general agreement that the original vision behind 
svg:foreignObject was to embed/referenced non-SVG content which is 
processed according to a different specification's rules, I am 
uncomfortable with disallowing SVG content within an svg:foreignObject. 
Long-term, I believe the W3C needs to unify its various replaced-content 
facilities (svg:foreignObject, html:object, maybe some features from XLink, 
comparable features in XSL-FO) into a single feature which addresses 
general replaced-content needs in a satisfactory manner. Going along this 
line of thought, since html:object allows recursive HTML content, therefore 
I conclude that svg:foreignObject should allow recursive SVG content.

Another reason for allowing an SVG file sometimes to treat SVG content as 
"foreign content" is that there are various profiles and versions of SVG. 
Perhaps there might exist a browser which implements only a subset of SVG 
(e.g., static, scripted SVG Full 1.1), and implements that subset very 
well, but a content creator requires other features, such as the multimedia 
features found in SVG Tiny 1.2. We should not paint ourselves into a 
language corner and rule out the ability for the outer SVG content to be 
rendered by one SVG user agent and the SVG embedded within an 
svg:foreignObject rendered by a different SVG user agent.

Jon

At 10:12 AM 8/21/2005, L. David Baron wrote:
>On Sunday 2005-08-21 18:43 +0200, Chris Lilley wrote:
> > On Sunday, August 21, 2005, 6:28:24 PM, L. David Baron wrote:
> > LDB> On Sunday 2005-08-21 18:20 +0200, Chris Lilley wrote:
> > >> On Sunday, April 24, 2005, 7:27:38 PM, Bjoern wrote:
> > >> BH>   From http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/extend.html
> > >> BH> section 19.2
> > >>
> > >> BH> [...]
> > >> BH>   The contents of 'foreignObject' are assumed to be from a different
> > >> BH>   namespace. Any SVG elements within a 'foreignObject' will not be
> > >> BH>   drawn, except in the situation where a properly defined SVG
> > >> BH>   subdocument with a proper xmlns (see "Namespaces in XML 1.1" 
> [XML-NS])
>
> > >> It is prohibited by the schema, you are correct that this is not
> > >> desired. The spec has been altered by removing the text after 'drawn' so
> > >> that the sentence ends there.
> >
> > LDB> Shouldn't it instead say that any SVG element *children* of a
> > LDB> 'foreignObject' will not be drawn?  That seems like what may have been
> > LDB> intended in the first place.  The revised text appears to prohibit
> > LDB> drawing SVG inside elements of some other language that are inside
> > LDB> foreignObject.
> >
> > Yes, the original intent was that SVG foreignObject hands off to another
> > renderer, and that if that content then hands back to a (second instance
> > of an) SVG renderer, such nested embedding can occur.
>
>The idea that different namespaces are handled by different renderers is
>an implementation detail.  It's not mentioned in the spec, nor should it
>be.  (And unless the model were explicitly the model described in the
>spec, an implementation that drew the nested content on that basis would
>still, as a whole, be nonconformant, since the wording above forbids
>drawing it.)
>
> > But the original wording seemed to allow direct SVG children. Can you
> > suggest better text to clarify this?
>
>Using what I said above:
>
>    The contents of 'foreignObject' are assumed to be from a different
>    namespace. Any SVG element children within a 'foreignObject' must not
>    be drawn.
>
> > The current wording makes it clear that the existing renderer is not to
> > render any SVG content which occurs as either direct children or as
> > nested children of foreignObject.
>
>The specification should rely on the recursive nature of the nesting and
>just define the recursive step instead of poking across multiple layers
>of nesting.  In other words, it should just say that the content in the
>other namespace is rendered according to that specification's rules.  If
>that then recursively includes SVG, the drawing of the included SVG is
>defined (or not) by that other specification.  The specification for
>svg:foreignObject should only describe the handling of foreignObject's
>children, and leave the rest to the specifications governing those
>children.
>
>-David
>
>--
>L. David Baron                                <URL: http://dbaron.org/ >
>           Technical Lead, Layout & CSS, The Mozilla Foundation
>

Received on Monday, 22 August 2005 01:48:10 UTC