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

<use> 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 <animation> 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 <image> 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 <svg>

ISSUE-2252

Comments
yes	SVG WG	We will allow transform on <svg> in SVG2. (see Pre-TPAC meeting minutes)

Add @allowReorder to <switch> 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 <use>

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 <color> 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

Add HTML5 style-element attributes to SVG's style element

This is for media and scoped, at least.

ISSUE-2240

Comments
yes	Chris	Obvious addition, for consistency and compatibility. Easy to add.
yes	SVG WG	SVG 2 style element shall be aligned with the html5 style element (See Pre-TPAC meeting minutes)

Transforms, Coordinate Systems, Units

Alternative transforms

mesh, wrap, spherical, conic, Mercator

— David Dailey

perspective transforms (I think 2.0 already has these)

— David Dailey

continue efforts with 3D-transformation (compatible with current SVG transformations of course)

— Olaf Hoffmann

consider how often graffiti flows into rectangles

— David Dailey

to allow glyphs to be squished into convex polygons

— David Dailey

Comments
maybe	Tav	Inkscape users would like a perspective transform. We have several features to simulate or produce perspective effects including a 3-D box tool.
maybe	Chris	Yes to perspective transforms. For arbitrary transforms as used in mapping (Mercator etc) maybe, but a fixed list is problematic. Would it be possible to support a customTransform where the user supplies the forward and reverse mapping (ie not restricted to transforms expressible as a matrix)?
no	SVG WG	SVG 2 will not include alternative transforms, in the absence of a convincing proposal (See Pre-TPAC meeting minutes)

Support getting bounding boxes that include stroke and/or markers

in hopes that something like getStrokedBBox() could be added to SVG 2.0. There are times that one would want to know the actual footprint of something with its stroke.

— David Dailey

Comments
yes	Tav	Inkscape has two internal bounding box routines, "visual" that includes and "geometric" that doesn't include strokes and markers. They both have their uses, especially in tilings.
yes	Chris	We had resolved in the SVG 1.1SE timeframe to add this for SVG2 (paintedBBox or something). Should include stroke; we were unsure about whether it shouldinclude the effect of filters. Markers depends on the resolution of the markers issue.
yes	SVG WG	SVG 2 shall include better bounding-box querying functions (See Pre-TPAC meeting minutes)

Consider allowing rotations to be relative to their bounding box center

ISSUE-2208

This may already be resolved with the Transforms FX work.

Comments
yes	Chris	Already covered by CSS transforms, need to add corresponding markup syntax.
yes	SVG WG	we will ensure there is a way to specify rotations around particular points and shapes (See Pre-TPAC meeting minutes)

Paths

Shared paths

Required for mapping and boundaries of countries etc. I can remember Andreas asking for this nearly a decade ago - this should be high priority IMO.

— Alex Danilo (request observed over the years)

Form the intersection of superpath, vector effects and connectors, preserving basic topology of orientation. (Markup-based relations between DOM objects need to be known, whether in SVG or in HTML5 or both)

— David Dailey

Comments
yes	Chris	Not so concerned about topology and about connectors, but the compound path formulation from vector effects does not belong there (unlike the others, it draws directly) and should be merged with superpath to provide a way to reuse path components to make paths that fill and shapes which abut correctly without anti-aliasing artifacts (because the renderer knows they share a boundary). Useful for mapping amongst other things; reduces filesize and increases rendering fidelity.
yes	Tav	Chris sums it up.
yes	SVG WG	We will have a solution to shared path segments in SVG2. (See Pre-TPAC meeting minutes)

Connectors

— Doug Schepers (nice to have)

— Paul Williams (nice to have)

Comments
yes	Tav	Inkscape includes some connector support. A group is currently working on improving that support. There is interest in developing a proposal for submission to the working group for including connectors as part of SVG 2.0.
no	SVG WG	SVG 2 will not have connectors, but we will continue its work as a separate module/spec (see meeting minutes)

Skeleton frames

— Doug Schepers (nice to have)

pattern along the stroke more advanced than stroke-dasharray, even if this becomes defined

— Olaf Hoffmann

Comments
yes	Tav	A great feature that Inkscape simulates. See lizard example.
yes	Tav	Inkscape has an "LPE" (Live Path Effect) that does this. This is a high demand item.
yes	Chris	Much easier to animate a skeleton than the flattened path which wraps it.
no	SVG WG	We will not have skeleton paths in SVG2, but we will work on it in a separate module. (See Pre-TPAC meeting minutes)

Replicate

— David Dailey

Comments
no	SVG WG	We will not include replicate in SVG2 unless accompanied by concrete use cases and demonstration of author/implementor interest. (See Pre-TPAC meeting minutes)

Turtle graphics

extensions of <path> that include classic turtle graphics, parentheses and iteration, and relative coordinates"

— David Dailey

The rotation/forward commands from turtle graphics are ISSUE-2288.

Comments
no	SVG WG	We will not include general turtle graphics in SVG2 without examples of practical reasons to do so.(See Pre-TPAC meeting minutes)

Smooth curves through points

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)

— Olaf Hoffmann

This is covered by Doug's Catmull-Rom curves I believe, which came out of ISSUE-2282.

Comments
yes	Chris	Yes and already covered by Catmull-Rom. Same method could be used to produce linear and radial gradients without gradient discontinuities. Yes I need to write that up since apparently its only obvious to me :)
yes	SVG WG	We will include smooth path between points functionality in SVG2. (See Pre-TPAC meeting minutes)

Polar coordinates for paths

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

— Olaf Hoffmann

Comments
yes	SVG WG	SVG 2 will make it simpler to construct regular polygons and stars (see TPAC Day 5 Meeting minutes)

Introduce element-based path syntax

This is element-based path syntax.

ISSUE-2050

Comments
maybe	SVG WG	Will be discussed with EXI WG

Look at making path arcto command work with drawing 360 degree arcs

ISSUE-2290

Comments
yes	SVG WG	SVG 2 will make arcs in paths easier (see TPAC Day 5 Meeting minutes)

Basic Shapes

Polar element

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.

— Olaf Hoffmann

This is ISSUE-2272.

Comments
no	SVG WG	SVG will not add a polar element (see TPAC Day 5 Meeting minutes)

Define <shapePath> element

ISSUE-2315

Define a <shapePath> element, similar to <textPath>, but for laying out shapes.
Use Cases:

positioning shapes relative to one another

more advanced markers

easy complex animations

complex borders

Considerations:

animation along a path, in addition to animating the path itself

spacing of shapes along the path (different options)

alignment of shapes relative to baseline

orientation of shapes along baseline

shapes of different sizes

scaling shapes automatically?

effect of transforms and positional/geometric attributes with respect to baseline

Comments
yes	SVG WG	SVG 2 will allow objects to be positioned along a path (see TPAC Day 5 Meeting minutes)

Text

Text flow to arbitrary shapes

— Doug Schepers (must have)

Flow charts, organisational charts, heck _lots_ of use cases. The WG designed this for years for 1.2 Full, Inkscape implemented it and then it vanished due to Mobile obsession or some other reason. I would really like to be able to shove some text into a diamond without pain.

— Alex Danilo (request observed over the years)

Comments
maybe	Cameron	I don't want to see separate mechanisms for text-in-shapes for SVG and for CSS. Will CSS Regions and Exclusions work for us here? Perhaps in conjunction with simpler inclusion of CSS-formatted text in SVG in general?
yes	Tav	This is a real sore point for Inkscape, to have had this yanked out from under their feet. Inkscape still does flow text as was defined by the spec. This is a high demand item.
maybe	Chris	On the one hand this is a much requested feature from the content creator and authoring communities. On the other hand it was a strong button-pusher for the browser and CSS communities, and CSS3 is finally adding this with CSS3 [exclusions] and [regions].
yes	SVG WG	SVG 2 will require automatic text wrapping in arbitrary shapes compatible with CSS (see conference call minutes)

Enhanced text support

to allow multiple alignment of text along multiple lines: base, top and middle

— David Dailey

Comments
yes	SVG WG	SVG 2 will support glyphs being aligned to different baselines, perhaps by using existing or improved CSS properties (see meeting minutes)

Label placement

magnetism/gravity that allows labels of geographic entities to draw their labels (is not difficult in today's computational environment since most of 2D physics avoids undecidability)

— David Dailey

Comments
no	SVG WG	SVG 2 will not have dynamic placement unless a more concrete proposal is made (see conference call minutes)

Textpath method="stretch" definition

Tighten up the definition of method=stretch so that it requires stretching glyphs to fit the path.

— Israel Eisenberg

— Seattle F2F discussion

— Issue summary by TB

Comments
yes	SVG WG	SVG 2 will clarify the stretch method for textpath. (see conference call minutes)

Flip-invariant text

If I define a symbol or other re-usable object containing text, and then use that object with the transform "scale=(-1,1)", then the text will render backwards. There should be a way to declare text to always read in the declared orientation (e.g., left-to-right).

— R. Timothy Edwards

— ISSUE-2289

Comments
yes	Chris	There is no easy way to ensure this currently, but its easy to specify at the spec level.
yes	SVG WG	SVG 2 will have a way to specify flip-invariant text (see conference call minutes).

Use CSS 'white-space' instead of 'xml:space'

This probably falls under the general desire to utilise more CSS properties, which we discussed in Seattle.

ISSUE-2172

Resolution: SVG2 will use CSS3 definitions for text layout (whitespacing, bidi, etc) that is not specific to SVG

Comments
yes	Chris	We already agreed to do this as part of the list of CSS3 modules depended on by SVG2. Already removed xml:space tests from SVG 1.1 testsuite.
yes	SVG WG	SVG 2 will deprecate the use of xml:space to affect layout and will use the CSS white-space property (see Conference call minutes)

Allow @transform to apply to <tspan> elements

ISSUE-2316

Comments
yes	SVG WG	SVG 2 will allow transforms on tspan (see Conference call minutes)

Gradients and patterns

New gradients

— Doug Schepers (must have)

including at least some of:

replicate

contours

diffusion curves

— David Dailey

— Olaf Hoffmann

Advanced pattern methods

— Olaf Hoffmann

After exchanging emails with Dr. Hoffmann there are several items he would like addressed. One is being able to specify other symmetries (there are 17 tiling symmetries). Another is a more clear treatment of how to handle overlaps between tiles and how tiles line up at boundaries. He states that there are inconsistencies between browers in how they render patterns.

Comments
maybe	Erik	It's not clear what exactly is being requested.
no	SVG WG	The requirement is not accepted unless a concrete proposal is made (see Conference Call minutes)

Multimedia

Video/audio on demand

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

— Olaf Hoffmann

Comments
yes	SVG WG	SVG 2 will have a video element in SVG namespace with the same characteristics as the HTML 5 video element TPAC minutes

Free audio/video codec requirements

explore the option to get free and then required formats for audio and video in SVG (similar as PNG and JFIF/JPEG is required).

— Olaf Hoffmann

Comments
yes	Chris	Would be great if we could. Should certainly be explored. Some recent activity in W3C about this, free profile of H.264
no	SVG WG	We support the goal, including for the whole web platform, but it does not seem feasible at the moment (see Meeting minutes)

Interactivity

Tooltip

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.

— Olaf Hoffmann

Comments
yes	SVG WG	SVG2 will have stronger requirements for when to display tooltips (see meeting minutes)

Hit-testing on image alpha

This has been asked for - but if we add it for PNG, then we could have the: <path> becomes <image> then you get hit-testing the same from the flattened to image version as with the original path data, only no DOM for the path(s) that made the original image.

— Alex Danilo (personal wish-list)

Comments
yes	SVG WG	SVG 2 will support pointer events sensitive to alpha, subject to security constraints (see meeting minutes)

Anchor events (anchorActivated, anchorTargeted)

ISSUE-2311

This might be solved by importing onhashchange from HTML.

Comments
yes	SVG WG	SVG 2 will consider adding HTML document wide events (including hashchange) apply to SVG documents when they make sense (see meeting minutes)

Consider adding drag and drop functionality

ISSUE-2274

Comments
yes	SVG WG	SVG2 may require drag&drop functionality, and we'll investigate html5's functionality for that (see meeting minutes)

Detect if a mouse event is on the fill or stroke

Is there any way to run one code-path when a user clicks the fill and another when the user clicks the stroke of a particular element? I know I could use pointer-events to limit clicks to one or the other, but is there a way to detect which was actually clicked?

Use-case: it's for a tshirt design application where users can add arbitrary SVGs to the shirt and then color them by clicking on the images, so if they click the border I want to change the stroke color, not the fill color.

— Shea Levy

Comments
maybe	Erik	It might be out-of-scope for SVG (would probably require changes to the MouseEvent/UIEvent interface), but it would be nice functionality to have.
yes	SVG WG	SVG 2 will make it easier to detect if an mouse event is on the stroke or fill of an element (see meeting minutes)

Scripting

Consider allowing async/defer on <svg:script>

ISSUE-2230

To align with HTML.

Comments
yes	SVG WG	SVG 2 will allow async/defer on <svg:script> (see Conference call minutes)

Animation

SMIL data feedback

as per STELLA circa 1986 on Macs -- see http://www.iseesystems.com/softwares/Education/StellaSoftware.aspx

— David Dailey

Comments
no	SVG WG	SVG 2 will not have SMIL data feedback until we accept requirement after clarification (see meeting minutes)

SMIL time containers

adopt SMIL time containers (layers)

— Olaf Hoffmann

Comments
yes	Chris	Already added in SVGT 1.2,should be added in SVG2
yes	SVG WG	SVG 2 will support the feature of SMIL time containers (see meeting minutes)

SMIL time manipulation module

adopt SMIL time manipulation module (accelerate, decelerate, speed, autoreverse)

— Olaf Hoffmann

— ISSUE-2155

Comments
yes	SVG WG	SVG 2 will solve animation reversing (see Sydney F2F meeting minutes )
yes	SVG WG	We will have support for non-negative speed on time containers (if we decide to include time containers) in SVG2 (see Sydney F2F meeting minutes)

Function-based input for <animate>

Extensions of the timing module of svg <animate> to include the ability to draw upon functional input from multivariate sources (rather than just keysplines and keytimes --as with <replicate>), e.g., from multiple curvilinear 2D paths.

— David Dailey

Comments
yes	SVG WG	SVG 2 will support path-based animations of pairs of attributes (see Conference call minutes)

to-animateTransform definition

to-animateTransform define/clarify how to get a smooth change from current to to-value

— Olaf Hoffmann

Comments
yes	SVG WG	SVG 2 will attempt to define all explicitly undefined parts of the SVG 1.1 spec (see Sydney F2F minutes).

animateTransform type matrix

allow animateTransform of type matrix

— Olaf Hoffmann

Comments
yes	SVG WG	We will allow animateTransform with type equals matrix in SVG2 (see Sydney F2F meeting minutes)

Declarative animation value conservation/use

declarative method to conserve and reuse current values from animation in animation

— Olaf Hoffmann

Comments
no	SVG WG	We will not add getValue/setValue for animation value conservation and reuse without convincing use cases (see Sydney F2F meeting minutes )

Improve to-animations

improve to-animation approach to get something similar to CSS-transitions within SVG animation.

— Olaf Hoffmann

Comments
yes	SVG WG	SVG 2 will allow CSS-transitions-like animations (see Sydney meeting minutes)

Transitions for discretely animated properties, text-anchor in particular

animation from text-anchor="start" to "middle" or "end" doesn't cause a smooth transition from one position to the next.

— pho0

Comments
yes	SVG WG	SVG2 will allow linear interpolation for properties which were previously discrete (see Sydney meeting minutes)

Support for animations of transform lists

ISSUE-2279

This is a proposal to add a type="list" to animateTransform for decomposed matrix transform list animation.

Comments
yes	SVG WG	SVG 2 will support animation using a transform-list

Look at making paced animation easier

ISSUE-2281

The brief proposal here is to allow something like pace="10px/1s" to set the duration of an animation.

Comments
yes	SVG WG	We will support motion animation of a specified speed in SVG2. (see Sydney meeting minutes)

Implementation requirements

Basic SVG UI enhancements

enhanced browser consistency in basic SVG interface

consistency of zoom and pan (give us a widget if you can't agree!)

a drawing widget
Rationale: HTML (hyperTEXTmarkuplanguage) has <textarea>
<textarea> comes armed with word-wrap, backspace/delete, newline/return, cursor insertion, selection/replacement, copy/paste (&rich text attributes?)

Donc/therefore: SVG (svGRAPHICS) should have <tablet>
<tablet> could come armed with basic drawing tools (polygon, Bezier, select, delete, copy/paste Drag, resize, rotate)

layers control (as with Photoshop layers)

— David Dailey

Comments
no	SVG WG	SVG 2 will not have basic UI elements (see Sydney meeting minutes )

Specify that unknown elements are treated as <g> elements for the purpose of rendering

ISSUE-2350

Comments
yes	SVG WG	SVG 2 will have unknown elements treated as <g> for the purpose of rendering. The groups wants community feedback on how much content would be impacted.(see Sydney meeting minutes)

Specify how SVG graphics and text are copy/pasted

ISSUE-2367

Comments
yes	SVG WG	SVG 2 will specify how SVG graphics and text are copy/pasted (see Sydney meeting minutes)

Extensibility

Consider removing the requirement for @width and @height for <foreignObject>

ISSUE-2054

Comments
no	Chris	Needed for handoff to box-model formatter which needs the dimensions of the outermost containing block
yes	SVG WG	SVG 2 will remove the requirement to have @width and @height on foreignObject (see Sydney meeting minutes).

Feature strings

Consider the future of feature strings and the switch element

ISSUE-2422 - Define switch to work with unknown elements and processing behaviour for audio elements etc

Comments
yes	SVG WG	SVG 2 will improve the fallback mechanism using switch (see Sydney meeting minutes)

Tracker issues

Below are the issues currently raised against the SVG2 component in tracker that we should consider in our requirements drafting process.

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.

Consider adding API for saving and restoring SVG state

This is for generating a snapshot of some dynamically modified or animated SVG content.

ISSUE-2063

Comments
no	SVG WG	SVG 2 will not add an API for saving and restoring the SVG state (see Sydney meeting minutes])

Consider treating audio separately to graphics

This is introducing properties to control whether the audio from a video or audio element is audible.

ISSUE-2069

Comments
yes	SVG WG	SVG 2 will provide a way to control audio level and playback. (see Sydney meeting minutes )

Consider adding new interface for easier use of positional properties

This is a proposal for a UIEvent.getPosition() method to get transformed points out of an Event object.

ISSUE-2182

Comments
yes	SVG WG	SVG 2 will provide positioning information in MouseEvents. (see Sydney meeting minutes)

Consider adding method to return array of declarative timeline

ISSUE-2218

It might be useful, when integrating SMIL animation and script, for the author to be able to get a summary of the current declarative timeline, with the start time, duration, declaring element, and target element, for each animation. This might include those animations that are undefined or depend upon UI events.

Comments
no	SVG WG	The WebAnimations proposal will provide an API to get animation timeline information (i.e., current state of the timing engine, running animations, pending animations , frozen animations etc...). SVG 2 will not address this requirement directly. (See Sydney meeting minutes)

CSS3 Color syntax in SVG

ISSUE-2224

I think we have already resolved this at Seattle 2011.

Comments
yes	SVG WG	Already decided and widely implemented

Align with CSS WG preserveAspectRatio

ISSUE-2237

Making image-fit work. Again, probably falls under the "we'll make most CSS properties work with SVG" direction.

Comments
yes	SVG WG	SVG 2 will work with CSS image-fit. (see CSS Spec Dependencies)

Should be possible to determine intrinsic size of an image

ISSUE-2293

This would be a DOM interface, I think. Related to the #Auto-sized_image request above.

Comments
no	SVG WG	SVG 2 will not provide a separate interface to get image intrinsic size because it will be possible to query the size on the SVG image elements. (see Sydney meeting minutes)

Consider adding convenience methods for currentScale/currentTranslate

ISSUE-2296

It would be convenient for both authors and implementations for SVG to define a couple new methods, zoom() (or setZoom()) and pan() (or setPan()), to allow set the centerpoint of the viewport and optionally zoom. These would modify the values of the currentScale and currentTranslate properties.

zoom(zoom-level, optional-cx, optional-cy)

pan(cx, cy)

UAs can offer these to users as part of the UI, and authors could use them as a more convenient way to zoom and pan to a specific center-point without having to calculate the viewBox, etc.

Comments
yes	SVG WG	SVG 2 will make it easier to write a zoom/pan widget, possibly by adding convenience method to get scale/transfer (see Sydney meeting minutes)

Align with CSS Value and Units

ISSUE-2300

This is just to reference css3-values. We have a resolution on this already.

Comments
yes	SVG WG	Already agreed

Gzip-compressed svg in data URIs

ISSUE-2313

Comments
maybe	Chris	Nice to have, requires an update to RFC 2397
no	SVG WG	Out of scope for SVG 2 (see Sydney meeting minutes)

Deprecate baseline-shift and use vertical-align instead

ISSUE-2322

Comments
yes	SVG WG	SVG 2 will deprecate baseline-shift and use vertical-align (see Sydney meeting minutes)

Media elements in SVG need ability to associate captions and description

ISSUE-2324

Comments
yes	Chris	Needed for accessibility and alignment with HTML5, need to look at WebVTT which [might get a WG]
yes	SVG WG	SVG 2 will allow video elements to have captions, tracks, etc (see Sydney meeting minutes)

Consider adding a 'inverse' value to clip-rule

ISSUE-2354

Comments
yes	Tav	Requested by several Inkscape users.
yes	Chris	Useful functionality.
no	SVG WG	Since it easy to do in masks and difficult to do in geometry, we will not make it part of SVG 2 (see Sydney meeting minutes)

Consider allowing the 'clip-path' property to reference any element, not just 'clipPath'

ISSUE-2355

Comments
yes	Tav	Requested by Inskcape users. Also, Inkscape allows use of <g> while others require that each element in a group be explicitly added inside a <clipPath>.
yes	SVG WG	SVG 2 will allow clip to to reference any element (see Sydney meeting minutes)

Consider adding renderedWidth/renderHeight properties to SVG root

ISSUE-2356

We should look into a new set of DOM attributes for getting the final rendered width and height of the SVG document or fragment in pixels. For external documents, this can be detected with innerWidth/innerHeight, but it is more difficult for inline content.

Comments
no	SVG WG	The properties already exist (see SVG 1.1 and Sydney meeting minutes)

Consider adding a fixed-stroke property

ISSUE-2357

Slightly different from vector-effect="non-scaling-stroke"; this one is to handle the case when the SVG document is in an iframe (say) which itself is scaled down.

Comments
no	SVG WG	The current non-scaling stroke already defines this behavior (see Sydney meeting minutes)

Consider allowing geometry to be defined using properties

ISSUE-2359

Seems to be a request to promote some geometry attributes to properties.

Comments
no	Chris	Property bloat as all elements have all properties. Risk of collision, and confusion from renaming the over-generic names. This is a bad way to cope with the limitation that CSS animation can only animate properties, not attributes.
yes	SVG WG	SVG 2 will promote some attribute to properties according to Patrick's proposal (see Sydney meeting minutes)

Consider adding a 'key()' keyword for animation triggers

ISSUE-2362

This would take DOM 3 Events key identifiers, compared to accessKey().

Comments
yes	SVG WG	SVG will support animation triggers based on keyboard input, pending a proposal on security issues (see meeting minutes)

Consider adding a property for autoscaling

ISSUE-2378

Comments
no	SVG WG	SVG 2 will not add a property for autoscaling (see Sydney meeting minutes)

Consider adding advanced font metrics interface

ISSUE-2379

Comments
yes	SVG WG	SVG 2 will have an advance font metrics interface (see Sydney meeting minutes)

Consider making svgz files just as valid and useful as svg files

ISSUE-2388

Comments
yes	SVG WG	SVG 2 will clarify that svgz should be as usable everywhere svg files can (see Sydney meeting minutes)

Consider allowing CSS 'color' property to apply to 'fill'

ISSUE-2389

Comments
no	SVG WG	We already have currentColor for this. See also currentFillPaint and currentStrokePaint and Sydney meeting minutes

Consider adding a DOM method to convert a <text> element to outline path data

ISSUE-2425 - related to ACTION-3076 (CM)

Resolution to add an API for getting glyph outlines

Proposal page: Text to path API

Comments
yes	SVG WG	SVG 2 will have a DOM method to convert a <text> element to outline path data (see Sydney meeting minutes))

Simpler interpolation between two paths for animations

NURBS?

Comments
yes	SVG WG	SVG 2 will try to have simpler interpolation between two paths (see Sydney meeting minutes)

WOFF Support

Explicit support for Web Open Font Format (WOFF). See https://www.w3.org/Bugs/Public/show_bug.cgi?id=15410

Already resolved, see http://www.w3.org/2011/03/01-svg-minutes.html#item03

Comments
yes	SVG WG	Resolved at Auckland f2f

Features from SVG Tiny 1.2

New Document Structure features

the 'snapshotTime' attribute on the <svg> element

Comments
yes	SVG WG	SVG2 will add snapshot time for animated documents and may specify how to get at the rendered image (see conference call minutes)

the 'timelineBegin' attribute on the <svg> element

Comments
yes	SVG WG	SVG2 will support a means for having SMIL animations start before their time container has fully loaded (see meeting minutes)

the <discard> element

Comments
yes	SVG WG	SVG 2 will support the discard element (see meeting minutes)

the 'playbackOrder' attribute on the <svg> element

This attribute is linked to the use of the <discard> element.

Comments
yes	SVG WG	SVG 2 should support the playbackOrder attribute to inform UA to not display controls to seek backwards (see meeting minutes)

the 'requiredFonts' and 'requiredFormats' conditional processing attributes

Comments
yes	SVG WG	SVG 2 will adopt the requiredFonts attribute (see conference call minutes)
no	SVG WG	SVG 2 will not adopt the requiredFormats attribute (see conference call minutes)

the Progressive Rendering algorithm

Comments
yes	SVG WG	SVG2 will define progressive rendering more precisely, drawing on SVG Tiny 1.2 and HTML 5 (see conference call minutes)

the <prefetch> element

Comments
no	SVG WG	SVG2 will not add the prefetch element but will clarify when resources start downloading (see conference call minutes)

<ed> i would like us to state whether resources start downloading as soon as you set the href, even if it's not appended to the document
<ed> similar to Image in html, e.g var img = new Image(); img.src = "foo"

the <solidColor> element

Comments
yes	Tav	Inkscape simulates this by using (abusing?) 1-stop gradients.
yes	Chris	Useful way to re-use named colours and to animate all uses of that colour.
yes	SVG WG	SVG 2 will add the solidColor element and its properties (see meeting minutes)

Common Attributes to all elements

xml:id

Comments
no	Chris	xml:id has not gained traction among W3C specs
no	SVG WG	SVG 2 will not add xml:id (see meeting minutes)

role, rel, rev, about, content, datatype, property, resource, typeof

Comments
yes	Chris	Added to 1.2T for ARIA, RDFa and microdata support
yes	SVG WG	SVG 2 will follow what HTML does for RDFa and microdata (see meeting minutes)

New Styling features

New properties

audio-level

Comments
yes	SVG WG	as previously resolved

buffered-rendering

Comments
yes	SVG WG	SVG 2 will add buffered-rendering (implementor feedback indicates that it is needed) (See resolution Auckland resolution (no) and meeting minutes (yes)).
yes	Erik	If people "abuse" CSS3D transforms to exactly the same thing (different name, same thing), that indicates that there's an actual need for it in some scenarios and on some devices.

display-align

Comments
no	SVG WG	SVG 2 will not add display-align since it will not have textarea (see meeting minutes)

line-increment

Comments
no	Chris	CSS community hated this, and wanted something more obviously compatible with CSS box model
no	SVG WG	SVG 2 will not add line-increment as it is linked to textArea (see meeting minutes)

solid-color

Comments
yes	SVG WG	Related to #the_.3CsolidColor.3E_element

solid-opacity

Comments
yes	SVG WG	Related to #the_.3CsolidColor.3E_element

text-align

Comments
no	SVG WG	SVG 2 will not add text-align as it is linked to textArea (see meeting minutes)

vector-effect

Comments
yes	Chris	Often requested functionality
yes	Erik	As an additional feature-request I would like to see a new shorthand keyword: stroke-below-fill (or equivalent).
yes	SVG WG	SVG 2 will have the vector-effect property (see meeting minutes)

viewport-fill

Comments
yes	SVG WG	Resolved at Brussels f2f: SVG 2 will keep viewport-fill and viewport-fill-opacity for zoom

viewport-fill-opacity

Comments
yes	SVG WG	Resolved at Brussels f2f: SVG 2 will keep viewport-fill and viewport-fill-opacity for zoom

New Transforms, Coordinate Systems, Units features

Constrained Transformations

Comments
yes	SVG WG	SVG 2 will have constrained transformations based on SVG 1.2 Tiny (see meeting minutes)

More precise definition of bounding box

Comments
yes	Erik	Needs to be defined precisely, and it should also be coupled with a large number of automated js tests using the new testing framework.
yes	SVG WG	SVG 2 will improve the bounding box text based on SVG Tiny 1.2 (see meeting minutes)

the Paths chapter

The SVG 1.2 Tiny Paths chapter does not seem to describe new features compared to SVG 1.1 2nd edition.

the Basic Shapes chapter

The SVG 1.2 Tiny Basic Shapes chapter does not seem to describe new features compared to SVG 1.1 2nd edition

New Text features

modified introduction, improved text about characters and glyphs, text layout, text selection, text search ...

Comments
yes	Chris	Improved text is improved
yes	SVG WG	SVG 2 will include the improved text from SVG Tiny 1.2 on characters and glyphs, text layout, text selection, text search (see meeting minutes)

the editable attribute

Comments
yes	Chris	Yes for the functionality, but align with content-editable instead
yes	SVG WG	SVG 2 will have the HTML content editable feature (see meeting minutes)

Consider adding scrolling to editable text

ISSUE-2373

Comments
maybe	SVG WG	see meeting minutes

the textArea element

Comments
no	Chris	The name, while meaningful to the graphics editing community, has an unfortunate clash with the HTML forms textarea element. While this is widely implemented functionality in authoring tools,the CSS community would rather see something that uses the CSS box model and would probably prefer an HTML div element (with arbitrary HTML children). But that is problematic for SVG-only authoring tools
no	SVG WG	Already resolved see Text flow to arbitrary shapes

the tbreak element

Comments
no	SVG WG	SVG 2 will not have the tbreak element unless compelling use cases are provided (see meeting minutes)

Multimedia features

the <video> element

Comments
yes	Chris	The markup has the advantage that it is integrated into the timing model unlike the HTML5 audio and video elements. The DOM on the other hand sucks and should be aligned with the HTML DOM for audio and video which is better.
yes	SVG WG	Already resolved (see Video on demand requirement)

the 'transformBehavior' attribute

Comments
yes	SVG WG	SVG 2 will have the transformBehavior feature in its spec or as part of the merged transform spec (see meeting minutes)

the 'overlay' attribute

Comments
no	SVG WG	SVG 2 will not add the SVG Tiny 1.2 overlay attribute because the Fullscreen API combined with the z-index property will cover the same use cases (see meeting minutes)

the <animation> element

Comments
maybe	Chris	Wr added this to align with SMIL which has separate elements for static graphics and animated vector graphics. We also made the animation element a time container while image was not a time container. We should revisit this decision for SVG2. Also, people found the name of the element confusing because of the animate* elements.
yes	SVG WG	SVG 2 will add the features of the SVG Tiny 1.2 animation element but not the element itself (see meeting minutes)

the <audio> element

Comments
yes	Chris	The markup has the advantage that it is integrated into the timing model unlike the HTML5 audio and video elements. The DOM on the other hand sucks and should be aligned with the HTML DOM for audio and video which is better.
yes	SVG WG	Already resolved (see Video on demand requirement)

Common attributes

initialVisibility

Comments
no	SVG WG	We will not add initialVisibility to SVG2 since it is possible to get the same effect with the HTML5 video features we will be bringing across.
no	Erik	Note that the lacuna value for 'initialVisibility' is 'whenStarted', which is different from HTML5 (default there is the same as 'always'), and that it would require the 'poster' attribute referencing a transparent image to get the effect of 'whenStarted'.

Run-time Synchronization attributes

These attributes are: syncBehavior, syncBehaviorDefault, syncTolerance, syncToleranceDefault and syncMaster.

Comments
yes	SVG WG	SVG 2 should have synchronization support from somewhere in the web platform (see meeting minutes)

audio-level

Comments
yes	SVG WG	as previously resolved

New Interactivity features

Focus navigation

the 'focusable' attribute

Comments
yes	Erik	Whole section on what is focusable and not should be moved over, in SVG 1.1 it's very unclear what elements can have focus and when.
yes	SVG WG	SVG 2 will have a solution for specifying focusability and navigation order, and be consistent with html (see meeting minutes)

the navigation attributes (nav-next, nav-prev ...)

Comments
maybe	Chris	Note that CSS3 Basic UI also covers this
yes	SVG WG	Already covered (see above)

the focusHighlight attribute

Comments
yes	SVG WG	SVG 2 will have a mechanism for controlling focus indication, consistent with CSS and HTML (see meeting minutes)

the Focus API: setFocus, moveFocus

Comments
no	Erik	Should be aligned with HTML DOM so that we don't get two ways for setting/getting focus. Document.activeElement and Element.focus().
yes	SVG WG	SVG 2 will support an API to control focus consistent with HTML (see meeting minutes)

Events

Key-related events: textInput, keydown, keyup

Comments
yes	Chris	But align with DOM3 Events
yes	SVG WG	SVG 2 will have support for key events from DOM Level 3 Events (see meeting minutes)

The SVGRotate event

Comments
yes	SVG WG	SVG 2 will have the SVGRotate event from SVG Tiny 1.2 (see meeting minutes)

Progress Events loadstart, progress, loadend

Comments
yes	SVG WG	SVG 2 will support progress events using the html 5 method (see meeting minutes)

The SVGTimer event

Comments
no	SVG WG	SVG 2 will not have the SVG 1.2 Tiny timer event (see meeting minutes)

The MouseWheel event

Comments
yes	Erik	We should have a mousewheel event, but I'm not sure we need to include it in the spec like we did for SVG Tiny 1.2. It should be enough to reference the spec that defines it, DOM 3 Events or its successor.
yes	SVG WG	SVG 2 will support the mousewheel event as defined in the DOM specifications (see meeting minutes)

Modified sections for hit testing, event processing, ...

Comments
yes	SVG WG	SVG 2 will adopt improved svgt1.2 text on hit testing and event processing (see meeting minutes)

XML Events

Comments
no	Erik	Make a separate module for all things XMLEvents-related in Tiny.
no	Chris	xml events did not get traction, conflicts with HTML5
no	SVG WG	SVG 2 will not support xml events (see meeting minutes)

the <listener> element

Comments
no	Chris	xml events did not get traction, conflicts with HTML5
no	SVG WG	SVG 2 will not support xml events (see meeting minutes)

the <handler> element

Comments
no	Chris	xml events did not get traction, conflicts with HTML5
no	SVG WG	SVG 2 will not support xml events (see meeting minutes)

XML EVents namespace: 'ev:' for the 'events' attribute on the handler element and for the listener element

Comments
no	Chris	xml events did not get traction, conflicts with HTML5
no	SVG WG	SVG 2 will not support xml events (see meeting minutes)

New Linking features

Reference Restrictions

Comments
yes	Chris	Useful spec text, port over
yes	SVG WG	SVG 2 will adopt the improved wording on Reference Restrictions (see meeting minutes)

Processing External References

This concerns the concept of primary document vs. resource document.

Comments
yes	Chris	Useful spec text, port over
yes	SVG WG	SVG 2 will adopt the improved wording on Processing External References (see meeting minutes)

Xlink additional attributes on the <a> element

This concerns the xlink:role, xlink:arcrole and xlink:title attributes.

Comments
no	Chris	Only xlink:href was useful (and prefix is being dropped) the rest are useless and never used in practice. Drop.
no	Erik	There is some use of xlink:title, and there is a title attribute in html5 [1]. But xlink:role and xlink:arcrole can be dropped I think.
no	SVG WG	SVG 2 will drop the xlink attributes role, arcole, title( see minutes)

indicating links

Comments
yes	Chris	Improved text is improved
yes	SVG WG	SVG 2 will include port the text from SVG Tiny 1.2 on Indicating links (see meeting minutes)

Improved text for fragment identifiers link traversal

Comments
yes	Chris	Improved text is improved
yes	Erik	Yes, but I think we should have a look at the syntax overall and there are parts in 1.1 which aren't in 1.2T. Also we should consider media fragments.
yes	SVG WG	svg2 will merge the svg1.1se text and the svgt12 text on fragment identifiers link traversal and add media fragments (see meeting minutes)

Added text for Processing Inline Script

Comments
yes	SVG WG	SVG 2 will define how inline scriptable content will be processed, in compatible way to HTML5 (see meeting minutes)

New Scripting features

script element text

There are some differences between SVG 1.1 2nd ed and SVG 1.2 Tiny.

Comments
yes	Chris	Improved text is improved
yes	SVG WG	SVG 2 will merge SVG Tiny 1.2 improved text on the script element (see meeting minutes)

Script Processing

Comments
yes	Erik	The script processing model is mostly undefined in 1.1, so we should probably move the relevant parts from 1.2T over when editing SVG2. We should align with the html script element. This section is referenced by html5 for dealing with script elements in svg fragments [2].
yes	SVG WG	SVG 2 will use the relevant parts from 1.2T and align with the html script element (see meeting minutes).

the Animations chapter

The Animation chapter of SVG Tiny 1.2 does not seem to have modifications compared to SVG 1.1 2nd edition.

ED: There are some minor modifications, like definining what happens when there are errors in a begin-value-list for example.

Comments
yes	Erik	We should accept the changes that were made, this could be considered the same as relaxed document error handling.
yes	SVG WG	SVG 2 will apply the changes from SVG Tiny 1.2 Animations chapter (see meeting minutes)

Fonts

The Fonts chapter of SVG Tiny 1.2 does not seem to have modifications compared to SVG 1.1 2nd edition.

Extensibility

the xlink:href attribute on <foreignObject>

ISSUE-2096

Comments
yes	SVG WG	SVG 2 will support xlink:href on fo element after security verification (see meeting minutes)

Micro DOM

Comments
maybe	Erik	My maybe here means yes to some and no do some :) Can this be broken down into smaller chunks please? E.g there are some minor changes to the SVGSVGElement, SVGMatrix, SVGLocatable interfaces, some completely new interfaces like SVGPath, SVGRGBColor, TraitAccess, SVGTimedElement, SVGAnimationElement, SVGVisualMediaElement, SVGTimer, SVGGlobal, AsyncStatusCallback, AsyncURLStatus, EventListenerInitializer2. Some subsetting of DOM Core and DOM Events interfaces, and progress events.
yes	SVG WG	SVG 2 will not merge the MicroDOM as is but will use it as input into the DOM improvement designs (see meeting minutes)

Relaxed document error handling (lacuna values etc)

Comments
yes	Erik	Relaxed error handling, aka lacuna values, is so much nicer to work with than having to stop all rendering.
yes	Chris	I luv lacuna values. lacuna matata.
yes	SVG WG	SVG 2 will have relaxed document error handling (with lacuna values etc.) as defined in Tiny 1.2 (see meeting minutes)

Masks using alpha or luminance

Comments
yes	SVG WG	SVG 2 will allow masks to use either alpha or luminance or both (see meeting minutes)
yes	SVG WG	SVG 2 will relax restriction on masks pointing to mask element only (see meeting minutes)

Late Proposed Requirements

Array element

email from Koray Inal

Related resolution: use element cleanup.

Comments

Half-tone (Screening/Pattern filter)

email from Ivan Louette

See Screening Filter Primitive Examples

Comments

Multipage support

Frequent request from Inkscape users. Inkscape bug report (with 10 duplicate bugs)

Comments

Variable stroke opacity

Comments

Gradient along/across stroke

Comments
yes	Tav	An easy way to create gradients that would be difficult to do any other way. Now supported by some drawing software.

New Stroke Join

Comments
yes	Tav	The current Miter choice doesn't look good when the adjacent path segments are curved. An "Extrapolated" join where the curvature of the paths is used determine the shape of the Miter yields a better looking join. This has been implemented in Inkscape as part of the Powerstroke "Live Path Effect".