- From: Gavin Kistner <gavin@refinery.com>
- Date: Thu, 13 Nov 2003 12:47:18 -0700
- To: www-svg@w3.org
- Cc: svg-developers@yahoogroups.com
Comment Context
FWIW, here are my initial comments on the SVG1.2 draft. So you may
classify and sort my comments appropriately, my role is an SVG content
author, standing with 1.8 feet in the SVG-as-programmable-UI camp.
Section 1
How should the elements be described? I personally prefer DTD over XML
Schema. IMO a DTD snippet is fine and moderately helpful when
introducing the element (ala HTML 4.01 specs), but I think it would be
fine to omit precise specifications inline in the documentation, just
include a common-case sample or two, leaving the precise syntactic
specification to a separate-file DTD (or XML Schema).
Section 2, Example #5:
" 5. Implement a new document structure for the SVG specification by
publishing multiple parts. For example, SVG Part 1 could define the
core static SVG features; SVG Part 2 could introduce SMIL animation and
interactivity; SVG Part 3 could define the SVG DOM; and finally Part 4
would cover the extensibility."
If I understand this correctly to mean "We're going to solve the fight
between the two camps by reorganizing the documentation into a
particular order" then I'm not sure how this would help. IMHO example
#1/2 are the best choices -- provide a clearly-defined profile for each
of the two camps, and let the UAs state which they support.
In fact (Section 2.1) I really don't understand the difference between
a 'theme' and a profile. What's the SVG Core 'theme' if not a subset
profile of the overall ('Extended') specification?
(skipping various sections which are too complex for me to peek at now
:)
Section 17.2
SVGImage.getPixel() returns an unsigned long. Assuming this is for a
32-bit RGBA implementation, this seems like a rather annoying data type
to have to deal with. It takes a bit of bitwise ANDing and shifting to
get each component out, which is surely what every developer would have
to do in order to work with this.
The method itself is quite welcome, but I suggest that a full-fledged
object be returned, with (read-only) direct access to each of the RGBA
values.
--
Gavin Kistner @ Refinery, Inc.
gavin@refinery.com
work: +1.303.444.1777
Received on Thursday, 13 November 2003 14:47:23 UTC