- 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
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 >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 Thursday, 25 August 2005 16:24:29 UTC