- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sun, 8 May 2011 14:24:08 +0100
- To: www-svg@w3.org
Hello, I assume already, that SVG2.0 will be a compatible superset of SVG 1.1 and SVG tiny 1.2, therefore only issues beyond SVG tiny 1.2: - avoid backwards incompatible changes (just because some viewers have bugs or because some/many just cannot imagine yet, for what some features could be maybe used, if implemented correctly) - define behaviour of stroke-dasharray, in doubt define more properties related to this like stroke-dash-cap, stroke-dash-subpath etc - to-animateTransform define/clarify how to get a smooth change from current to to-value - allow animateTransform of type matrix - tooltip element, because title and desc are intended for other purposes and something like the SVG tiny 1.2 method <metadata about="#ID" role="tooltip" property="aria:tooltip" content="This is the tootip text." /> is not optimal (even if it would work in viewers), there should be a well defined SVG method to avoid that authors abuse other elements for this functionality or that they always have to create their own tooltip method, for example with declarative animation without specifying relations properly. - additional generic element to structure content of desc, tooltip and maybe metadata, like XHTML:div, to be able to add semantics with role, RDFa... - allow/define viewBox on image to present only parts of the image - define a method to reference raster images with its own size without the need to set width and height - add requirement for viewers to provide an interface for audio and video on demand (pause authors timing considerations if this option is used); similar to what is described in the HTML5 draft for their video and audio - a clever combination of both could finally result in pretty useful elements - explore the option to get free and then required formats for audio and video in SVG (similar as PNG and JFIF/JPEG is required). - allow authors to specify the required rounding method to device pixels per element with an attribute (to top|bottom and left|right, including or excluding rounding off/up integer results. This is typically very important to be able to place partly transparent objects directly edge to edge without an overlap (or gap) due to rounding artefacts of viewers - currently with SVG and typical viewers it is not possible to place such objects edge to edge without having some ugly artefacts from viewer rounding to device pixels, rendering is not predictable for authors, because it may depend on magnification/scaling and specific implementation issues. - stroke with variable width - pattern along the stroke more advanced than stroke-dasharray, even if this becomes defined - simple method to structure stroke perpendicular to the path direction (for example only fragment on fill or only outside fill, arbitrary fractions etc); maybe this is covered by advanced vector-effects? - declarative method to conserve and reuse current values from animation in animation - improve to-animation approach to get something similar to CSS-transitions within SVG animation. - star like element, see proposal http://hoffmann.bplaced.net/svgueb/polar.php maybe other elements, which simplifies it for authors to specify popular named shapes, which have already a more or less good defined semantic meaning, but are not trivial to realise for authors. - explore, whether path commands in polar coordinates have a chance to be used by authors or not - see proposal http://hoffmann.bplaced.net/svgueb/ppolar.xhtml - alternative methods for simple notation of smooth paths (simple interpolation methods to derive smooth curves from simple point lists without the need for the author to calculate the derivatives to get control points) - maybe already included in the next point - include declarative method to generate shapes from raw data (especially without scripting) - see proposal http://hoffmann.bplaced.net/rdml/ - advanced gradients, pattern methods - adopt SMIL time containers (layers) and time manipulation module - parameters - z-index - continue efforts with 3D-transformation (compatible with current SVG transformations of course) One option could be to put together only the simpler, not much graphic related new features, clarifications and fixes into an intermediate version 1.2 or 1.3 (this is roughly the first group above) and to prepare more advanced features as modules at the same time and combining this later to SVG 2.0 - I think, a version 2.0 without many new exciting new features would be disappointing for authors and several simpler issues like the tooltip, the stroke-dasharray or the to-animateTransform need a faster approach then to wait for such more complex features. Olaf
Received on Sunday, 8 May 2011 13:24:40 UTC