Re: Definition of "container element" in SVG 1.1

Hi Glenn, Erik.

Glenn A. Adams:
> > it may be useful to distinguish between a "graphics container",
> > i.e., a visual or otherwise presentable container, and an
> > "information container", i.e., an grouping element (not necessarily
> > related to graphics or presentable descendant elements);

Erik Dahlström:
> That sounds like a rather good idea, but I wonder if 'clipPath' isn't
> a specialcase. Are the 'clipPath' element container restrictions
> useful for any other elements?
>
> Maybe 'container element' as the general term, and 'limited container
> element' if we find that it the 'clipPath' restrictions can be useful
> somewhere else. "Limited container element - An element which can
> contain a limited set of other elements. Each 'limited container
> element' must itself define these further restrictions. Specifically:
> <clipPath>."
>
> I think that adding 'glyph' and 'missingGlyph' to container elements
> is fine. They do have special handling that is different from normal
> container elements, but they can contain other elements and as such
> they belong in that category.

Hmm, thinking about this some more, there’s a difference between <glyph>
and say <marker>.  A <marker> can have a child <marker> (according to
the DTD), while a <glyph> can’t have a child <glyph>.  Also, a <glyph>
can only be a child of <font>, not of an arbitrary container element.

Given the number of places the term “container element” is referenced,
maybe it’s better just to leave <glyph> and <missing-glyph> out of that
list.  I’ll still take <clipPath> out, though.

I don’t think there’s a need to define a limited container element at
the moment, because as you mention, we don’t have anywhere else yet that
those <clipPath> child restrictions are useful.  Especially if the
definition required the limitations to be defined elsewhere.

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 22 May 2009 07:47:47 UTC