SVG2 Requirements Input

Resolutions/Commitments

See SVG2_Resolutions and SVG2_Requirements_Commitments pages.

Feedback

Collated here are the responses to Doug's call for public input on features for SVG2, and the issues we already had in the new tracker.

NOTE: we should have a look at the old tracker issues too, and move over any feature requests that we don't have in the new tracker. A wiki summary can be found here.

General

Avoid backwards incompatible changes

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)

— Olaf Hoffmann

Comments
yes	SVG WG	We will add a section to the Requirements document about general approaches including avoiding backwards compatible changes (see Pre-TPAC Meeting minutes ACTION-3154)

Declarative shape generation from raw data

include declarative method to generate shapes from raw data (especially without scripting) - see proposal http://hoffmann.bplaced.net/rdml/

— Olaf Hoffmann

Comments
no	SVG WG	This seems too big for SVG 2 and should be looked at within the Web Components activity (see Pre-TPAC minutes)

Templating for controls/widgets

Building a web app with UI components needs this. JonF's original 'Grand Unified' plan which begat RCC, sXBL, etc. and then vanished is a gaping hole in the spec. as is. Just the other day I wanted to build a scroll bar and polled "people that know" who advise me to use Javascript libraries. I can build Windows apps with all sorts of component controls, OS X apps with Interface builder etc. A templating mechanism for things that can be re-used would be nice.

— Alex Danilo (request observed over the years)

Comments
no	SVG WG	We will not include a templating mechanism in SVG2 (see Pre-TPAC meeting minutes)

Accessibility

no it's not really an afterthought! What does it mean for geometry to be accessible? Let's think about it!

— David Dailey

ISSUE-2114 may be relevant.

Comments
yes	SVG WG	We will keep accessibility in mind when designing new features, and improve existing features where we can, in SVG2. (see Pre-TPAC meeting minutes)

Rendering Model

z-index

— Olaf Hoffmann

local z-index --if global z-index is computationally impractical (think knot theory and planar four regular graphs)

global z-index (I get the sense jwatt is doing this?)

— David Dailey

Comments
yes	SVG WG	Accepted (see resolution)

Translucency

modeling translucency beyond transparency

— David Dailey

Comments
maybe	Chris	Shaders in customFilter may cover this already
no	SVG WG	Pre-TPAC Meeting minutes

Pixel rounding methods

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.

— Olaf Hoffmann

Seems related to ISSUE-2291.

Comments
yes	SVG WG	We will ensure there is a way to avoid getting seams on adjacent edges of rendered elements in SVG2 (See Pre-TPAC Meeting minutes)

Flatten to image

For some use cases, a zillion paths or objects probably end up chewing memory and bloating the DOM for some special cases. So, it would be nice to have a primitive that takes the rendered output of arbitrary SVG and flattens it to an image so all you get is the pixels. Think of it like 'use', but the target of the use becomes a sprite with all it's efficiency of rendering, blitting etc. Access to the pixels of course is a logical extension of this.

— Alex Danilo (personal wish-list)

Comments
maybe	Erik	How does this differ from the buffered-rendering property?
yes	SVG WG	Accepted as a requirement (See Pre-TPAC minutes)

Document Structure

Namespace requirements cleanup

— Doug Schepers

Related is ISSUE-2042. We have a resolution for xlink:href.

Comments
yes	Cameron	I'm not sure if this is anything more than the removal of xlink. I'm in favour of that, pending a concrete proposal.
yes	Erik	I'm in favour of that, pending a complete proposal covering more than just xlink:href.
yes	Chris	We already agreed to do this for xlink and already agreed to do this for xmlevents. Thus an xml serialisation needs only the SVG namespace, and an HTML5 serialisation does not need that. For custom data, use data-* from HTML5 for that serialisation,and continue to alow arbitrary, declared namespaces in the XML serialisation..
yes	SVG WG	See See Pre-TPAC Minutes

cleanup

— Doug Schepers

Comments
—	Cameron	Don't know what the proposal is.
—	Chris	Presumably a regularization of shadow tree generation and, especially, inheritance and liveness.
yes	SVG WG	We will require a feature that allows symbol reuse without requiring duplication of shadow trees in SVG2. (see Pre-TPAC Meeting minutes)

Shadow tree cleanup

— Doug Schepers

Comments
—	Cameron	Need more detail.
yes	SVG WG	We will require a feature that allows symbol reuse without requiring duplication of shadow trees in SVG2. (see Pre-TPAC Meeting minutes)

Marker cleanup

— Doug Schepers

Resolution for adding currentFillPaint and currentStrokePaint specifically for addressing a common complaint about inheriting colors into the markers.

Comments
yes	Cameron	I want to see more concrete proposals before committing to them, but I think we definitely should do something to improve the marker situation in SVG 2.
yes	Chris	Deprecate markers on arbitrary paths. Rarely used, adds significant complexity (markers can have markers),mostly used where the path itself is not drawn or is a polyline. Add a polymarker basic shape which takes a list of points and a list of (pointers to) one or more markers, which are repeated if there are more points than markers.
yes	SVG WG	We will improve markers for SVG2. (see Pre-TPAC Meeting minutes)

Improve the DOM

— Doug Schepers

— SVG_2_DOM collects a few different proposals

Take a machete to the DOM. People complain and rightly so. The 1.2 Tiny micro-DOM didn't seem to tickle anyones fancy. So we need to address the DOM to attempt to keep people happy and make the web app developers life nicer.

— Alex Danilo (request observed over the years)

Comments
yes	Cameron	I think improved SVG DOM is a must have for SVG 2. Someone needs to write up a proposal.
yes	Erik	We should resolve on the things we have proposals for as a first step, but writing up more detailed proposals is necessary in some cases.
yes	SVG WG	We will generally improve the SVG DOM for SVG2 (specific proposals to be resolved on later). (see Pre-TPAC meeting minutes)

Improve the DOM for SVG Animation

— Tim Becker

Related: ISSUE-2204 Improve DOM Interfaces for SMIL Values

Proposal page: AnimateMotion DOM API

Comments
yes	Erik	Just exposes some information that the UA already has.
yes	SVG WG	We will expose animateMotion values in the SVG DOM in SVG2. (see Pre-TPAC meeting minutes)

Make the SVGList* interfaces a bit more like other lists/arrays

ISSUE-2323 Consider aligning SVG*List interfaces with other arraylike types (Note: already implemented in Opera 11.50 and Firefox 5) - Has an ACTION-2975 to add that to the spec.

Comments
yes	Erik	Already implemented, has action to add it to spec already.
yes	SVG WG	Accepted (see ACTION-2975)

Make it easier to read and write to attributes in the DOM

To allow e.g rectElt.x.px = 20 for access to the attribute values.

ISSUE-2044

Comments
yes	SVG WG	We will make it easier to read and write to attributes in the SVG DOM in SVG2 (see Pre-TPAC meeting minutes)

Improve the SVG path DOM

Experimenting APIs before committing to them is something that should be done. An API similar to Canvas would be desirable, however access to segments is not provided when they are created in Canvas. The SVG Tiny 1.2 SVGPath API is similar to what the Canvas path methods offer.

Much of the SVG DOM overhead (and complexity) of the PathSegList interfaces come from the keep-lists-in-sync-at-all-times requirement. The SVG Working Group should check this requirement to see if it is absolutely necessary and if there are compelling use cases. If not then, it could probably be dropped.
The combination of the SVGPath interface and the SVGPathSegList interfaces could be a solution possibly, use the path creation methods from SVGPath, then inspect and change segments with the methods given in the SVGPathSeg\* interfaces.

— Path API improvements

— Canvas-like path creation API

Comments
yes	SVG WG	We will improve the SVG path DOM APIs in SVG2. (see Pre-TPAC meeting minutes)

A way to access (presentational) property values easily

Here's a very simple example. Why does my browser know how to convert "red" into a RGB triple, but I have to write a conversion function in JS and carry a huge-ass 147-entry map around with me?

— Jeff Schiller

Comments
maybe	Erik	The TraitAccess interface from SVGT12 does address this, but it's maybe more of a CSSOM sucks kind of thing.
yes	SVG WG	We will coordinate with other WGs to ensure improved property value access to SVG properties in SVG2. (see Pre-TPAC meeting minutes)

Make it possible to get the bounding box of an element in a particular coordinate system

ISSUE-2283

Possibly extend getBBox() with a parameter being the element in whose coordinate system you want the bounding box.

Proposal page: getBBoxOf

Comments
yes	SVG WG	We will improve bounding box method APIs in SVG2. (see Pre-TPAC meeting minutes)

Automatic fetch/discard of subtrees

Thinking of the 'Big Data Set' like say all of openstreetmap.org, it would be nice to have a parent element like say that manages conditional zoom/pan to fetch and/or discard the child tree data. This is along the lines of the SVG Tiling module but more general. If we want to pan an SVG of the entire planet in detail, then the UA should be able to load content that declaratively says it should exist if you've panned within 'n' pixels of the viewport or have a specific user->device zoom level set. Then you can walk a tree of the world and only have relevant content in your DOM without ever resorting to script to manage it all.

— Alex Danilo (personal wish-list)

Comments
yes	Chris	This was proposed for SVGT1.2, rejected, then added by MPEG to LASeR and adotped by OMA. So there is clearly a need.
yes	SVG WG	We will add discard in SVG2 (see Seattle meeting minutes)

Additional generic element

additional generic element to structure content of desc, tooltip and maybe metadata, like XHTML:div, to be able to add semantics with role, RDFa...

— Olaf Hoffmann

Comments
no	SVG WG	We will not add a new semanticless SVG element to hold role/rev/etc. attributes to SVG2.(see Pre-TPAC meeting minutes)

Allow viewBox on image

allow/define viewBox on image to present only parts of the image

— Olaf Hoffmann

This is ISSUE-2002.

Comments
yes	SVG WG	We will have a method for to select a part of an image to display, maybe by allowing viewBox on it. (see Pre-TPAC meeting minutes)

Auto-sized image

define a method to reference raster images with its own size without the need to set width and height

— Olaf Hoffmann

Comments
maybe	Chris	Certainly for aspect ratio (i.e if only one value of width or height is supplied,autocompute the other based on native aspect ratio). Not sure how a pixel-based 'own size' works in general with arbitrary coordinate systems,and some rasterformats have a preferred real-world size in the EXIF or other places (in mm,inches,etc).
yes	SVG WG	We will allow auto-sized images in SVG2. (see Pre-TPAC meeting minutes)

Level of detail control

If we have a large data set, and we zoom, then level of detail control of what gets drawn is useful for _lots_ of use cases.

— Alex Danilo (request observed over the years)

— Satoru Takagi (w3c member submission)

Submission
Documents : Tiling and Layering Module for SVG 1.2 Tiny
W3C Staff Comment

Comments
yes	Chris	This is the one remaining missing feature from the original 1996 requirements document
yes	SVG WG	We will support Level of Detail control in SVG2 (see Pre-TPAC meeting minutes).

Display of InkML trace groups

— Charles Pritchard

Comments
yes	SVG WG	SVG should be able to display InkML trace groups by some means such as buffered-rendering and variable stroke width , not necessarily varying anything (see meeting minutes)

Placeholder graphics for unresolved images

Consider adding placeholders or fallback for unresolved resources

ISSUE-2040

Comments
no	SVG WG	We will not have a feature to provide broken image fallback content, unless specific proposals are worked on further.(see Pre-TPAC meeting minutes)

Consider adding transform="" to

ISSUE-2252

Comments
yes	SVG WG	We will allow transform on

Add @allowReorder to for improved language-based switching

ISSUE-2238

That attribute is in SMIL 3.

Comments
yes	SVG WG	We will support a mechanism like or the same as allowReorder from SMIL3 in SVG2. (see Pre-TPAC meeting minutes)

Allow referencing root external files with

ISSUE-2295

Comments
yes	SVG WG	We will relax referencing requirements to particular elements to allow dropping fragments to mean referencing root element, where it makes sense, such as with use, in SVG2.(see Pre-TPAC meeting minutes)

Attributes

Parameters

— Doug Schepers (must have)

— Olaf Hoffmann

This is ISSUE-2067 and ISSUE-2312.

Should this subsume ISSUE-2047 Using author-defined named colors where can be specified? If adopted,it covers that case. If not adopted,we still need to address named colours (in HTML5 serialisation; in XML serialisation its easy). Also relates to solidColor which gives another way to have named, animatable colours.

Comments
yes	Cameron	I want to see at least some simple parameterised graphics in SVG 2, although I still feel that we need to have this more closely integrated with CSS Variables or whatever mechanism CSS has.
yes	Tav	It would be nice to be able to have a simple SVG that can easily be reused without resorting to tricks like JavaScript. See the section "Reusing external SVG buttons" at my SVG Button Test page.
yes	Chris	Needed to give more flexibility for SVGs used as fragments from CSS (for gradients, filters...). Required for SVG glyphs in OpenType fonts.
yes	SVG WG	We will have Parameters in SVG2, worked on in a normatively referenced separate spec. (see Pre-TPAC meeting minutes)

Custom data-* attributes

(This should be grouped as an HTML5/XML item - ed)

— Jon A. Frost

Comments
maybe	Chris	Presumably for HTML compatibility; need to track development there. Something like that is needed for the HTML5 serialisation of SVG, since custom namespaces cannot be used and "you can't extend it, sorry" is a poor answer.
yes	SVG WG	We will add data-* attributes in SVG2 to align with HTML5 (See Pre-TPAC meeting minutes)

Randomization

extensive support for randomization (random attribute values, etc)

— David Dailey

Comments
no	SVG WG	we will not add declarative randomisation functionality in SVG2 (See Pre-TPAC meeting minutes)

Consider adding certain HTML attributes used in metadata

For microformats, this is for rel and rev attributes (although I think that rev has been dropped from HTML5).

ISSUE-2048

For microdata, this is for itemscope, itemtype, itemid, itemref, and itemprop attributes.

#whatwg logs

Comments
yes	SVG WG	we will align with HTML5 global semantic attributes where these make sense for SVG (See Pre-TPAC meeting minutes)

Consider relaxing case sensitivity of presentation attribute values

ISSUE-2292

Comments
yes	SVG WG	We will make property values case insensitive (See Pre-TPAC meeting minutes)

Styling

Fluorescent colours/extended colour specifiers

At the moment we have the HTML colour names, rgb(,,) and ICC support. Extended colour spaces have been in mainstream O/S graphics libraries for quite some time allowing you to specify R greater than 1.0 (or 255 if you think 8-bit). It's high time we had high dynamic range colour in the stack.

— Alex Danilo (personal wish-list)

Comments
yes	Chris	May already be covered by SVG Color module. HDTV added HighColor.
yes	SVG WG	SVG 2 will depend on svg color management subject to deciding the exact conformance classes required. (See Pre-TPAC meeting minutes)

Non-scaling stroke

— Doug Schepers (must have)

— Rick Graham

— Paul Williams

All SVG Tiny 1.2 viewers already implement this as (syntactic sugar for) part of the vector-effect module. Should be a no-brainer to add as a module for 1.1, rather than a 2.0 feature.

— Alex Danilo (request observed over the years)

This is ISSUE-2400.

Comments
yes	Cameron	Comparatively high demand for this feature, and I hope (although I'm not sure, with non-uniform scaling, skewing, etc.) that it's simple to specify and implement.
yes	Erik
yes	Tav	Inkscape has an option to simulate this, as well as to keep rectangle corners from scaling.
yes	Chris	Often requested, easy to add.
yes	SVG WG	SVG 2 will include non-scaling stroke. (See Pre-TPAC meeting minutes)

Non-scaling rounded rect corners

Tav: Inkscape has an option to keep rectangle corners from scaling

Comments
yes	SVG WG	SVG 2 should include non-scaling features, aside from non-scaling stroke. (2 separate components: non-scaling part of the object, and non-scaling entire object) (See Pre-TPAC meeting minutes)

Variable stroke width

— Doug Schepers (nice to have)

— Olaf Hoffmann

This is ISSUE-2271.

Comments
yes	Tav	Inkscape has a trial "LPE" (Live Path Effect) that simulates this using a filled path. This is a high demand item, especially for font design.
yes	Chris	Definately a useful feature; should not be tied to the number of nodes in the path. Skeleton stroke plus variable width is a more useful, editable, more easily animatable representation than a flattened path. Useful for pressure-sensitive tablets.
yes	SVG WG	SVG 2 shall include variable stroke-width (See Pre-TPAC meeting minutes)

Stroke position

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?

— Olaf Hoffmann

A stroke-position property to control where relative to the path a stroke is painted.

— Jérémie Patonnier

Proposal page: Stroke position

Comments
yes	SVG WG	SVG 2 shall include a way to specify stroke-position (See Pre-TPAC meeting minutes)

Define behaviour of stroke-dasharray

define behaviour of stroke-dasharray, in doubt define more properties related to this like stroke-dash-cap, stroke-dash-subpath

— Olaf Hoffmann

Comments
yes	SVG WG	SVG 2 will specify more precisely stroke dashing (See Pre-TPAC meeting minutes)

Adaptive stroking

Needed for cartography where the dashing always ends with a full length dash at the start and end of the stroke. So the borders of things look consistent - i.e. not chopped off. It requires the renderer to work out the length of the path and scale the dasharray appropriately. Been a part of HP-GL for decades, surely SVG should handle this.

— Alex Danilo (request observed over the years)

Proposal page: Stroke dash adjustment

Comments
yes	SVG WG	SVG 2 shall allow more author control over positions of dashes (See Pre-TPAC meeting minutes)

Hatch fills

Required for mapping again. If you have a large area you just want to fill it with a bunch of spaced lines/hatches etc. Pattern fill doesn't work since you get tiling problems. Easy to do in Postscript or HP-GL. Difficult in SVG.

— Alex Danilo (request observed over the years)

This is ISSUE-2372.

Comments
yes	Tav	An often requested feature in Inkscape.
yes	SVG WG	SVG 2 should support hatching without the artifacts that patterns currently impose (See Pre-TPAC meeting minutes)

Arbitrary fill

e.g. specify video or an image as a fill paint source. Someone said this was just texture mapping, but it's not. Texture mapping is mapping a 2D thing onto a 3D surface using anisotropic scaling, mip-maps or whatever technique you like. What I mean here is still plain 2D. It would allow video for example be the fill of an object (nice for video fonts:-) Also an SVG image could be a fill. Most of this could be done with clip paths too, but it would be much easier to avoid the clip-path route since that is not as flexible since you could animate a rectangle/path etc. and then you're dealing with one object alone. From a model point of view I can't see why this should be difficult.

— Alex Danilo (personal wish-list)

This is ISSUE-2371.

Maybe Tab's Image Values work solves this?

Comments
yes	Chris	This is just another paint server, easy to specify.
yes	SVG WG	SVG 2 shall support filling and stroking from arbitrary elements (See Pre-TPAC meeting minutes)

SVG using WebGL filters

— Charles Pritchard

Comments
maybe	Chris	May already be covered by shaders in customFilter
yes	SVG WG	SVG 2 shall support custom filters (See Pre-TPAC meeting minutes)

Consider adding an href to the style element to link to external stylesheets

ISSUE-2049