Re: Definition of "container element" in SVG 1.1

On Mon, 20 Apr 2009 08:50:35 +0200, Glenn A. Adams <gadams@xfsi.com> wrote:

> On 4/20/09 12:55 PM, "Cameron McCormack" <cam@mcc.id.au> wrote:
>
>> I don¹t think the set of elements in the ³container element² definition
>> in SVG 1.1 is right.  It currently says:
>>
>>   An element which can have graphics elements and other container
>>   elements as child elements. Specifically: 'svg', 'g', 'defs'
>>   'symbol', 'clipPath', 'mask', 'pattern', 'marker', 'a' and 'switch'.
>>
>> First, <clipPath> cannot contain just any graphics or container element;
>> it only allows basic shapes, <path>, <text> and <use>.  So I think it
>> should be removed.
>>
>> Second, both <glyph> and <missingGlyph> have the same content model as
>> <g>, so I think they should be added.
>
> 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);

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.

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 20 April 2009 12:50:49 UTC