Re: SVG12: svg in foreignObject

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

Received on Tuesday, 23 August 2005 13:36:33 UTC