W3C home > Mailing lists > Public > www-svg@w3.org > October 2000

Re: SVG specification issues

From: Jon Ferraiolo <jferraio@Adobe.COM>
Date: Fri, 27 Oct 2000 15:59:25 -0700
Message-Id: <4.2.2.20001026110750.00d17e80@mailsj.corp.adobe.com>
To: bbrodie@savagesoftware.com (Blaine Brodie)
Cc: www-svg@w3.org
Blaine,
Thanks for the error reports.

At 10:56 AM 10/26/00 -0700, Blaine Brodie wrote:
>A few minor errors with the current specification:
>
>The specification defines a CSS decimal number as having at least one
>digit before or after the dot.  But according to the CSS2 spec, it
>actually should be defined as having at least one digit after the dot.

Right you are. I'll fix the SVG spec.

(But I'll make the editorial comment that "25." is a valid way to express a 
real number and should be allowed. I'll bet nearly every implementation 
supports this.)


>The new icc-color syntax does not define a separator between its Icc color
>numbers.  It used to be comma separated, should it still be this way?

Items inside a CSS "function" need to be comma-separated.

I modified the SVG spec to say:
    icc-color(<name>[,<icccolorvalue>]*)


>The specification states that SVGICCColor interface is a base class for
>SVGColor.  SVGICCColor isn't a base class.

Correct. I removed the wording about SVGICCColor being a base class.


>The description of SVGStylable's getPresentationAttribute states:
>         "If the given attribute or property is being animated, contains the
>current animated value of the attribute or property. If the given
>attribute or property is not currently being animated, contains the same
>value as
>         'baseVal'."
>Should this description be with getAnimatedPresentationAttribute rather
>than the former?

The sentence certainly does not belong with getPresentationAttribute. I 
will update the spec.


>And one suggestion:
>Element Attributes that have underlying objects require parsing before
>they can be used to set their underlying objects.  For example, a path
>element's 'd' attribute needs to be parsed before it can set the
>underlying path segment lists.  However,  the setAttribute, setNodeValue
>etc. methods do not throw parse exceptions, so the user does not know
>whether the attribute was parsed correctly.  Subclassing DOM's attribute
>and adding a method to query whether the set method succeeded or failed at
>parsing the string and setting the underlying object may be useful for the
>user.

Agreed. Unfortunately, the setAttribute() method, etc. is under the control 
of the DOM working group, and DOM2 at Proposed Recommendation and shortly 
will be announced as a Recommendation. It seems that these methods should 
be defined to raise a SYNTAX_ERR. I'll mention this to the DOM group.

Until DOM gets changed, what will happen is that the SVG user agent should 
go into an error state and re-render the document up to the point of the 
newly introduced error. Theoretically, script writers can check for 
"onerror", but all they will know is that an error occurred somewhere.

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated

>---
>Blaine

Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated
Received on Friday, 27 October 2000 19:17:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 5 November 2012 23:52:48 GMT