- 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