SVG:SVG2:Ideas

This page contains ideas for improvements to SVG for SVG 2 that should be brought up and discussed at the SVG WG meetings. Please update these page with links to meetings and conclusions as they happen.

There are other pages on bugs in the spec at SVG:Language and SVG:Specification_Issues.

Ideas for SVG 2

Relax whitespace rules for attributes

Currently HTML is very relaxed about leading and trailing whitespace in attribute values. This seems to lead to authors tripping over SVG's stricter rules. We should probably audit our attributes and allow leading and trailing whitespace where possible.

Support SMIL animation of pie chart slices

This is a nightmare right now. See https://bugzilla.mozilla.org/show_bug.cgi?id=653928#c15

Remove SVGSVGElement::getElementById

If we can't remove it, then at least define it in terms of querySelector, so that the behavior between the two is consistent.

Text on path, pathLength and textPath

We need to sort out what the spec says on how pathLength works when there is a transform on the path. Also the text talking about how transform is handled on textPath, the textPath's parent, and the referenced path...and then how pathLength works with all that. Pay attention to when the transforms affect the text as a visual entity, and when the affect just offsets. IE seems to do a transform of the position of the glyphs in a way that affects the on screen distance between them, whereas other implementations seem to keep the distance between glyphs the same.

Adding JS array style indexing to SVG list types

Add it!

User space/user coordinate system

It's quite unclear what this term means in the spec, which makes things like what getCTM should do quite ambiguous. What is the "current user space"?

I asked this on www-svg and Jon Ferraiolo replied, but his reply, but this seems unhelpful. Jon also doesn't seem to notice that 'transform' applied before 'x'/'y' type attributes, whereas 'viewBox' applies after.

I think that "user space" should be defined to be something like "the coordinate space in which vertex defining attributes are in". That doesn't really work for all elements (x/y on svg doesn't define a vertex, for example), but something like that.

Specify what happens for empty conditional processing attributes

The spec should clarify what should happen if conditional processing attributes (systemLanguage et. al.) are set to the empty string. Probably we should treat that as unset, but that's not what Firefox currently does.

Clarify [un]suspendRedraw/forceRedraw

Right now it seems to me (jwatt) that these methods were a mistake. When you suspend redraw on an <svg> which has other content partially on top of it, and that content changes, how can you repaint correctly? The only way would be to maintain a snapshot of the the <svg> at the time it was suspended (either the tree, or its rendering). Even if you save a snapshot, what about if the <svg> resizes due to a window resize, say? If the snapshot is of the tree, it's going to rerender at a different size, which for some people won't be "suspended". If the snatshot is of the rendering itself, then the <svg> is going to fit badly into the surrounding document, or even if it's scaled with pixelation, it would not get preserveAspectRatio scaling. So there's no way to get this right for all cases. There's also the issue of handling of pointer events in suspended content, and unexpected behavior from a user's point of view.

Specify what should happen when script inserts bad things into an SVGStringList

When the SVGStringList methods initialize(), insertItemBefore(), replaceItem() and appendItem() are used to insert bad things into a string list, we should really throw. This probably includes:

• null
• empty string
• strings containing whitespace (list items are supposed to be separated by whitespace, so allowing this breaks round-tripping)
• probably strings that contain any control characters or other bad characters

Cap numOctaves

It seems like setting a high value for numOctaves is going to pretty much hang any implementation, and after a certain value it doesn't make much difference to the rendering. The spec should probably cap the value.

filterRes

The name "filterRes" is unfortunate, since it doesn't define a resolution (pixels per unit length), but rather an offscreen surface size.

getScreenCTM

We should call this "getClientCTM", and have the spec say that there's a pseudonym "getScreenCTM" for backwards compatibility.

Also specify that on <svg>, getCTM and getScreenCTM get the transform not to the nearestViewportElement's viewport, but to the element's own viewport.

SVGXxxList.clear()

Clarify whether this should make element.hasAttribute() return false.

<switch> when the matched child is display:none

We should specify what should happen when the child of a <switch> that would normally be matched is display:none. It seems like that should mean that that child is not matched, and the search for a child should continue.

Drop the 'zoomAndPan' attribute

Seems like this is out of scope for a spec (to restrict how the user can choose to view the content).

transform-origin and percentage values

It seems like there should be a way to say "transform-origin at top-left of object", but "top left" means "0 0", which for SVG means "0,0 in the element's user space". Maybe we need a new unit, or a new property to make the distinction?

Remove the ability to set 'transform' using a fragment identifier

Drop support for clip-path on clipPath

The utility to content authors is about nil, so it just pointlessly adds complexity.

Allow clip-path to directly reference 'path’, ‘text’ and basic shape elements

Add a property to 'mask' which allows it to be a 1-bit mask

Definition of user space

I think this should be "An element's user space is the coordinate space that the element's parent established for its children."