SVG2 Requirements Input
From SVG
Resolutions
See SVG2_Resolutions page.
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)
| 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/
| 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!
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
- 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?)
| Comments | ||
|---|---|---|
| yes | SVG WG | Accepted (see resolution) |
Commitment: add your company name or individual (if not working for a company)
Translucency
modeling translucency beyond transparency
| 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.
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
Document Structure
Namespace requirements cleanup
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 |
Commitment: add your company name or individual (if not working for a company)
<use> cleanup
| 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) |
Commitment: add your company name or individual (if not working for a company)
Shadow tree cleanup
| 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) |
Commitment: add your company name or individual (if not working for a company)
Marker cleanup
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) |
Commitment: add your company name or individual (if not working for a company)
Improve the DOM
— 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) |
Commitment: add your company name or individual (if not working for a company)
Improve the DOM for SVG Animation
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) |
Commitment: add your company name or individual (if not working for a company)
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.
| 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) |
Commitment: add your company name or individual (if not working for a company)
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.
— Canvas-like path creation API
| Comments | ||
|---|---|---|
| yes | SVG WG | We will improve the SVG path DOM APIs in SVG2. (see Pre-TPAC meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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?
| 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) |
Commitment: add your company name or individual (if not working for a company)
Make it possible to get the bounding box of an element in a particular coordinate system
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) |
Commitment: add your company name or individual (if not working for a company)
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. |
| no | SVG WG | We won't include automatic fetch/discard in SVG2 (see Pre-TPAC 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...
| 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
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) |
Commitment: add your company name or individual (if not working for a company)
Auto-sized image
define a method to reference raster images with its own size without the need to set width and height
| 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) |
Commitment: add your company name or individual (if not working for a company)
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). |
Commitment: add your company name or individual (if not working for a company)
Display of InkML trace groups
| Comments |
|---|
Placeholder graphics for unresolved images
Consider adding placeholders or fallback for unresolved resources
| 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>
| Comments | ||
|---|---|---|
| yes | SVG WG | We will allow transform on <svg> in SVG2. (see Pre-TPAC meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Add @allowReorder to <switch> for improved language-based switching
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) |
Commitment: add your company name or individual (if not working for a company)
Allow referencing root external files with <use>
| 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) |
Commitment: add your company name or individual (if not working for a company)
Attributes
Parameters
— Doug Schepers (must have)
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) |
Commitment: add your company name or individual (if not working for a company)
Custom data-* attributes
(This should be grouped as an HTML5/XML item - ed)
| 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) |
Commitment: add your company name or individual (if not working for a company)
Randomization
extensive support for randomization (random attribute values, etc)
| 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).
For microdata, this is for itemscope, itemtype, itemid, itemref, and itemprop attributes.
| Comments | ||
|---|---|---|
| yes | SVG WG | we will align with HTML5 global semantic attributes where these make sense for SVG (See Pre-TPAC meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Consider relaxing case sensitivity of presentation attribute values
| Comments | ||
|---|---|---|
| yes | SVG WG | We will make property values case insensitive (See Pre-TPAC meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
Non-scaling stroke
— Doug Schepers (must have)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
Variable stroke width
— Doug Schepers (nice to have)
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) |
Commitment: add your company name or individual (if not working for a company)
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?
A stroke-position property to control where relative to the path a stroke is painted.
Proposal page: Stroke position
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 shall include a way to specify stroke-position (See Pre-TPAC meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will specify more precisely stroke dashing (See Pre-TPAC meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
SVG using WebGL filters
| 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) |
Commitment: add your company name or individual (if not working for a company)
Consider adding an href to the style element to link to external stylesheets
See also the next issue.
| Comments | ||
|---|---|---|
| no | SVG WG | SVG 2 will not add href to the <style> element (See Pre-TPAC meeting minutes) |
Add HTML5 style-element attributes to SVG's style element
This is for media and scoped, at least.
| 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) |
Commitment: add your company name or individual (if not working for a company)
Transforms, Coordinate Systems, Units
Alternative transforms
mesh, wrap, spherical, conic, Mercator
- perspective transforms (I think 2.0 already has these)
continue efforts with 3D-transformation (compatible with current SVG transformations of course)
consider how often graffiti flows into rectangles
- to allow glyphs to be squished into convex polygons
| 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.
| 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) |
Commitment: add your company name or individual (if not working for a company)
Consider allowing rotations to be relative to their bounding box center
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) |
Commitment: add your company name or individual (if not working for a company)
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)
| 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) |
Commitment: add your company name or individual (if not working for a company)
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. |
Skeleton frames
— Doug Schepers (nice to have)
pattern along the stroke more advanced than stroke-dasharray, even if this becomes defined
| 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. |
| yes | 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) |
Commitment: add your company name or individual (if not working for a company)
Replicate
| 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"
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)
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) |
Commitment: add your company name or individual (if not working for a company)
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
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will make it simpler to construct regular polygons and stars (see TPAC Day 5 Meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Introduce element-based path syntax
This is element-based path syntax.
| Comments | ||
|---|---|---|
| maybe | SVG WG | Will be discussed with EXI WG |
Commitment: add your company name or individual (if not working for a company)
Look at making path arcto command work with drawing 360 degree arcs
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will make arcs in paths easier (see TPAC Day 5 Meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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.
This is ISSUE-2272.
| Comments | ||
|---|---|---|
| no | SVG WG | SVG will not add a polar element (see TPAC Day 5 Meeting minutes) |
Define <shapePath> element
Define a <shapePath> element, similar to <textPath>, but for laying out shapes. Use Cases:Considerations:
- positioning shapes relative to one another
- more advanced markers
- easy complex animations
- complex borders
- 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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
Enhanced text support
- to allow multiple alignment of text along multiple lines: base, top and middle
| Comments |
|---|
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)
| 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.
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will clarify the stretch method for textpath. (see conference call minutes) |
Commitment: add your company name or individual (if not working for a company)
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).
| 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). |
Commitment: add your company name or individual (if not working for a company)
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.
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) |
Commitment: add your company name or individual (if not working for a company)
Allow @transform to apply to <tspan> elements
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will allow transforms on tspan (see Conference call minutes) |
Commitment: add your company name or individual (if not working for a company)
Gradients and patterns
New gradients
— Doug Schepers (must have)
including at least some of:
- replicate
- contours
- diffusion curves
See also:
- ISSUE-2370 Investigate gradients along a path for SVG 2
- Mesh gradients resolution.
| Comments | ||
|---|---|---|
| yes | Cameron | That's a "yes" for gradient meshes, which we've already resolved upon. I don't think we need to consider additional gradients for the moment. |
| yes | Tav | I've already got code for Inkscape to create and edit gradient meshes. This is a high demand item. |
| yes | Chris | Strong demand and a great new SVG2 feature. Already resolved for gradient meshes which is probably sufficient. Other proposals had problems. Trimesh with delauney triangulation of a point cloud was investigated, had problems of discontinuities in gradient if Gouraud shading was used. Phong shading (as already used in lighting filters) was proposed but not investigated. Diffusion curves are more of a drawing primitive than a fill styleand can show significant variability between implementations, may not be well behaved mathematically. Gradients with Coons patches have been suggested, but lets see how well we do with the already agreed gradient mesh before adding this complexity. |
| yes | SVG WG | Mesh gradients are accepted by the WG for SVG 2.0 |
Commitment: add your company name or individual (if not working for a company)
Advanced pattern methods
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
| 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 |
Commitment: add your company name or individual (if not working for a company)
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).
| 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.
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG2 will have stronger requirements for when to display tooltips (see meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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 |
|---|
Anchor events (anchorActivated, anchorTargeted)
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) |
Commitment: add your company name or individual (if not working for a company)
Consider adding drag and drop functionality
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG2 may require drag&drop functionality, and we'll investigate html5's functionality for that (see meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Scripting
Consider allowing async/defer on <svg:script>
To align with HTML.
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will allow async/defer on <svg:script> (see Conference call minutes) |
Commitment: add your company name or individual (if not working for a company)
Animation
SMIL data feedback
as per STELLA circa 1986 on Macs -- see http://www.iseesystems.com/softwares/Education/StellaSoftware.aspx
| Comments |
|---|
SMIL time containers
adopt SMIL time containers (layers)
| Comments | ||
|---|---|---|
| yes | Chris | Already added in SVGT 1.2,should be added in SVG2 |
SMIL time manipulation module
adopt SMIL time manipulation module (accelerate, decelerate, speed, autoreverse)
| 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) |
Commitment: add your company name or individual (if not working for a company)
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.
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will support path-based animations of pairs of attributes (see Conference call minutes) |
Commitment: add your company name or individual (if not working for a company)
to-animateTransform definition
to-animateTransform define/clarify how to get a smooth change from current to to-value
| 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
| Comments | ||
|---|---|---|
| yes | SVG WG | We will allow animateTransform with type equals matrix in SVG2 (see Sydney F2F meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Declarative animation value conservation/use
declarative method to conserve and reuse current values from animation in animation
| 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.
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will allow CSS-transitions-like animations (see Sydney meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
Support for animations of transform lists
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 |
Commitment: add your company name or individual (if not working for a company)
Look at making paced animation easier
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) |
Commitment: add your company name or individual (if not working for a company)
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)
| 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
| 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) |
Commitment: add your company name or individual (if not working for a company)
Specify how SVG graphics and text are copy/pasted
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will specify how SVG graphics and text are copy/pasted (see Sydney meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Extensibility
Consider removing the requirement for @width and @height for <foreignObject>
| 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). |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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.
| 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.
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will provide a way to control audio level and playback. (see Sydney meeting minutes ) |
Commitment: add your company name or individual (if not working for a company)
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.
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will provide positioning information in MouseEvents. (see Sydney meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Consider adding method to return array of declarative timeline
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 | ||
|---|---|---|
| yes | 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) |
Commitment: add your company name or individual (if not working for a company)
CSS3 Color syntax in SVG
I think we have already resolved this at Seattle 2011.
| Comments | ||
|---|---|---|
| yes | SVG WG | Already decided and widely implemented |
Commitment: add your company name or individual (if not working for a company)
Align with CSS WG preserveAspectRatio
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) |
Commitment: add your company name or individual (if not working for a company)
Should be possible to determine intrinsic size of an image
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
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) |
Commitment: add your company name or individual (if not working for a company)
Align with CSS Value and Units
This is just to reference css3-values. We have a resolution on this already.
| Comments | ||
|---|---|---|
| yes | SVG WG | Already agreed |
Commitment: add your company name or individual (if not working for a company)
Gzip-compressed svg in data URIs
| 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
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will deprecate baseline-shift and use vertical-align (see Sydney meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Media elements in SVG need ability to associate captions and description
| 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) |
Commitment: add your company name or individual (if not working for a company)
Consider adding a 'inverse' value to clip-rule
| 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' property to reference any element, not just 'clipPath'
| 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) |
Commitment: add your company name or individual (if not working for a company)
Consider adding renderedWidth/renderHeight properties to SVG root
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
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
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) |
Commitment: add your company name or individual (if not working for a company)
Consider adding a 'key()' keyword for animation triggers
This would take DOM 3 Events key identifiers, compared to accessKey().
| Comments |
|---|
Consider adding a property for autoscaling
| Comments | ||
|---|---|---|
| no | SVG WG | SVG 2 will not add a property for autoscaling (see Sydney meeting minutes) |
Consider adding advanced font metrics interface
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will have an advance font metrics interface (see Sydney meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Consider making svgz files just as valid and useful as svg files
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will clarify that svgz should be as usable everywhere svg files can (see Sydney meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Consider allowing CSS 'color' property to apply to 'fill'
| 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)) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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 |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
the 'timelineBegin' attribute on the <svg> element
| Comments |
|---|
the <discard> element
| Comments |
|---|
the 'playbackOrder' attribute on the <svg> element
This attribute is linked to the use of the <discard> element.
| Comments |
|---|
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
New Styling features
New properties
audio-level
| Comments | ||
|---|---|---|
| yes | SVG WG | as previously resolved |
Commitment: add your company name or individual (if not working for a company)
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. |
Commitment: add your company name or individual (if not working for a company)
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 |
Commitment: add your company name or individual (if not working for a company)
solid-opacity
| Comments | ||
|---|---|---|
| yes | SVG WG | Related to #the_.3CsolidColor.3E_element |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
viewport-fill
| Comments | ||
|---|---|---|
| yes | SVG WG | Resolved at Brussels f2f: SVG 2 will keep viewport-fill and viewport-fill-opacity for zoom |
Commitment: add your company name or individual (if not working for a company)
viewport-fill-opacity
| Comments | ||
|---|---|---|
| yes | SVG WG | Resolved at Brussels f2f: SVG 2 will keep viewport-fill and viewport-fill-opacity for zoom |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
Consider adding scrolling to editable text
| Comments | ||
|---|---|---|
| maybe | SVG WG | see meeting minutes |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
audio-level
| Comments | ||
|---|---|---|
| yes | SVG WG | as previously resolved |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
The SVGRotate event
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will have the SVGRotate event from SVG Tiny 1.2 (see meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
Progress Events loadstart, progress, loadend
| Comments | ||
|---|---|---|
| yes | SVG WG | SVG 2 will support progress events using the html 5 method (see meeting minutes) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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 [www.w3.org/2012/02/16-svg-irc#T21-19-55 meeting minutes]) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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) |
Commitment: add your company name or individual (if not working for a company)
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. |
indicating links
| Comments | ||
|---|---|---|
| yes | Chris | Improved text is improved |
Improved text for fragment identifiers link traversal
| Comments | ||
|---|---|---|
| yes | Chris | Improved text is improved |
Added text for Processing Inline Script
| Comments |
|---|
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 |
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. |
the Animations chapter
The Animation chapter of SVG Tiny 1.2 does not seem to have modifications compared to SVG 1.1 2nd edition.
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>
| Comments |
|---|
Micro DOM
| Comments |
|---|
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. |
Late Proposed Requirements
Array element
| Comments |
|---|
Half-tone
| Comments |
|---|
