SVG:Language:Regrets

This is a place to collect a list of things about the SVG language that we might like to change if we could go back in time, or issues that we might be able to remedy in some way in a future version of the language.

Animation and the DOM

SVG 1.1 Full has a very verbose DOM. For example, to get to a particular matrix component in a 'transform' attribute, object.transform.baseVal.item(x).matrix.a. Or to get at an 'x' attribute: object.x.baseVal.value. A lot of people were unhappy with this, so SVG 1.2 Tiny introduced traits. Unfortunately the side effect is that Full implementations will have to support both the heavyweight object DOM, and the trait system.

Declarative (SMIL) Animation

See SMIL Challenges.

Mixed case element and attribute names

There are many element and attribute names in SVG that are mixed case. This doesn't integrate very well with the case insensitivity of CSS or HTML though. Future versions of SVG may just use case insensitive names, but that doesn't get around the issues with the large number of existing names, and will just make the SVG internally inconsistent and require authors to have to remember whether names are camel case, hyphenated, or all lowercase. All adding to the burden on authors.

Use of XLink

The use of XLink in SVG adds virtually nothing of value, but has proved to be a constant source of headaches for authors, a large portion of which find namespacing overly hard.

The error handling of SVG 1.1

SVG 1.1 required conforming implementations to do catastrophic things with SVG that is "in error". Happily nobody really implemented this error handling, and it's something that can be changed without too many problems in a future version of SVG.

Using 'evt' instead of 'event' as the event name

Duh!

Redundancy of the 'path', 'polyline' and 'polygon' elements

Defining objectBoundingBox to establish an implicit transform

The way it is defined, only percentage lengths are useful. Lengths such as 'px' lengths etc are useless. Suddenly 1px is the entire width/height of the element. It would have been much better if the spec had simply said that it changed what percentage units are relative to, and nothing else.

The values for the 'pointer-events' property

http://www.w3.org/TR/SVG/interact.html#PointerEventsProperty

IMNSHO, we should have had 'none' plus six other values (not eight): 'fill', 'stroke', 'both' and 'paintedFill', 'paintedStroke', 'paintedBoth'. The former three would have ignored opacity and visibility, the latter three would not. In fact, for reuse in CSS box model contexts such as HTML where you have 'background' and 'border' instead of 'fill' and 'stroke', the names would be 'perimeter', 'interior', 'both', and 'paintedPerimeter', 'paintedInterior', 'paintedBoth'.

Hmm, note that in the CSS case, 'background-color' has an initial value of 'transparent', which results in a computed value of 'rgba(0,0,0,0)'. That probably has implications for CSS compatibility with the existing or proposed [initial] values.

The current specification makes the value of the 'visibility' property special, but for some strange reason ignores the effects of opacity. As a result the 'visible' in value names such as 'visiblePainted' is nothing to do with whether something visible is actually painted, but rather to do with whether the 'visibility' property is set to 'visible' or not. The 'fill-opacity', 'stroke-opacity' or 'opacity', or the 'fill' or 'stroke' properties with rgba()/hsla() values that set opacity to zero, could all prevent any paint from being output, but as far as 'visiblePainted' et. al. are concerned, it's visible and painted if 'visibility' is set to 'visible'. Perhaps these values could be fixed to take account of opacity?

In fact 'visibleFill', 'visibleStroke' and 'visible' don't care about the values of 'fill' or 'stroke', even if they are 'none'.

Another source of confusion is the difference between 'visiblePainted', 'visible', 'painted' and 'all'. For all four the geometry is the combined stroke and fill geometry. The difference is in whether the 'fill' and 'stroke' properties are set to 'none' or not ('visiblePainted' and 'painted' do not allow them to be 'none', but 'visible' and 'all' do). Why do we even need a distinction between non-painting due to the value of 'visibility' vs 'fill'/'stroke'? Why don't we also have 'paintedFill', 'paintedStroke' and 'paintedAll' values then???

The 'visible' value should really have been 'visibleAll' for consistency. Maybe it seemed easier to remember, but the inconsistency it brings to the naming makes it harder to remember how everything works as a whole.

What about when 'fill' or 'stroke' references a gradient or pattern that is fully transparent/empty (or has large areas that are)? I think it would be fine to always treat paint server references as fully opaque paint. The utility behind 'painter-events' is to

Requiring 'display: none;' to create frames

clientX/Y and screenX/Y

These are in different coordinate systems in SVG than they are in HTML. SVG should really have added a getPointRelativeTo(element) function. The way it's redefined is not compatible with HTML, *and* it's not very useful. Really a method like that would have been a lot lot better.

externalResourcesRequired

Underspecified.

• does rendering stop at an element with externalResourcesRequired="true" until all of that element's content and their external resources have loaded, or does it stop at the first content element that requires a resource that is not loaded and wait for that to load before continuing? (can be do both by adding a progressiveRendering="true|false" attribute? any need for that?)
• what happens if an external resources cannot be loaded? does painting stop at that element for the entire lifetime of the document, while allowing the elements earlier in the document to paint and update as normal? is the stopping of the painting limited to the rest of the content of the element with the externalResourcesRequired="true" on it, or is it for the entire rest of the document.
• what happens if you have an element with externalResourcesRequired="false" inside an element with externalResourcesRequired="true"???
• what happens when you have a foreignObject containing non-SVG content that includes external resources, inside an element with externalResourcesRequired="true"?

Using hyphens in some element names

Most SVG elements use camel case naming, but some use hyphenation instead. See the SVG 1.1 Element Index. Presumably this was for consistency with CSS properties, but it makes these SVG elements totally inconsistent with other SVG elements.

Behavior of setting SVGLength.value

If you have a percentage length attribute, you get it's property in the DOM, and you set it's SVGLength.value to 50 and expect it to change to 50%, you will be sorely disappointed. The value passed in is understood to be in user units, regardless of the unit type of the SVGLength. This user unit value is then converted to the SVGLength's current unit, then set. So the value you pass in is in user units, but doesn't convert the length to user units. In other words you need to know how to convert between the units of the length and user units for that to be useful - i.e. it's not at all useful most of the time. IMO SVGLength.value should have been the SVGLength's value in its current units.

Markers

Authors seem to hate that style isn't inherited into the marker from the element that is being marked. Content that is <use>'ed is supposed to inherit style from the <use> element, which is a pain to implement, but possibly a better design for markers.

DOM interface for creating path segments

Really stupid is the fact that the arguments to the createXxx methods on the interface SVGPathElement change the argument order to what they are in the 'd' attribute. Specifically the end point (x and y arguments) are moved from the end to the beginning. Grr!!