W3C home > Mailing lists > Public > www-svg@w3.org > February 2006

Re: [SVGMobile12] Properties on elements

From: Chris Lilley <chris@w3.org>
Date: Tue, 7 Feb 2006 19:25:12 +0100
Message-ID: <10510497050.20060207192512@w3.org>
To: www-svg@w3.org
Cc: Michael.Ingrassia@nokia.com

Hello www-svg,

Mike wrote:

> Hello SVG WG,
> The following topic has been discussed in other forums and I would be
> interested in hearing the response from other members of the SVG WG.
> According to the element table in appendix K, all properties (as defined
> in appendix L.1) can be set on basic shapes (e.g. <rect>, <circle>,
> <ellipse>, etc).  It then follows that it is valid to set as attributes
> some properties (e.g. font-family, font-size, etc) on shapes even though
> it will have no meaningful effect on the rendering of the element.
> Also, according to appendix A.7.12, these same properties can be
> set/accessed via the trait manipulation interface in the uDOM.


> Originally the property index of SVG 1.1 (appendix N) defined which
> elements each property could apply to.  In SVG Mobile 1.2 (appendix K)
> the only options are all/none/media.

Right. There are basically two schools of thought here. One (lets call
it the attribute school) says that the set of attributes on each element
should be as small as possible, to allow better validation and to
minimise footprint. Opponents of this note that it makes re-using
classes awkward, limits future expansion, and makes hand-authoring
harder since each element has its own particular set of properties -
authors have to remember what can be set where.

The other school of thought - call it the property school - states that
all properties can be set everywhere (this is the case when CSS
stylesheets are used) and that the place a property is set and the place
it takes effect can be different (for inherited properties).
Implementation is easier, because less per-element checking is needed,
and further expansion -including incorporation of other namespaces - can
always change which properties actually affect elements or their
children. As an example, in SVG Full, the font size on a rect will
affect its rendering if it has width="12em" for example. As another

<rect font-style="italic">
  <ex:rectText xmlns:ex="http://example.org/randomExtension">
  Some text

> Looking at this from an implementation standpoint, this is a bit
> wasteful of RAM usage since we are requiring the ability to set
> attributes on elements that are of no practical use to the element.

Its important to remember that the DOM is an API, not a memory model.
How much RAM is consumed depends on your particular choices regarding
speed vs foorprint. If you consider it rare for someone to ask what the
font size is on a rect that can have no text children, its okay for the
response to that API call to be optimized for memory footprint not for

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Tuesday, 7 February 2006 18:25:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:07 UTC