W3C home > Mailing lists > Public > www-svg@w3.org > April 2005

Re: [SVGMobile12] Chapter 7

From: Chris Lilley <chris@w3.org>
Date: Thu, 28 Apr 2005 14:00:49 +0200
Message-ID: <349561611.20050428140049@w3.org>
To: www-svg@w3.org, Cameron McCormack <cam-www-svg@aka.mcc.id.au>

Hello Cameron

> A few things in "Coordinate Systems, Transformations and Units".
> 
> - In 7.6.1, it says
> 
>     The following is the Backus-Naur Form (BNF) for values for the
>     transform attribute.
> 
>   where actually the BNF only defines values for the transform attribute
>   that match transform-list.

Yes, you are right. Although the spec says

  The <transform-list> attribute type is defined below. The 'ref( )'
  attribute type is defined in the Constrained Transformations section.

it then goes on to describe the transform-list part as the transform
attribute. This is a copy-paste error from SVG 1.1, we will fix it.

> - A few of the examples in section 7.7 aren't indented nicely and hinder
>   readability.

Yes, we can fix that.

>   Also, a lot of the red monospace text describing the
>   transformations is quite unreadable.

To clarify - is it the styling that makes it unreadable, or are you
using 'red monospaced' to indicate the particular pieces of text whose
content is unreadable?

> 
> - In 7.7.5, it is not clear which svg element the ref() transform refers
>   to.  Is it the closest ancestor svg element?  Or the outermost one?
>   In the red text I see svg[0] referred to, so I guess that might mean
>   the outermost one, but that notation with the square brackets isn't
>   defined anywhere.

The spec says:

  In the above definition, g[n] refers to the element with
  the id "g-n"

so the [n] notation is referring to the set of ids on the
nested g (and svg) elements. We might say that more clearly as

  In the above definition, E[n] refers to the element called
  E with the id "g-n". So, in Example "n=2" the element
  hierarchy from the root to the rect is svg[g-2], g[g-1],
  g[g-0] and rect[elt].

Would that be clearer? SVG Tiny 1.2 does not allow nested svg elements,
so the closest ancestor *is* also the outermost one. The distinction
will be important for SVG Full though, which does allow nested svg
elements.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
Received on Thursday, 28 April 2005 12:00:57 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:30 GMT