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

Re: SVG12: svg in foreignObject

From: Jon Ferraiolo <jonf@adobe.com>
Date: Wed, 2 Nov 2005 06:20:09 -0800
Message-ID: <6ECA24BE410D994496A2AE995367C5C8301C19@namail3.corp.adobe.com>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: <www-svg@w3.org>


---------------

From: Jon Ferraiolo <jonf@adobe.com> 
Date: Thu, 25 Aug 2005 09:20:17 -0700
To: Chris Lilley <chris@w3.org>, Jon Ferraiolo <jonf@adobe.com> 
Cc: "L. David Baron" <dbaron@dbaron.org>, www-svg@w3.org 
Message-id: <6.2.1.2.2.20050825091339.03ffbbb0@mailsj-v1.corp.adobe.com>


At 03:31 AM 8/25/2005, Chris Lilley wrote:
>On Tuesday, August 23, 2005, 4:31:03 PM, Jon wrote:
>
>JF> I hate to be picky, but I think there is a better approach for
wording 
>what
>JF> happens with SVG content inside of an svg:foreignObject. Instead of

>saying:
>
>JF>     "The contents of 'foreignObject' are assumed to be from a
different
>JF> namespace. Any SVG elements within a 'foreignObject' will not be
drawn."
>
>JF> how about:
>
>JF>     "It is assumed that the contents of 'foreignObject' are
rendered as a
>JF> different content type using a different user agent.
>
>'Different user agent may (Firefox+ASV) or may not (Firefox native) be
>the case. The definition of the content should not encourage content
>creators to assume a particular implementation strategy.

I was thinking from a conceptual model perspective, not from an 
implementation perspective. From a model perspective, there is an SVG UA

that handles everything except the foreign content and a different UA
that 
handles the foreign content, under the hood these two conceptual UAs
might 
be implemented off of the same code base. In my model, Firefox
implements 
at least two UAs: one that conforms to the HTML family of specs (HTML4, 
XHTML, DOM2, CSS2, ...) and one that conforms to the SVG family of specs

(SVG 1.1, DOM2, ...).

But perhaps "user agent" is not the best term because people will indeed

equate "user agent" to "implementation". Perhaps "language handler"?

Jon
Bjoern and everyone,
This is a follow-on response in attempt to close discussion on the
original LC comment you submitted via:
   http://lists.w3.org/Archives/Public/www-svg/2005Apr/0233.html
and which I was the last person to complain that the text is not yet
good enough:
   http://lists.w3.org/Archives/Public/www-svg/2005Apr/0233.html

Here is proposed new wording from the SVG WG on the topic which we hope
expresses the processing model for 'foreignObject' clearly:

---------------
The user agent must treat all of the content within a 'foreignObject' as
foreign content which is to be handed off to an appropriate content
handler for rendering. User agents are not required to support any
particular content types via 'foreignObject'. In particular, user agents
are not required to support SVG content embedded within or referenced by
'foreignObject'; SVG content within 'foreignObject' represents an
extension  just as with any other type of content.
---------------

Please tell us within two weeks if the above text is unacceptable.

Thanks.
Jon Ferraiolo (for the SVG WG)

>JF>  The SVG user agent
>JF> must treat all of the content within a 'foreignObject" (including
SVG
>JF> namespace elements) as foreign content which is to be handed off to
a
>JF> different user agent for rendering."
>
>JF> The above wording leaves open the possibility of future deprecation
of
>JF> svg:foreignObject in favor of html:object (or cdf:object or XLink)
because
>JF> it does not completely rule out the possibility of LanguageFoo
nesting
>JF> LanguageFoo via a [foreign]object tag. (Thinking of html:object 
>referencing
>JF> HTML files.)
>
>JF> Jon
>
>JF> At 06:36 AM 8/23/2005, Chris Lilley wrote:
>
> >>On Sunday, August 21, 2005, 7:12:13 PM, L. wrote:
> >>
> >>LDB> 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.
> >>
> >>Thus leading to the text,
> >>
> >>The contents of 'foreignObject' are assumed to be from a different
> >>namespace. Any SVG elements within a 'foreignObject' will not be
> >>drawn.
> >>
> >> >> LDB> Shouldn't it instead say that any SVG element *children* of
a
> >> >> LDB> 'foreignObject' will not be drawn?
> >>
> >>
> >>Yes.
> >>
> >> >> But the original wording seemed to allow direct SVG children.
Can you
> >> >> suggest better text to clarify this?
> >>
> >>LDB> Using what I said above:
> >>
> >>LDB>    The contents of 'foreignObject' are assumed to be from a
different
> >>LDB>    namespace. Any SVG element children within a 'foreignObject'

> must not
> >>LDB>    be drawn.
> >>
> >>That seem to be exactly what I said, except s/will/must/, a change i
> >>certainly agree with.
> >>
> >> >> 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.
> >>
> >>Right. So can I take it that we now agree with this text?
> >>
> >>--
> >>  Chris Lilley                    mailto:chris@w3.org
> >>  Chair, W3C SVG Working Group
> >>  W3C Graphics Activity Lead
>
>
>
>
>
>--
>  Chris Lilley                    mailto:chris@w3.org
>  Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
Received on Wednesday, 2 November 2005 14:20:21 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:32 GMT