Copyright © 2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document addresses errors in the Scalable Vector Graphics (SVG) 1.1 Specification Recommendation published on 14 January 2003. It records all errors that, at the time of this document’s publication, have solutions that have been approved by the SVG Working Group.
This document lists all corrections for the Scalable Vector Graphics (SVG) 1.1 Specification Recommendation that have been approved by the SVG Working Group.
Each erratum is classified as markup, editorial or substantive. These categories are defined as follows:
These categories correspond to the first three correction classes in the W3C Process Document.
Each erratum has one of two statuses: proposed and normative. Proposed errata are those that have been accepted by the Working Group but which still need wider technical review and endorsement from the W3C. Normative errata are those that have been accepted by the Working Group and have had wider technical review and endorsement by the W3C. (See the Errata Management section of the W3C Process Document for details.)
Comments on the specification or these errata may be sent to www-svg@w3.org, which is publicly archived.
There are currently no normative corrections.
Linking in a text environment | |
---|---|
Status | Proposed |
Category | Substantive |
In reference to | |
Description | It is not possible to express in a DTD the dynamic content model of an 'a' element, ie. the 'a' element takes on the content model of its parent. This was fixed in 1.2 Tiny by using Relax NG. Note that the description of container element does not allow graphical elements inside non-container elements. The text element is a non-container. |
Resolution | Content of an 'a' element must follow the content model of the parent. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/linking.html#Links, replace: with: |
feFlood in attribute | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Erik Dahlström |
In reference to | |
Description | The feFlood filter primitive has an 'in' attribute, but doesn't specify how that is meant to work. |
Resolution | Remove the 'in' attribute from the 'feFlood' element. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feFloodElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#filter-mod, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#basic-filter-mod, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#InterfaceSVGFEFloodElement, replace: with: |
Filter subregion | |
---|---|
Status | Proposed |
Category | Substantive |
Comment | Tim Rowley |
Description | Clarify how the filter subregion is supposed to work. |
Resolution | Proposed: When a filter is applied to an element the output of the filter is what gets painted on the canvas. The filter region specifies the dimensions of the output and the filter primitive subregion can further restrict the region that the filter operates on. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#FilterPrimitiveSubRegion, replace: with: |
Clarify the effect of "to animations" and "by animations" for transforms | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
Comment | Cameron McCormack |
Test case | [1] |
Description | The behavior of "to animations" and "by animations" when using animateTransform is unclear. |
Resolution | Clarify that a "by animation" is equivalent to an additive animation from zero to the "by" value, where in particular the zero value for a scale transform is indeed 0. State that "to animations" for transforms are undefined. This behavior is in line with that defined in SVG Tiny 1.2. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html, replace: with: |
Start and end incorrectly described for text | |
---|---|
Status | Proposed |
Category | Substantive |
In reference to | |
Test case | [1] |
Description | Start and end are incorrectly described as left and right - when bidi is in effect, start would be on the right. |
Resolution | The definition of start and end should be as per the xsl specification. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#TextAlignmentProperties, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#TextAlignmentProperties, replace: with: |
Typo 'effect' instead of 'affect' | |
---|---|
Status | Proposed |
Category | Markup |
In reference to | |
Description | There is a typo 'effect' instead of 'affect' |
Resolution | Replace with 'affect'. This is the case in several places throughout the section, wherever there is "not effect event processing" |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/interact.html#PointerEventsProperty, replace: with: |
Incorrect reference to solidColor element | |
---|---|
Status | Proposed |
Category | Editorial |
In reference to | |
Description | References to solidColor element and link to "solid colors" should have been removed from the SVG 1.1 spec in favour of putting into SVG 1.2 Tiny. |
Resolution | Remove references to solidColor element and link to "solid colors". |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#Introduction, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#SpecifyingPaint, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/pservers.html#Introduction, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#DataTypeColor, replace: with: |
Capturing pointer-events with a zero opacity mask | |
---|---|
Status | Proposed |
Category | Substantive |
In reference to | |
Description | It's unclear whether if an element has a mask, pointer-events are still captured even in areas where the mask goes to zero opacity. Don't want nearly transparent and fully transparent to behave differently. |
Resolution | If an element has a mask, pointer-events are still captured even in areas where the mask goes to zero opacity. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/interact.html#PointerEventsProperty, insert: |
Unclear how clip-path affects bounding boxes | |
---|---|
Status | Proposed |
Category | Substantive |
Test case | [1] |
Description | It is unclear whether the bounding-box of an object should take into account a clip-path on that object. |
Resolution |
|
Pointer-events and fallback values | |
---|---|
Status | Proposed |
Category | Substantive |
Description | The visible-painted desc. says it applies only when fill property is set to value other than none, but you could have a fill property set to a URI and falling-back to none. |
Resolution | Refer to the actual value rather than the plain property value. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/interact.html#PointerEventsProperty, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/interact.html#PointerEventsProperty, replace: with: |
Clarify List syntax | |
---|---|
Status | Proposed |
Category | Editorial |
In reference to | |
Description | Not entirely obvious how whitespace should be treated in list syntax. |
Resolution | Need to mention "Per the SMIL specification, leading and trailing white space, and white space before and after semi-colon separators, is allowed and will be ignored." Not a technical change, but a clarification. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#ValuesAttribute, replace: with: |
SVGFEConvolveMatrix IDL missing 'in' attribute | |
---|---|
Status | Proposed |
Category | Editorial |
In reference to | |
Description | Missing 'readonly attribute SVGAnimatedString in1' in the SVGFEConvolveMatrixElement interface. Note that this is already added to the new Filters specification. |
Resolution | Add 'readonly attribute SVGAnimatedString in1' to the SVGFEConvolveMatrixElement interface. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#InterfaceSVGFEConvolveMatrixElement, replace: with: |
feDistantLight azimuth attribute direction | |
---|---|
Status | Proposed |
Category | Substantive |
In reference to | |
Description | Direction of azimuth is not specified, and implementations differ. |
Resolution | Specify that it is clockwise. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feDistantLight, replace: with: |
Propagation of rotate in text | |
---|---|
Status | Proposed |
Category | Substantive |
In reference to | |
Test case | [1] |
Description | In SVG Full 1.1, the description of tspan explicitly says that rotate does not propagate to exisiting characters when there are more characters than rotation values. However, subsequent text following the attribute description implies that it does. This errata item should correct the description of the rotate attribute in tspan and define the exact behavior. |
Resolution | We will clarify the propagation of character rotation values, and include an example that demonstrates this. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#TSpanElement, replace: with: |
Add svg to list of animatable elements | |
---|---|
Status | Proposed |
Category | Editorial |
In reference to | |
Description | List of animatable elements does not include the svg element. |
Resolution | Add svg to list of elements. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#AnimationAttributesAndProperties, replace: with: |
Remove XPointer syntax | |
---|---|
Status | Proposed |
Category | Substantive |
In reference to | |
Description | We reviewed this decision and agreed that xpointer is not implemented, and that the xpointer format has subsequently changed, and that we should simply remove it from all specs. |
Resolution | We will remove all reference to xpointer. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/intro.html#W3CCompatibility, remove: In http://www.w3.org/TR/2003/REC-SVG11-20030114/linking.html#SVGFragmentIdentifiers, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/refs.html#q1, remove: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#HeadOverview, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#xlinkRefAttrsEmbed, replace: with: |
Add definition of access of default uninitialized values | |
---|---|
Status | Proposed |
Category | Substantive |
Description | It isn't clear what should happen when you ask for an unspecified attribute. |
Resolution | Specify that an object is initialised with the default value, if there is one. It is live, and isn't created unless it's assigned to. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/svgdom.html#SVGDOMOverview, replace: with: |
Mention live values | |
---|---|
Status | Proposed |
Category | Substantive |
Test cases | [1], [2], [3], [4] |
Description | Liveness of the SVG base types isn't clear. For SVG*List.replaceItem and SVG*List.insertItemBefore when the item is inserted into the same list it was in before it's not defined if the index is before or after the item was removed. |
Resolution | Need to clarify that some values in the DOM are live. For replaceItem and insertItemBefore the index given is before the item has been removed from the list. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/svgdom.html#SVGDOMOverview, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGNumberList, http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLengthList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGPointList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList and http://www.w3.org/TR/2003/REC-SVG11-20030114/paths.html#InterfaceSVGPathSegList, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGNumberList, http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLengthList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGPointList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList and http://www.w3.org/TR/2003/REC-SVG11-20030114/paths.html#InterfaceSVGPathSegList, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGNumberList, http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLengthList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGPointList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList and http://www.w3.org/TR/2003/REC-SVG11-20030114/paths.html#InterfaceSVGPathSegList, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGNumberList, http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLengthList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGPointList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList and http://www.w3.org/TR/2003/REC-SVG11-20030114/paths.html#InterfaceSVGPathSegList, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGNumberList, http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLengthList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGPointList, http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList and http://www.w3.org/TR/2003/REC-SVG11-20030114/paths.html#InterfaceSVGPathSegList, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransform, replace: with: |
SVGStringList string removal | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Erik Dahlström |
Description | The SVGStringList interface says that if a certain string was in an SVGStringList it must be removed from that list when inserted into another list. The type of object that SVGStringList contains is DOMString, which is defined by DOM Core as a sequence of unsigned shorts. DOMString objects may come from any number of different places and are not tied to where they came from. All the other SVGxxxLists contain SVG DOM base objects, and the SVG DOM base objects provide ways to identify that they were in lists. SVGStringList on the contrary doesn't contain SVG DOM base objects but DOM Core base objects (DOMString) which makes it different from the other lists because the objects are low-level (core) objects which don't have the necessary information to say that an object was in a list. |
Resolution | SVGStringList does not remove inserted strings from previous lists. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGStringList, replace: with: |
Undefined behavior of missing feFunc[RGBA] in feComponentTransfer | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Tim Rowley |
In reference to | |
Test case | [1] |
Description | The spec should specify what happens if feComponentTransfer is missing one or more of feFunc[RGBA], as well as what happens if a feFunc[RGBA] is specified more than once. |
Resolution | Specify that a missing feFunc[RGBA] acts as a no-op, and for feFunc[RGBA] specified multiple times the last one is used (check that this is backwards compatible). |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feComponentTransfer, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feComponentTransfer, replace: with: |
patternContentUnits missing in 1.1 modules | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Tolga Capin |
In reference to | |
Description | The spec should have patternContentUnits in the pattern module, section 13.5. |
Resolution | Add patternContentUnits to the pattern module. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/pservers.html#pattern-mod, replace: with: |
References to characters in SVGTextContentElement should be UTF-16 code units | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Description | The methods on SVGTextContentElement are all written in terms of Unicode characters, but to be consistent with DOM Core method these should be in terms of UTF-16 code units. |
Resolution | These methods should all be interms of UTF-16 code units. An explanatory paragraph at the top of the interface description will be included to clarify this. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#InterfaceSVGTextContentElement, replace: with: |
SVGTextContentElement.getNumberOfChars | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Thomas E Deweese |
In reference to | |
Comments | Thomas Deweese, Anne van Kesteren |
Test case | [1] |
Description | getNumberOfChars() is written in terms of Unicode characters, but it would be more consistent with other DOM methods to be in terms of UTF-16 codepoints. Also, it should be made clear that it is the number of UTF-16 codepoints for all characters that are available for rendering, not just those that are in the end rendered. For example, with textPath not all glyphs might be rendered when they fall off the end of the path. |
Resolution |
|
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#InterfaceSVGTextContentElement, replace: with: |
Mandate gzip compression | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Peter Sorotokin |
In reference to | |
Comment | Peter Sorotokin |
Description | gzip is more than deflate, we should only mention deflate. This is already fixed in Tiny 1.2. |
Resolution | Fix the wording as per SVG Tiny 1.2. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/conform.html#ConformingSVGViewers, replace: with: |
SVGLocatable.getScreenCTM() vs clientX/Y, screenX/Y | |
---|---|
Status | Proposed |
Category | Editorial |
In reference to | |
Description | This method would have been more aptly named as getClientCTM, but the name getScreenCTM is kept for historical reasons. |
Resolution | Say that this method would have been more aptly named as getClientCTM, but the name getScreenCTM is kept for historical reasons. Proposed text should clarify that getScreenCTM actually relates to the same coordinate space as clientX/Y. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLocatable, replace: with: |
ElementTimeControl interface | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Vincent Hardy |
Comment | Cameron McCormack |
Description |
|
Resolution |
|
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#DOMInterfaces, replace: with: |
TimeEvent interface | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Comment | Cameron McCormack |
Description |
|
Resolution | The inline Java interface should also be replaced with a reference to the one in SMIL Animation. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#DOMInterfaces, replace: with: |
SVGLoad does not bubble | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Olli Pettay |
In reference to | |
Comments | Bjoern Hoehrmann, Bjoern Hoehrmann |
Description | The SVGLoad event is in SVG1.1 is dispatched only to the element to which the event applies; it is not dispatched to its ancestors. This change was made in SVG Tiny 1.2 and the same change should be made to 1.1 to make them consistent. |
Resolution | We will replace the paragraph in 1.1 with a simple statement that "The SVGLoad event does not bubble". |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/interact.html#SVGEventsCompleteList, replace: with: |
Float Value Units | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Cameron McCormack |
In reference to | |
Description | There are minor typographical errors in the description of the SVGLength interface. |
Resolution | These typographical errors will be fixed. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLength, replace: with: |
boolean useCurrentView | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Cameron McCormack |
In reference to | |
Description |
The |
Resolution | The references to |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: |
Example feColorMatrix source file correction | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Robert Longson |
Comment | [1] |
Description | The example file feColorMatrix.svg incorrectly uses a percentage value in a |
Resolution | Change the example in source file of feColorMatrix.svg to use a decimal number instead of a percentage number. The example is correct in the SVG specification. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/images/filters/feColorMatrix.svg, replace: with: |
Clarify scientific notation text | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Robert Longson |
In reference to | |
Comment | [1] |
Description | The description of value real number syntaxes allowed in CSS properties and XML attributes is confusing. |
Resolution | The text will be reworded to have CSS2 mentioned in the scientific notation. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#DataTypeLength, replace: with: |
Clarify clipPath and Pointer-Events | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Doug Schepers |
Comment | [1] |
Description | It is unclear where pointer events should be triggered on elements with a clipping path applied. |
Resolution | An explanation of the different values for |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/masking.html#EstablishingANewClippingPath, insert: |
A number of interfaces' methods are missing DOMExceptions | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Description | A number of SVG DOM interfaces that correspond to DOM nodes have methods that can mutate the node, but don't declare that they throw a DOMException when the node is readonly. |
Resolution | Add NO_MODIFICATION_ALLOWED_ERR DOMExceptions to the relevant methods that could mutate a readonly object. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLength and http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLength, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGAngle and http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGAngle, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransform and http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGTransform, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList and http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGTransform, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#InterfaceSVGMarkerElement and http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#InterfaceSVGMarkerElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#InterfaceSVGFilterElement and http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#InterfaceSVGFilterElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#InterfaceSVGFEGaussianBlurElement and http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#InterfaceSVGFEGaussianBlurElement, replace: with: |
Interface SVGRect has incorrect attribute descriptions | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Cameron McCormack |
In reference to | |
Description | In the description for Interface SVGRect, the descriptions of the attributes are inaccurate. They refer to attributes (in the XML sense) on an element, but this is only true for the case of SVGFitToViewBox.viewBox. |
Resolution | Update the attribute descriptions to more accurately reflect their purpose. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGRect, replace: with: |
Stroking subpaths of zero length | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Dr. Olaf Hoffman |
Description | There is a conflict between sections 11.4 and F.5 in the SVG 1.1 specification regarding the stroking of zero length subpaths. SVG Tiny 1.2 is fixed such that there is no conflict. |
Resolution | We will back port the fix from SVG Tiny 1.2 to SVG 1.1. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#StrokeProperties, replace: with: |
Clarification of outermost SVG element | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Antoine Quint |
In reference to | |
Description | The SVG 1.1 spec assumes that definition of "outermost svg element" is understood when describing terms in the definition section. The SVG Tiny 1.2 specification seems to describe "outermost svg element" (a.k.a. the "rootmost svg element") more carefully. |
Resolution | We will add a definition for the term "outermost svg element". |
Change | In http://www.w3.org/TR/2003/REC-SVG11-20030114/intro.html#Definitions, insert: |
Link to idl.zip incorrect | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Tim Rowley |
In reference to | |
Description | The IDL appendix has a link to the SVG 1.0 idl.zip file. This should be a link to the 1.1 idl.zip file, since there are a couple of changes. |
Resolution | The link will be changed to point to the SVG 1.1 IDL zip file. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: |
Correction to Feature Sets title | |
---|---|
Status | Proposed |
Category | Markup |
Reported by | Cameron McCormack |
In reference to | |
Description | The "Appendix O: Feature Strings" chapter is called "Feature Sets" in the HTML <title>. Presumably this should be "Feature Strings". |
Resolution | |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/feature.html, replace: with: |
Clarify feTurbulence seed value type | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Cameron McCormack |
In reference to | |
Description |
Currently in the specification the |
Resolution |
We will clarify that the value of |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feTurbulenceSeedAttribute, replace: with: |
Clarify color-interpolation in feDisplacementMap | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Robert Longson |
In reference to | |
Comment | [1] |
Description | The 'color-interpolation-filters' property only applies to the (in2) source image and does not apply to the in source image. For feDisplacement map we can convert the (in2) source image before we work on it but what are we supposed to do with the in source image? This needs to be clarified. |
Resolution | The image should be left in the color space it happens to be in. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feDisplacementMap, replace: with: |
Clarify limitingConeAngle in feSpotLight | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Tim Rowley |
In reference to | |
Comment | [1] |
Description | There is a limitingConeAngle specified as an attribute and DOM property of the feSpotLight element, but the lighting specification in the feDiffuseLighting and feSpecularLighting sections do not include it in the equations given. This needs to be clarified. |
Resolution | To add wording: "If limitingConeAngle is specified, -L.S < cos(limitingConeAngle) also indicates no light is present." and also state that limitingConeAngle is in degrees. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feSpotLightLimitingConeAngleAttribute, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feDiffuseLighting, replace: with: |
Liveness of getIntersectionList and getEnclosureList | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Erik Dahlström |
Description | The two SVG 1.1 DOM methods getIntersectionList and getEnclosureList return a NodeList. NodeList is defined by the DOM 2 Core specification as being "live". This means that the evaluation of these two methods can be expensive to perform. Batik is the only implementation known at the time of writing that supports these methods, but it does so only as static NodeLists. |
Resolution | Loosen the stricture on NodeList so that it may be static only for the getIntersection and getEnclosureList methods. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: |
feDiffuseLighting calculation does not define I(x,y) | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Tim Rowley |
In reference to | |
Description | The normal calculation in section 15.14 defines N in terms of a function "I(x,y)", which does not appear to be defined. |
Resolution | The equations are computing the surface normal at a given point of a surface made by treating the alpha channel as a height field. The text above those equations originally said "input alpha image I(x,y)" but was then edited to the longer and slightly more readable "input alpha image Ain (x,y)". Unfortunately, the same substitution was not made to the equations, just the description. This erratum makes the text and the equations consistent with each other and with the equations immediately following. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feDiffuseLighting, replace: with: |
getCurrentTime()/setCurrentTime() undefined before document timeline begin | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Description | The behavior of SVGSVGElement's getCurrentTime() and setCurrentTime() methods is not defined if they are called before the document timeline has begun. |
Resolution | Calling getCurrentTime() before the document timeline has begun returns 0. Calling setCurrentTime() before the document timeline has begun will cause the document to be seeked to the specified time once the timeline has begun. If there are multiple such calls to setCurrentTime(), the last one takes effect. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: |
Clarify Z and z for paths | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Andreas Neumann |
Description | It is not clear whether there are any difference between closing the path with z or Z. If one used relative coordinates before, should one use z and otherwise Z? |
Resolution | We will clarify that "z" and "Z" have identical behavior in paths. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/paths.html#PathDataClosePathCommand, replace: with: |
Typographical Errors in Coordinate Systems Examples | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Alexey Feldgendler |
In reference to | |
Comment | [1] |
Description | A number of examples in the coordiantes systems chapter contain minor typographical errors. |
Resolution | We will correct the typographical errors. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#EstablishingANewUserSpace, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#GeographicCoordinates, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#GeographicCoordinates, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#GeographicCoordinates, replace: with: |
Clarification of contentScriptType behavior | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Erik Dahlström |
In reference to | |
Comment | [1] |
Description |
Scripting elements that have to move across unknown markup to get to the
default script type should not be executed unless it understands the
contentScriptType specified.
Alternatively, it could be interpreted that the |
Resolution | We will clarify that |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/script.html#DefaultScriptingLanguage, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/script.html#ScriptElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/script.html#ScriptElement, replace: with: |
Remove exception on unsuspendRedraw | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Erik Dahlström |
In reference to | |
Description |
|
Resolution | We will drop the exception. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: |
Clarify premultiplied values for feDisplacementMap | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | MenTaLguY |
In reference to | |
Description | Section 15.15 (feDisplacementMap) does not explicitly specify whether it operates on premultiplied values. It comes down to an issue of whether or not feDisplacementMap is a filter which works more naturally on non-premultiplied data. The reporter assumes that is the case. |
Resolution | We will state that the filter operates on premultiplied values. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feDisplacementMap, replace: with: |
Clarify getSVGDocument behavior | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Anne van Kesteren |
In reference to | |
Comments | [1], [2] |
Description |
|
Resolution | We will make |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceGetSVGDocument, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/refs.html, replace: with: |
Clarify contentStyleType behavior | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Erik Dahlström |
In reference to | |
Description |
|
Resolution |
|
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/styling.html#StyleElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/styling.html#StyleElement, replace: with: |
Clarify if 'order' on 'feConvolveMatrix' is required or not | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Robert O'Callahan |
In reference to | |
Test case | [1] |
Description |
The attribute description for |
Resolution | We will make the attribute not required. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feConvolveMatrixElementOrderAttribute, replace: with: |
Typo in the definition of the 'u2' attribute | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
Description |
The |
Resolution |
We will align |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/fonts.html#HKernElementU2Attribute, replace: with: |
SVGTextContentElement clarifications | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Ian Hickson |
In reference to | |
Test case | [1] |
Description | According to SVG 1.1, getSubStringLength() raises an INDEX_SIZE_ERR exception "if the charnum is negative or if charnum+nchars is greater than or equal to the number of characters at this node", but it seems like "charnum+nchars" being equal to the number of characters should be fine. It's not clear what happens in getSubStringLength if the given range start- or endpoints are on some inseparable character, such as a surrogate pair, or a multi-character glyph. |
Resolution | Allow the last character in a text content element to be measured with getSubStringLength. Don't raise an INDEX_SIZE_ERR exception in selectSubString and getSubStringLength for the cases where nchars is greater than the number of characters. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#InterfaceSVGTextContentElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#InterfaceSVGTextContentElement, replace: with: |
Clarify value spacing of keySpline syntax | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Oliver Hunt |
In reference to | |
Description | The SVG Full 1.1 specification implies that the syntax for control points of the keySpline attribute are space separated. Various SVG test cases use commas to separate the values. SMIL syntax allows comma separated values. This should be clarified in the specification. |
Resolution | We will clarify the wording for the keySpline syntax. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#KeySplinesAttribute, replace: with: |
Incorrect entries in the attribute index | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Cameron McCormack |
In reference to | |
Description |
|
Resolution | The above attributes should be added/removed/fixed. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/attindex.html, remove: In http://www.w3.org/TR/2003/REC-SVG11-20030114/attindex.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/attindex.html, replace: with: |
Clarify liveness of setMatrix and createSVGTransformFromMatrix methods | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Robert O'Callahan |
Description | The liveness of SVGTransformList.createSVGTransformFromMatrix, SVGSVGElement.createSVGTransformFromMatrix and SVGTransform.setMatrix is not defined. |
Resolution | setMatrix and createSVGTransformFromMatrix methods copy the values from the matrix parameter, and do not adopt the SVGMatrix object in the SVGTransform object. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransform, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#InterfaceSVGTransformList, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: |
Clarify if xlink:href on <script> elements is animatable or not | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Erik Dahlström |
Description |
It's not clearly defined if |
Resolution | We will align with SVG 1.2 Tiny, where it is not animatable. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/script.html#TypeAttribute, replace: with: |
Return value for SVGAnimationElement.getStartTime() is unclear | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Brian Birtles |
In reference to | |
Comments | Cameron McCormack, Brian Birtles |
Test case | [1] |
Description |
|
Resolution | An exception will be thrown if there is no current interval. A value will be returned regardless of whether the current interval is active or has not yet started. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#InterfaceSVGAnimationElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#InterfaceSVGAnimationElement, replace: with: |
Mismatch between Font.class in the spec and in the DTD | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Erik Dahlström |
Comment | Erik Dahlström |
Description | The font content sets don't match the DTD, and there are tests that rely on the DTD where font-face is in Font.class. |
Resolution | Add the font-face element to Font.class. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/fonts.html#id5195633, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/fonts.html#id5196049, replace: with: |
Clarify xml:space on 'text' element children | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Kalle Raita |
Comment | Kalle Raita |
Description | Unclear whether xml:space applies when specified on 'text' element child elements, e.g 'tspan'. |
Resolution | If a 'text' element child has specified xml:space it applies to that element and its children. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#XMLSpaceAttribute, replace: with: |
Link to ISO8601 reference in the Animation chapter is incorrect | |
---|---|
Status | Proposed |
Category | Markup |
Reported by | Scott Hayman |
In reference to | |
Description | A reference to ISO8601 in the animation chapter is linked to an ICC document instead of the ISO8601 bibliography entry. |
Resolution | Fix the link to point to the bibliography entry. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#WallclockSyncValueSyntax, replace:
Describes the element begin as a real-world clock
time. The wallclock time syntax is based upon syntax
defined in [
with:
Describes the element begin as a real-world clock
time. The wallclock time syntax is based upon syntax
defined in [
|
DTD extensibility example incorrect | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Chris Lilley |
In reference to | |
Description | The example demonstrating the use of an internal DTD subset to extend the language is invalid. |
Resolution | The example should be corrected. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/extend.html#PrivateElementsAndAttribute, replace: with: |
Clarify getBBox behavior | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Alexander Adam |
In reference to | |
Comment | [1] |
Description | The blocking nature of getBBox wasn't described clearly enough in the spec. |
Resolution | Add a sentence to getBBox method definition to say that it must always return the actual boundingbox, even though the element may not yet have been rendered. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLocatable, replace: with: |
SVGSVGElement::useCurrentView should be read only | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Description | It is unclear what the effect of modifying the SVGSVGElement::useCurrentView attribute should be, especially since it reflects the state of the "inital view", i.e. just when the document is first displayed. Perhaps the attribute should be read only? Also, it's not clear when the NO_MODIFICATION_ALLOWED_ERR DOMException would be thrown, since useCurrentView doesn't correspond to a DOM attribute. |
Resolution | The attribute will be made read only, and the exception will be removed. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: |
SVGSVGElement::currentScale should not throw an exception | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Description | The NO_MODIFICATION_ALLOWED_ERR DOMException that is declared to be thrown on setting SVGSVGElement::currentScale is for when a read only node in the DOM would need to be modified. However, since currentScale does not correspond to an attribute in the DOM, this description is erroneous. |
Resolution | The exception will be removed. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceSVGSVGElement, replace: with: |
foreignObject should be allowed to be placed as a child of any container element | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Description | Currently a 'foreignObject' element is only allowed as a child of a 'switch'. Since you needn't place any conditional processing attributes on the 'foreignObject' inside the 'switch', it may as well be allowed as a child of any container element. |
Resolution | The DTD will be modified to allow a 'foreignObject' as the child of any container element. (Corresponding changes to the DTD appendix have been omitted from this erratum for brevity.) |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#SVGSVGElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#GElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#DefsElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#SymbolElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/linking.html#AElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/fonts.html#GlyphElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/fonts.html#MissingGlyphElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#MarkerElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/masking.html#MaskElement, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/pservers.html#PatternElement, replace: with: |
Clarify that assigning to valueAsString changes unitType and add exceptions for some cases | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Description |
|
Resolution | The description of valueAsString on SVGLength and SVGAngle will be clarified, and exceptions will be added for the above cases. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLength, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGAngle, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGLength, replace: with: In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#InterfaceSVGAngle, replace: with: |
Rendering of patterns with overflow="visible" is undefined | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Dr. Olaf Hoffmann |
In reference to | |
Comment | [1] |
Description | The rendering order of pattern tiles that have overflow="visible" set is undefined. |
Resolution | Let overflow="visible" have explictly undefined behavior, and raise this issue for a later spec version. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/pservers.html#Patterns, replace: with: |
Clarification of lineto commands in the path syntax | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Krzysztof Maczyński |
In reference to | |
Comment | [1] |
Description | SVG 1.1 and SVG Tiny 1.2 specs both say the following regarding the 'moveto' command in path syntax: [[ If a 'moveto' is followed by multiple pairs of coordinates, the subsequent pairs shall be treated as implicit 'lineto' commands. ]] It's unspecified whether those implicit 'lineto' commands are absolute or relative. Since the first 'moveto' command in @d will be interpreted as an absolute 'moveto' regardless of whether it said 'M' or 'm', that may need additional clarification wrt implicit 'lineto's that follow it. |
Resolution | Clarify implicit linetos to be absolute or relative in line with current implementations |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/paths.html#PathData, replace: with: |