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: SVG provides an 'a' element, analogous to HTML's 'a' element, to indicate links (also known as hyperlinks or Web links). SVG uses XLink ([XLink]) for all link definitions. SVG 1.0 only requires that user agents support XLink's notion of simple links. Each simple link associates exactly two resources, one local and one remote, with an arc going from the former to the latter. with: SVG provides an 'a' element, to indicate links (also known as hyperlinks or Web links). The 'a' element may contain any element that its parent may contain, except itself. SVG uses XLink ([XLink]) for all link definitions. SVG 1.0 only requires that user agents support XLink's notion of simple links. Each simple link associates exactly two resources, one local and one remote, with an arc going from the former to the latter. |
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: <!ENTITY % SVG.feFlood.extra.content "" > <!ENTITY % SVG.feFlood.element "INCLUDE" > <![%SVG.feFlood.element;[ <!ENTITY % SVG.feFlood.content "( %SVG.animate.qname; | %SVG.set.qname; | %SVG.animateColor.qname; %SVG.feFlood.extra.content; )*" > <!ELEMENT %SVG.feFlood.qname; %SVG.feFlood.content; > <!-- end of SVG.feFlood.element -->]]> <!ENTITY % SVG.feFlood.attlist "INCLUDE" > <![%SVG.feFlood.attlist;[ <!ATTLIST %SVG.feFlood.qname; %SVG.Core.attrib; %SVG.Style.attrib; %SVG.Color.attrib; %SVG.FilterColor.attrib; %SVG.FilterPrimitiveWithIn.attrib; flood-color %SVGColor.datatype; #IMPLIED flood-opacity %OpacityValue.datatype; #IMPLIED > with: <!ENTITY % SVG.feFlood.extra.content "" > <!ENTITY % SVG.feFlood.element "INCLUDE" > <![%SVG.feFlood.element;[ <!ENTITY % SVG.feFlood.content "( %SVG.animate.qname; | %SVG.set.qname; | %SVG.animateColor.qname; %SVG.feFlood.extra.content; )*" > <!ELEMENT %SVG.feFlood.qname; %SVG.feFlood.content; > <!-- end of SVG.feFlood.element -->]]> <!ENTITY % SVG.feFlood.attlist "INCLUDE" > <![%SVG.feFlood.attlist;[ <!ATTLIST %SVG.feFlood.qname; %SVG.Core.attrib; %SVG.Style.attrib; %SVG.Color.attrib; %SVG.FilterColor.attrib; %SVG.FilterPrimitive.attrib; flood-color %SVGColor.datatype; #IMPLIED flood-opacity %OpacityValue.datatype; #IMPLIED > 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: Interface SVGFEFloodElementThe SVGFEFloodElement interface corresponds to the 'feFlood' element.
with: Interface SVGFEFloodElementThe SVGFEFloodElement interface corresponds to the 'feFlood' element.
|
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: 'feTile' references a previous filter primitive and then stitches the tiles together based on the x, y, width and height values of the referenced filter primitive in order to fill its own filter primitive subregion. with: 'feTile' references a previous filter primitive and then stitches the tiles together based on the x, y, width and height values of the referenced filter primitive in order to fill its own filter primitive subregion.
Example: filtersubregion00.svg
<svg width="400" height="400" xmlns="http://www.w3.org/2000/svg"> <defs> <filter id="flood" x="0" y="0" width="100%" height="100%" primitiveUnits="objectBoundingBox"> <feFlood x="25%" y="25%" width="50%" height="50%" flood-color="green" flood-opacity="0.75"/> </filter> <filter id="blend" primitiveUnits="objectBoundingBox"> <feBlend x="25%" y="25%" width="50%" height="50%" in2="SourceGraphic" mode="multiply"/> </filter> <filter id="merge" primitiveUnits="objectBoundingBox"> <feMerge x="25%" y="25%" width="50%" height="50%"> <feMergeNode in="SourceGraphic"/> <feMergeNode in="FillPaint"/> </feMerge> </filter> </defs> <g fill="none" stroke="blue" stroke-width="4"> <rect width="200" height="200"/> <line x2="200" y2="200"/> <line x1="200" y2="200"/> </g> <circle fill="green" filter="url(#flood)" cx="100" cy="100" r="90"/> <g transform="translate(200 0)"> <g fill="none" stroke="blue" stroke-width="4"> <rect width="200" height="200"/> <line x2="200" y2="200"/> <line x1="200" y2="200"/> </g> <circle fill="green" filter="url(#blend)" cx="100" cy="100" r="90"/> </g> <g transform="translate(0 200)"> <g fill="none" stroke="blue" stroke-width="4"> <rect width="200" height="200"/> <line x2="200" y2="200"/> <line x1="200" y2="200"/> </g> <circle fill="green" fill-opacity="0.5" filter="url(#merge)" cx="100" cy="100" r="90"/> </g> </svg> In the example above there are three rects that each have a cross and a circle in them. The circle element in each one has a different filter applied, but with the same filter primitive subregion. The filter output should be limited to the filter primitive subregion, so you should never see the circles themselves, just the rects that make up the filter primitive subregion.
|
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: The animation effect for 'animateTransform' is post-multiplied to the underlying value for additive 'animateTransform' animations (see below) instead of added to the underlying value, due to the specific behavior of 'animateTransform'. From-to, from-by and by animations are defined by SMIL to be equivalent to a corresponding values animations. See the Animation function values section of SMIL Animation ([SMILANIM], section 3.2.2). However, to animations are a mixture of additive and non-additive behavior, as described in the How from, to and by attributes affect additive behavior section of SMIL Animation ([SMILANIM], section 3.3.6). To animations provide specific functionality to get a smooth change from the underlying value to the 'to' attribute value, which conflicts mathematically with the requirement for additive transform animations to be post-multiplied. As a consequence, in SVG 1.1 the behavior of to animations for 'animateTransform' is undefined. Authors are suggested to use from-to, from-by, by or values animations to achieve any desired transform animation. If calcMode has the value paced, … … Note that the zero value used when performing a by animation with type="scale" is indeed 0. Thus, performing the following animation causes the rectangle to be invisible at time 0s (since the animated transform list value is 'scale(0)'), and be scaled back to its original size at time 5s (since the animated transform list value is 'scale(1)'): <rect width="100" height="100"> <animateTransform attributeName="transform" attributeType="XML" type="scale" by="1" dur="5s" fill="freeze"/> </rect> For a list of attributes and properties … |
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: For Latin or Arabic, which is usually rendered horizontally, this is comparable to left alignment. with: For Latin in its usual orientation this is equivalent to left alignment. For scripts that are inherently right to left such as Hebrew and Arabic, this is equivalent to right alignment. In http://www.w3.org/TR/2003/REC-SVG11-20030114/text.html#TextAlignmentProperties, replace: For Latin text in its usual orientation, this is comparable to right alignment. with: For Latin in its usual orientation this is equivalent to right alignment. For scripts that are inherently right to left such as Hebrew and Arabic, this is equivalent to left alignment. |
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: not effect event processing with: not affect event processing |
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 SVG, you can paint (i.e., fill or stroke) with:
SVG uses the general notion of a paint server. Paint servers are specified using a URI reference on a 'fill' or 'stroke' property. Gradients, patterns and solid colors are just specific types of paint servers. with: With SVG, you can paint (i.e., fill or stroke) with:
SVG uses the general notion of a paint server. Paint servers are specified using a URI reference on a 'fill' or 'stroke' property. Gradients and patterns are just specific types of paint servers. 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 SVG, you can fill (i.e., paint the interior) or stroke (i.e., paint the outline) of shapes and text using one of the following:
SVG uses the general notion of a paint server. Gradients and patterns are just specific types of built-in paint servers. The 'solidColor' element is another built-in paint server, described in Color. with: With SVG, you can fill (i.e., paint the interior) or stroke (i.e., paint the outline) of shapes and text using one of the following: SVG uses the general notion of a paint server. Gradients and patterns are just specific types of built-in paint servers. In http://www.w3.org/TR/2003/REC-SVG11-20030114/types.html#DataTypeColor, replace: <color>: The basic type <color> is a CSS2-compatible specification for a color in the sRGB color space [SRGB]. <color> applies to SVG's use of the 'color' property and is a component of the definitions of properties 'fill', 'stroke' 'stop-color', 'solid-color', 'flood-color' and 'lighting-color', which also offer optional ICC-based color specifications. with: <color>: The basic type <color> is a CSS2-compatible specification for a color in the sRGB color space [SRGB]. <color> applies to SVG's use of the 'color' property and is a component of the definitions of properties 'fill', 'stroke' 'stop-color', 'flood-color' and 'lighting-color', which also offer optional ICC-based color specifications. |
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: 16.6.1 Clipping paths, masking, and pointer eventsThe effects of masking and clipping differ with respect to pointer-events. A clip path is a geometric boundary, and a given point is clearly either inside or outside that boundary; thus, pointer events must be captured normally over the visible areas of a clipped element, and may be captured normally over the clipped areas depending upon the different values of the pointer-events property, as described in the definition of clipping paths. By contrast, a mask (like a filter) is not a binary transition, but a pixel operation, and different behavior for fully transparent and 'almost but not fully transparent' would be confusing; as a consequence, for elements with a mask applied, pointer-events must still be captured even in areas where the mask goes to zero opacity. If an author wishes to achieve an effect where the transparent parts of a mask allow pointer-events to pass to an element below, a combination of masking and clipping may be used. |
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 |
The clip-path should not affect the bounding-box, but the getRenderedBBox would be affected by stroke, markers, filters, and clip-path. Note: this erratum is resolved by another erratum, 'clippath-pointer-events' |
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: Vector-valued attributes are supported using the vector syntax of the attributeType domain. with: Vector-valued attributes are supported using the vector syntax of the attributeType domain. Per the SMIL specification, leading and trailing white space, and white space before and after semi-colon separators, is allowed and will be ignored. |
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: interface SVGFEConvolveMatrixElement : SVGElement, SVGFilterPrimitiveStandardAttributes { // Edge Mode Values const unsigned short SVG_EDGEMODE_UNKNOWN = 0; const unsigned short SVG_EDGEMODE_DUPLICATE = 1; const unsigned short SVG_EDGEMODE_WRAP = 2; const unsigned short SVG_EDGEMODE_NONE = 3; readonly attribute SVGAnimatedInteger orderX; readonly attribute SVGAnimatedInteger orderY; readonly attribute SVGAnimatedNumberList kernelMatrix; readonly attribute SVGAnimatedNumber divisor; readonly attribute SVGAnimatedNumber bias; readonly attribute SVGAnimatedInteger targetX; readonly attribute SVGAnimatedInteger targetY; readonly attribute SVGAnimatedEnumeration edgeMode; readonly attribute SVGAnimatedNumber kernelUnitLengthX; readonly attribute SVGAnimatedNumber kernelUnitLengthY; readonly attribute SVGAnimatedBoolean preserveAlpha; }; ...
with: interface SVGFEConvolveMatrixElement : SVGElement, SVGFilterPrimitiveStandardAttributes { // Edge Mode Values const unsigned short SVG_EDGEMODE_UNKNOWN = 0; const unsigned short SVG_EDGEMODE_DUPLICATE = 1; const unsigned short SVG_EDGEMODE_WRAP = 2; const unsigned short SVG_EDGEMODE_NONE = 3; readonly attribute SVGAnimatedString in1; readonly attribute SVGAnimatedInteger orderX; readonly attribute SVGAnimatedInteger orderY; readonly attribute SVGAnimatedNumberList kernelMatrix; readonly attribute SVGAnimatedNumber divisor; readonly attribute SVGAnimatedNumber bias; readonly attribute SVGAnimatedInteger targetX; readonly attribute SVGAnimatedInteger targetY; readonly attribute SVGAnimatedEnumeration edgeMode; readonly attribute SVGAnimatedNumber kernelUnitLengthX; readonly attribute SVGAnimatedNumber kernelUnitLengthY; readonly attribute SVGAnimatedBoolean preserveAlpha; }; ...
|
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:
If more characters are provided than <number>s, then
for each of these extra characters: (a) if an ancestor
'text' or
'tspan' element specifies a
supplemental rotation for the given character via a rotate attribute, then the given
supplemental rotation is applied to the given character,
else (b) no supplemental rotation occurs. with:
If more characters are provided than <number>s, then
for each of these extra characters the rotation value specified by the last number must be used. Example tspan04 uses the 'rotate' attribute on the 'tspan' element to rotate the glyphs to be rendered. This example shows a single text string in a 'tspan' element that contains more characters than the number of values specified in the 'rotate' attribute. In this case the last value specified in the 'rotate' attribute of the 'tspan' must be applied to the remaining characters in the string. <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="10cm" height="3cm" viewBox="0 0 1000 300" xmlns="http://www.w3.org/2000/svg" version="1.1"> <desc>Example tspan04 - The number of rotate values is less than the number of characters in the string.</desc> <text font-family="Verdana" font-size="55" fill="blue" > <tspan x="250" y="150" rotate="-30,0,30"> Hello, out there </tspan> </text> <!-- Show outline of canvas using 'rect' element --> <rect x="1" y="1" width="998" height="298" fill="none" stroke="blue" stroke-width="2" /> </svg>
View this example as SVG (SVG-enabled browsers only) Example tspan05 specifies the 'rotate' attribute on the 'text' element and on all but one of the child 'tspan' elements to rotate the glyphs to be rendered. The example demonstrates the propagation of the 'rotate' attribute. <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100%" height="100%" viewBox="0 0 500 120" xmlns="http://www.w3.org/2000/svg" version="1.1"> <desc> Example tspan05 - Propagation of rotation on text using child tspan elemtns. </desc> <text id="parent" font-family="Arial, sans-serif" font-size="32" fill="red" x="40" y="40" rotate="5,15,25,35,45,55"> Not <tspan id="child1" rotate="-10,-20,-30,-40" fill="orange"> all characters <tspan id="child2" rotate="70,60,50,40,30,20,10" fill="yellow"> in <tspan id="child3"> the </tspan> </tspan> <tspan id="child4" fill="orange" x="40" y="90"> text </tspan> have a </tspan> <tspan id="child5" rotate="-10" fill="blue"> specified </tspan> rotation </text> <!-- Show outline of canvas using 'rect' element --> <rect x="1" y="1" width="498" height="118" fill="none" stroke="blue" stroke-width="2" /> </svg>
View this example as SVG (SVG-enabled browsers only) Rotation of red text inside the 'text' element:
Rotation of the orange text inside the "child1" 'tspan' element:
Rotation of the yellow text inside the "child2" 'tspan' element:
Rotation of the blue text inside the "child5" 'tspan' element:
|
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: The following lists all of the elements which can be animated by an 'animateMotion' element: with: The following lists all of the elements which can be animated by an 'animateMotion' element: |
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: An SVG fragment identifier can come in three forms:
An SVG fragment identifier is defined as follows: SVGFragmentIdentifier ::= BareName | XPointerIDRef | SVGViewSpec BareName ::= XML_Name SVGViewSpec ::= 'svgView(' SVGViewAttributes ')' SVGViewAttributes ::= SVGViewAttribute | SVGViewAttribute ';' SVGViewAttributes SVGViewAttribute ::= viewBoxSpec | preserveAspectRatioSpec | transformSpec | zoomAndPanSpec | viewTargetSpec viewBoxSpec ::= 'viewBox(' ViewBoxParams ')' preserveAspectRatioSpec = 'preserveAspectRatio(' AspectParams ')' transformSpec ::= 'transform(' TransformParams ')' zoomAndPanSpec ::= 'zoomAndPan(' ZoomAndPanParams ')' viewTargetSpec ::= 'viewTarget(' ViewTargetParams ')' where:
Spaces are not allowed in fragment specifications; thus, commas are used to separate numeric values within an SVG view specification (e.g., #svgView(viewBox(0,0,200,200))) and semicolons are used to separate attributes (e.g., #svgView(viewBox(0,0,200,200);preserveAspectRatio(none))). When a source document performs a link into an SVG document via an HTML [HTML4] anchor element (i.e., <a href=...> element in HTML) or an XLink specification [XLINK], then the SVG fragment identifier specifies the initial view into the SVG document, as follows:
with: An SVG fragment identifier can come in two forms:
An SVG fragment identifier is defined as follows: SVGFragmentIdentifier ::= BareName | SVGViewSpec BareName ::= XML_Name SVGViewSpec ::= 'svgView(' SVGViewAttributes ')' SVGViewAttributes ::= SVGViewAttribute | SVGViewAttribute ';' SVGViewAttributes SVGViewAttribute ::= viewBoxSpec | preserveAspectRatioSpec | transformSpec | zoomAndPanSpec | viewTargetSpec viewBoxSpec ::= 'viewBox(' ViewBoxParams ')' preserveAspectRatioSpec = 'preserveAspectRatio(' AspectParams ')' transformSpec ::= 'transform(' TransformParams ')' zoomAndPanSpec ::= 'zoomAndPan(' ZoomAndPanParams ')' viewTargetSpec ::= 'viewTarget(' ViewTargetParams ')' where:
Spaces are not allowed in fragment specifications; thus, commas are used to separate numeric values within an SVG view specification (e.g., #svgView(viewBox(0,0,200,200))) and semicolons are used to separate attributes (e.g., #svgView(viewBox(0,0,200,200);preserveAspectRatio(none))). When a source document performs a link into an SVG document via an HTML [HTML4] anchor element (i.e., <a href=...> element in HTML) or an XLink specification [XLINK], then the SVG fragment identifier specifies the initial view into the SVG document, as follows:
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: URI references are defined in either of the following forms: <URI-reference> = [ <absoluteURI> | <relativeURI> ] [ "#" <elementID> ] -or- <URI-reference> = [ <absoluteURI> | <relativeURI> ] [ "#xpointer(id(" <elementID> "))" ] where <elementID> is the ID of the referenced element. (Note that the two forms above (i.e., #<elementID> and #xpointer(id(<elementID>))) are formulated in syntaxes compatible with "XML Pointer Language (XPointer)" [XPTR]. These two formulations of URI references are the only XPointer formulations that are required in SVG 1.0 user agents.) SVG supports two types of URI references:
with: URI references are defined in the following form: <URI-reference> = [ <absoluteURI> | <relativeURI> ] [ "#" <elementID> ] where <elementID> is the ID of the referenced element. SVG supports two types of URI references:
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#xlinkRefAttrsEmbed, replace: If the URI reference is relative, its absolute version must be computed by the method of [XML-Base] before use. For locators into XML resources, the format of the fragment identifier (if any) used within the URI reference is specified by the XPointer specification [XPTR]. with: If the URI reference is relative, its absolute version must be computed by the method of [XML-Base] before use. |
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: A DOM application can use the hasFeature method of the DOMImplementation interface to verify that the interfaces listed in this section are supported. The list of available interfaces is provided in section Feature strings for the hasFeature method call. with: A DOM application can use the hasFeature method of the DOMImplementation interface to verify that the interfaces listed in this section are supported. The list of available interfaces is provided in section Feature strings for the hasFeature method call. When an object is accessed via the SVG DOM that hasn't been specified in the document, e.g. x.baseVal and the 'x' attribute was not provided, a corresponding SVG DOM object is created and initialized with a value that is equivalent to the value used in rendering when the attribute was not provided. The returned object does not affect rendering until it is modified for the first time. After the first modification the object becomes live, meaning that any modifications made to the corresponding attribute are immediately reflected in the object. Note that for some attributes it may be hard to find a good initial value:
|
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: A DOM application can use the hasFeature method of the DOMImplementation interface to verify that the interfaces listed in this section are supported. The list of available interfaces is provided in section Feature strings for the hasFeature method call. with: A DOM application can use the hasFeature method of the DOMImplementation interface to verify that the interfaces listed in this section are supported. The list of available interfaces is provided in section Feature strings for the hasFeature method call. All SVG DOM objects that directly correspond to an attribute, e.g. the SVGAnimatedLength 'ry' in an SVGRectElement, are live. This means that any changes made to the attribute are immediately reflected in the corresponding SVG DOM object. 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:
The attributes below apply to sub-elements 'feFuncR', 'feFuncG', 'feFuncB' and 'feFuncA' define the transfer functions. with:
The following rules apply to sub-elements in the feComponentTranfer element:
The attributes below apply to sub-elements 'feFuncR', 'feFuncG', 'feFuncB' and 'feFuncA' define the transfer functions. In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feComponentTransfer, replace: Example feComponentTransfer shows examples of the four types of feComponentTransfer operations. <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="8cm" height="4cm" viewBox="0 0 800 400" version="1.1" xmlns="http://www.w3.org/2000/svg"> <title>Example feComponentTransfer - Examples of feComponentTransfer operations</title> <desc>Four text strings showing the effects of feComponentTransfer: an identity function acting as a reference, use of the feComponentTransfer table option, use of the feComponentTransfer linear option, and use of the feComponentTransfer gamma option.</desc> <defs> <linearGradient id="MyGradient" gradientUnits="userSpaceOnUse" x1="100" y1="0" x2="600" y2="0"> <stop offset="0" stop-color="#ff0000" /> <stop offset=".33" stop-color="#00ff00" /> <stop offset=".67" stop-color="#0000ff" /> <stop offset="1" stop-color="#000000" /> </linearGradient> <filter id="Identity" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="identity"/> <feFuncG type="identity"/> <feFuncB type="identity"/> <feFuncA type="identity"/> </feComponentTransfer> </filter> <filter id="Table" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="table" tableValues="0 0 1 1"/> <feFuncG type="table" tableValues="1 1 0 0"/> <feFuncB type="table" tableValues="0 1 1 0"/> </feComponentTransfer> </filter> <filter id="Linear" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="linear" slope=".5" intercept=".25"/> <feFuncG type="linear" slope=".5" intercept="0"/> <feFuncB type="linear" slope=".5" intercept=".5"/> </feComponentTransfer> </filter> <filter id="Gamma" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="gamma" amplitude="2" exponent="5" offset="0"/> <feFuncG type="gamma" amplitude="2" exponent="3" offset="0"/> <feFuncB type="gamma" amplitude="2" exponent="1" offset="0"/> </feComponentTransfer> </filter> </defs> <rect fill="none" stroke="blue" x="1" y="1" width="798" height="398"/> <g font-family="Verdana" font-size="75" font-weight="bold" fill="url(#MyGradient)" > <rect x="100" y="0" width="600" height="20" /> <text x="100" y="90">Identity</text> <text x="100" y="190" filter="url(#Table)" >TableLookup</text> <text x="100" y="290" filter="url(#Linear)" >LinearFunc</text> <text x="100" y="390" filter="url(#Gamma)" >GammaFunc</text> </g> </svg> with: Example feComponentTransfer shows examples of how feComponentTransfer can be applied to a gradient fill (shown first). The four types of feComponentTransfer operations are applied to the next four rects respectively in the example. <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="8cm" height="8cm" viewBox="0 0 800 800" version="1.1" xmlns="http://www.w3.org/2000/svg"> <title> Example feComponentTransfer - Examples of feComponentTransfer operations </title> <desc> A gradient fill rect (shown first) with examples of different feComponentTransfer effects applied (next 4 rects): an identity function, use of the feComponentTransfer table option, use of the feComponentTransfer linear option, and use of the feComponentTransfer gamma option. </desc> <defs> <linearGradient id="ReferenceGradient" gradientUnits="userSpaceOnUse" x1="100" y1="0" x2="600" y2="0"> <stop offset="0" stop-color="#ff0000"/> <stop offset=".33" stop-color="#00ff00"/> <stop offset=".67" stop-color="#0000ff"/> <stop offset="1" stop-color="#000000"/> </linearGradient> <filter id="Identity" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="identity"/> <feFuncG type="identity"/> <feFuncB type="identity"/> <feFuncA type="identity"/> </feComponentTransfer> </filter> <filter id="Table" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="table" tableValues="0 0 1 1"/> <feFuncG type="table" tableValues="1 1 0 0"/> <feFuncB type="table" tableValues="0 1 1 0"/> </feComponentTransfer> </filter> <filter id="Linear" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="linear" slope=".5" intercept=".25"/> <feFuncG type="linear" slope=".5" intercept="0"/> <feFuncB type="linear" slope=".5" intercept=".5"/> </feComponentTransfer> </filter> <filter id="Gamma" filterUnits="objectBoundingBox" x="0%" y="0%" width="100%" height="100%"> <feComponentTransfer> <feFuncR type="gamma" amplitude="2" exponent="5" offset="0"/> <feFuncG type="gamma" amplitude="2" exponent="3" offset="0"/> <feFuncB type="gamma" amplitude="2" exponent="1" offset="0"/> </feComponentTransfer> </filter> </defs> <g fill="url(#ReferenceGradient)"> <rect x="100" y="50" width="600" height="40" /> <rect x="100" y="200" width="600" height="40" filter="url(#Identity)"/> <rect x="100" y="350" width="600" height="40" filter="url(#Table)"/> <rect x="100" y="500" width="600" height="40" filter="url(#Linear)"/> <rect x="100" y="650" width="600" height="40" filter="url(#Gamma)"/> </g> <g font-weight="bold" font-family="Courier New" font-size="45" fill="black"> <text x="100" y="140">Gradient Fill</text> <text x="100" y="290">type='Identity'</text> <text x="100" y="440">type='TableLookup'</text> <text x="100" y="590">type='LinearFunc'</text> <text x="100" y="740">type='GammaFunc'</text> </g> <rect fill="none" stroke="blue" x="1" y="1" width="796" height="796"/> </svg>
|
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: patternUnits, patternTransform with: patternUnits, patternContentUnits, patternTransform |
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: The SVGTextContentElement interface is inherited by various text-related interfaces, such as SVGTextElement, SVGTSpanElement, SVGTRefElement, SVGAltGlyphElement and SVGTextPathElement. with: The SVGTextContentElement interface is inherited by various text-related interfaces, such as SVGTextElement, SVGTSpanElement, SVGTRefElement, SVGAltGlyphElement and SVGTextPathElement. For the methods on this interface that refer to an index to a character or a number of characters, these references are to be interpreted as an index to a UTF-16 code unit or a number of UTF-16 code units, respectively. This is for consistency with DOM Level 2 Core, where methods on the CharacterData interface use UTF-16 code units as indexes and counts within the character data. Thus for example, if the text content of a 'text' element is a single non-BMP character, such as U+10000, then invoking getNumberOfChars on that element will return 2 since there are two UTF-16 code units (the surrogate pair) used to represent that one character. |
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 |
getNumberOfChars() should return number of UTF-16 codepoints corresponding to all of the characters available for rendering. (There perhaps should be an additional method for querying whether a particular character is rendered or not.) (Edit 23 June 2008) The UTF-16 language has been removed from the changed text, since it is now redundant with that in the References to characters in SVGTextContentElement should be UTF-16 code units erratum. |
||||||
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: For other devices or environments where physical pixel sizes are not known, then an algorithm similar to the CSS2 definition of a "pixel" can be used instead. with:
For other devices or environments where physical pixel sizes are not known, then an algorithm similar to the CSS2 definition of a "pixel" can be used instead. Note that null is returned if this element is not hooked into the document tree. This method would have been more aptly named as |
Container Element rewording | |
---|---|
Status | Proposed |
Category | Editorial |
In reference to | |
Description |
If you've implemented progressive rendering, this does have an effect. It's only in the context of the content that the 'can' is there. In that context, the text is fine. Maybe add "(only if there is an externalResource that is being used in that container, ie. an image element)". In addition, there is an erroneous "using" and the "specify" should be replaced with "specifically". |
Resolution | Add wording to the effect of the bracketed comment, and fix up the strange wording. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#ExternalResourcesRequired, replace: Because setting externalResourcesRequired="true" on a container element can have the effect of disabling progressive display of the contents of that container, tools that generate SVG content are cautioned against using simply setting externalResourcesRequired="true" on the outermost 'svg' element on a universal basis. Instead, it is better to specify externalResourcesRequired="true" on those particular graphics elements or container elements which specify need the availability of external resources in order to render properly. with: Because setting externalResourcesRequired="true" on a container element will have the effect of disabling progressive display of the contents of that container, if that container includes elements that reference external resources, tools that generate SVG content are cautioned against simply setting externalResourcesRequired="true" on the outermost 'svg' element on a universal basis. Instead, it is better to specify externalResourcesRequired="true" on those particular graphics elements or container elements which specifically need the availability of external resources in order to render properly. |
ElementTimeControl interface | |||||||
---|---|---|---|---|---|---|---|
Status | Proposed | ||||||
Category | Substantive | ||||||
Reported by | Vincent Hardy | ||||||
Comment | Cameron McCormack | ||||||
Description |
SVG 1.1 claims that the ElementTimeControl interface defined therein is copied from SMIL Animation. However, there are discrepancies between the definitions in SMIL Animation and those in SVG 1.1.
In addition, SVG 1.1 has a version of the ElementTimeControl Java interface copied from
SMIL Animation, but with the package changed to |
||||||
Resolution |
The description of the ElementTimeControl interface should be
synchronized with that in SMIL Animation
plus some changes (to fix errors in the IDL that say the four methods return |
||||||
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/animate.html#DOMInterfaces, replace: [the entire Interface ElementTimeControl subsection] with:
SMIL Animation supports several methods for controlling the behavior of
animation: <animate begin="indefinite" end="indefinite" .../>
If a DOM method call is made to begin or end the element (using
The expectation of the following interface is that an instance of the
ElementTimeControl interface can be obtained by using binding-specific
casting methods on an instance of an animate element. A DOM application can use the
For the corresponding Java binding, see section 6.4 of SMIL Animation [SMILANIM]. |
TimeEvent interface | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
In reference to | |
Comment | Cameron McCormack |
Description |
SVG 1.1 has a version of the TimeEvent Java interface copied from
SMIL Animation,
but with the package changed to |
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: The corresponding Java binding: package org.w3c.dom.svg; import org.w3c.dom.events.Event; import org.w3c.dom.views.AbstractView; public interface TimeEvent extends Event { public AbstractView getView( ); public int getDetail( ); void initTimeEvent ( String typeArg, AbstractView viewArg, int detailArg ); } with: For the corresponding Java binding, see section 6.4 of SMIL Animation [SMILANIM]. |
SVGLoad does not bubble | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Olli Pettay |
In reference to | |
Comment | 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: A SVGLoad event is dispatched only to the element to which the event applies; it is not dispatched to its ancestors. For example, if an 'image' element and its parent 'g' element both have event listeners for SVGLoad events, when the 'image' element has been loaded, only its event listener will be invoked. (The 'g' element's event listener will indeed get invoked, but the invocation will happen when the 'g' itself has been loaded.) with: The SVGLoad event does not bubble. |
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 'viewBox' attribute mistakenly referred to as 'fitBoxToViewport'. | ||||||
Resolution | The references to 'fitBoxToViewport' will be corrected to 'viewBox'. | ||||||
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 'values' attribute. |
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: <feColorMatrix type="saturate" in="SourceGraphic" values="40%"/> with: <feColorMatrix type="saturate" in="SourceGraphic" values="0.4"/> |
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: Note that the specification of a <number> is different for property values than for XML attribute values. 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 'pointer-events' and how they are affected by a clipping path will be added. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/masking.html#EstablishingANewClippingPath, insert: 14.3.6 Clipping paths, geometry, and pointer eventsA clipping path is conceptually equivalent to a custom viewport for the referencing element. Thus, it affects the rendering of an element, but not the element's inherent geometry. The bounding box of a clipped element (that is, an element which references a 'clipPath' element via a 'clip-path' property, or a child of the referencing element) must remain the same as if it were not clipped. With regards to pointer-events, while the visible parts of a clipped element receive pointer events normally, parts of a clipped element which are outside the extent of the clipping path must be treated as if they have a 'visibility' property value of 'hidden'. Therefore, an element which has 'pointer-events' property values which depend upon the visibility of the element (i.e. 'visiblePainted', 'visibleFill', 'visibleStroke', 'visible') will not receive pointer events outside of the clipping region, regardless of the setting of the 'visibility' property. Within the clipping region the 'visibility' property acts normally on event sensitivity. For example, a circle with a radius of 10 which is clipped to a circle with a radius of 5 will not receive 'click' events outside the smaller radius if it has the default 'pointer-events' property value of 'visiblePainted', but will if has the property value of 'all' or 'fill', for example. Note that for a child element of an element that references a clip-path, the relevant 'pointer-events' value is that of the target element (i.e., the child element), not the parent element. In other words, if a 'g' element has both a 'clip-path' property and the 'pointer-events' property value of 'visible', but a 'circle' child element has a 'pointer-events' property value of 'all', then the circle would be sensitive to pointer events even if it were clipped. Note that this property-dependent event clipping behavior applies only to elements clipped by the 'clip-path' property. For elements clipped by elements that establish a new viewport, such as nested 'svg' elements, events are always clipped for the clipped portions of a target element. |
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: interface SVGLength { ... void newValueSpecifiedUnits ( in unsigned short unitType, in float valueInSpecifiedUnits ); void convertToSpecifiedUnits ( in unsigned short unitType ); }; with: interface SVGLength { ... void newValueSpecifiedUnits ( in unsigned short unitType, in float valueInSpecifiedUnits ) raises( DOMException ); void convertToSpecifiedUnits ( in unsigned short unitType ) raises( DOMException ); }; 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: interface SVGAngle { ... void newValueSpecifiedUnits ( in unsigned short unitType, in float valueInSpecifiedUnits ); void convertToSpecifiedUnits ( in unsigned short unitType ); }; with: interface SVGAngle { ... void newValueSpecifiedUnits ( in unsigned short unitType, in float valueInSpecifiedUnits ) raises( DOMException ); void convertToSpecifiedUnits ( in unsigned short unitType ) raises( DOMException ); }; 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: interface SVGTransform { ... void setMatrix ( in SVGMatrix matrix ); void setTranslate ( in float tx, in float ty ); void setScale ( in float sx, in float sy ); void setRotate ( in float angle, in float cx, in float cy ); void setSkewX ( in float angle ); void setSkewY ( in float angle ); }; with: interface SVGTransform { ... void setMatrix ( in SVGMatrix matrix ) raises( DOMException ); void setTranslate ( in float tx, in float ty ) raises( DOMException ); void setScale ( in float sx, in float sy ) raises( DOMException ); void setRotate ( in float angle, in float cx, in float cy ) raises( DOMException ); void setSkewX ( in float angle ) raises( DOMException ); void setSkewY ( in float angle ) raises( DOMException ); }; 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: interface SVGTransformList { ... SVGTransform consolidate ( ); }; with: interface SVGTransformList { ... SVGTransform consolidate ( ) raises( DOMException ); }; 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: interface SVGMarkerElement : ... void setOrientToAuto ( ); void setOrientToAngle ( in SVGAngle angle ); }; with: interface SVGMarkerElement : ... void setOrientToAuto ( ) raises( DOMException ); void setOrientToAngle ( in SVGAngle angle ) raises( DOMException ); }; 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: interface SVGFilterElement : ... void setFilterRes ( in unsigned long filterResX, in unsigned long filterResY ); }; with: interface SVGFilterElement : ... void setFilterRes ( in unsigned long filterResX, in unsigned long filterResY ) raises( DOMException ); }; 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: interface SVGFEGaussianBlurElement : ... void setStdDeviation ( in float stdDeviationX, in float stdDeviationY ); }; with: interface SVGFEGaussianBlurElement : ... void setStdDeviation ( in float stdDeviationX, in float stdDeviationY ) raises( DOMException ); }; 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: A subpath (see Paths) consisting of a single moveto is not stroked. A subpath consisting of a moveto and lineto to the same exact location or a subpath consisting of a moveto and a closepath will be stroked only if the 'stroke-linecap' property is set to "round", producing a circle centered at the given point. with: A subpath (see Paths) consisting of a single moveto shall not be stroked. A subpath consisting of a moveto and lineto to the same exact location or a subpath consisting of a moveto and a closepath shall not be stroked if the 'stroke-linecap' property has a value of butt and shall be stroked if the 'stroke-linecap' property has a value of round or square, producing respectively a circle or a square centered at the given point. |
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:
The term "outermost 'svg' element" occurs in the following locations:
The markup for all instances of the term "outermost 'svg' element" will be linked to the new definition in the Introduction chapter. |
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: This appendix contains the complete OMG IDL for the SVG Document Object Model definitions. The IDL is also available at: http://www.w3.org/TR/2001/REC-SVG-20010904/idl.zip. with: This appendix contains the complete OMG IDL for the SVG Document Object Model definitions. The IDL is also available at: http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.zip. |
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: Feature Sets - SVG 1.1 - 20030114 with: Feature Strings - SVG 1.1 - 20030114 |
Clarify feTurbulence seed value type | |
---|---|
Status | Proposed |
Category | Editorial |
Reported by | Cameron McCormack |
In reference to | |
Description | Currently in the specification the 'seed' value of 'feTurbulence' is of type NUMBER. The algorithm treats the value as an integer. We need to clarify how to use the value. |
Resolution | We will clarify that the value of 'seed' is rounded. |
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: The 'color-interpolation-filters' property only applies to the in2 source image and does not apply to the in source image. with: The 'color-interpolation-filters' property only applies to the in2 source image and does not apply to the in source image. The in source image must remain in its current color space. |
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: If L.S is positive, no light is present. (Lr = Lg = Lb = 0) with: If L.S is positive, no light is present. (Lr = Lg = Lb = 0). If limitingConeAngle is specified, -L.S < cos(limitingConeAngle) also indicates that no light is present. |
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: interface SVGSVGElement : SVGElement, SVGTests, SVGLangSpace, SVGExternalResourcesRequired, SVGStylable, SVGLocatable, SVGFitToViewBox, SVGZoomAndPan, events::EventTarget, events::DocumentEvent, css::ViewCSS, css::DocumentCSS { readonly attribute SVGAnimatedLength x; readonly attribute SVGAnimatedLength y; readonly attribute SVGAnimatedLength width; readonly attribute SVGAnimatedLength height; attribute DOMString contentScriptType; // raises DOMException on setting attribute DOMString contentStyleType; // raises DOMException on setting readonly attribute SVGRect viewport; readonly attribute float pixelUnitToMillimeterX; readonly attribute float pixelUnitToMillimeterY; readonly attribute float screenPixelToMillimeterX; readonly attribute float screenPixelToMillimeterY; attribute boolean useCurrentView; // raises DOMException on setting readonly attribute SVGViewSpec currentView; attribute float currentScale; // raises DOMException on setting readonly attribute SVGPoint currentTranslate; unsigned long suspendRedraw ( in unsigned long max_wait_milliseconds ); void unsuspendRedraw ( in unsigned long suspend_handle_id ) raises( DOMException ); void unsuspendRedrawAll ( ); void forceRedraw ( ); void pauseAnimations ( ); void unpauseAnimations ( ); boolean animationsPaused ( ); float getCurrentTime ( ); void setCurrentTime ( in float seconds ); NodeList getIntersectionList ( in SVGRect rect, in SVGElement referenceElement ); NodeList getEnclosureList ( in SVGRect rect, in SVGElement referenceElement ); boolean checkIntersection ( in SVGElement element, in SVGRect rect ); boolean checkEnclosure ( in SVGElement element, in SVGRect rect ); void deselectAll ( ); SVGNumber createSVGNumber ( ); SVGLength createSVGLength ( ); SVGAngle createSVGAngle ( ); SVGPoint createSVGPoint ( ); SVGMatrix createSVGMatrix ( ); SVGRect createSVGRect ( ); SVGTransform createSVGTransform ( ); SVGTransform createSVGTransformFromMatrix ( in SVGMatrix matrix ); Element getElementById ( in DOMString elementId ); }; with: interface SVGSVGElement : SVGElement, SVGTests, SVGLangSpace, SVGExternalResourcesRequired, SVGStylable, SVGLocatable, SVGFitToViewBox, SVGZoomAndPan, events::EventTarget, events::DocumentEvent, css::ViewCSS, css::DocumentCSS { readonly attribute SVGAnimatedLength x; readonly attribute SVGAnimatedLength y; readonly attribute SVGAnimatedLength width; readonly attribute SVGAnimatedLength height; attribute DOMString contentScriptType; // raises DOMException on setting attribute DOMString contentStyleType; // raises DOMException on setting readonly attribute SVGRect viewport; readonly attribute float pixelUnitToMillimeterX; readonly attribute float pixelUnitToMillimeterY; readonly attribute float screenPixelToMillimeterX; readonly attribute float screenPixelToMillimeterY; attribute boolean useCurrentView; // raises DOMException on setting readonly attribute SVGViewSpec currentView; attribute float currentScale; // raises DOMException on setting readonly attribute SVGPoint currentTranslate; unsigned long suspendRedraw ( in unsigned long max_wait_milliseconds ); void unsuspendRedraw ( in unsigned long suspend_handle_id ) raises( DOMException ); void unsuspendRedrawAll ( ); void forceRedraw ( ); void pauseAnimations ( ); void unpauseAnimations ( ); boolean animationsPaused ( ); float getCurrentTime ( ); void setCurrentTime ( in float seconds ); NodeList getIntersectionList ( in SVGRect rect, in SVGElement referenceElement ); NodeList getEnclosureList ( in SVGRect rect, in SVGElement referenceElement ); boolean checkIntersection ( in SVGElement element, in SVGRect rect ); boolean checkEnclosure ( in SVGElement element, in SVGRect rect ); void deselectAll ( ); SVGNumber createSVGNumber ( ); SVGLength createSVGLength ( ); SVGAngle createSVGAngle ( ); SVGPoint createSVGPoint ( ); SVGMatrix createSVGMatrix ( ); SVGRect createSVGRect ( ); SVGTransform createSVGTransform ( ); SVGTransform createSVGTransformFromMatrix ( in SVGMatrix matrix ); Element getElementById ( in DOMString elementId ); };
The NodeList returned from the 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: The surface described by the input alpha image Ain (x,y) is: Z (x,y) = surfaceScale * Ain (x,y) with: The surface described by the input alpha image I(x,y) is: Z (x,y) = surfaceScale * I(x,y) |
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: <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="400px" height="150px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Example NewCoordSys - New user coordinate system</desc> <g fill="none" stroke="black" stroke-width="3" > <!-- Draw the axes of the original coordinate system --> <line x1="0" y1="1.5" x2="400" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="150" /> </g> <g> <text x="30" y="30" font-size="20" font-family="Verdana" > ABC (orig coord system) </text> </g> <!-- Establish a new coordinate system, which is shifted (i.e., translated) from the initial coordinate system by 50 user units along each axis. --> <g transform="translate(50,50)"> <g fill="none" stroke="red" stroke-width="3" > <!-- Draw lines of length 50 user units along the axes of the new coordinate system --> <line x1="0" y1="0" x2="50" y2="0" stroke="red" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="30" y="30" font-size="20" font-family="Verdana" > ABC (translated coord system) </text> </g> </svg> with: <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="400px" height="150px" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Example NewCoordSys - New user coordinate system</desc> <g fill="none" stroke="black" stroke-width="3" > <!-- Draw the axes of the original coordinate system --> <line x1="0" y1="1.5" x2="400" y2="1.5" /> <line x1="1.5" y1="0" x2="1.5" y2="150" /> </g> <g> <text x="30" y="30" font-size="20" font-family="Verdana" > ABC (orig coord system) </text> </g> <!-- Establish a new coordinate system, which is shifted (i.e., translated) from the initial coordinate system by 50 user units along each axis. --> <g transform="translate(50,50)"> <g fill="none" stroke="red" stroke-width="3" > <!-- Draw lines of length 50 user units along the axes of the new coordinate system --> <line x1="0" y1="0" x2="50" y2="0" /> <line x1="0" y1="0" x2="0" y2="50" /> </g> <text x="30" y="30" font-size="20" font-family="Verdana" > ABC (translated coord system) </text> </g> </svg> In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#GeographicCoordinates, replace: <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100" height="100" viewBox="0 0 1000 1000" version="1.1" xmlns="http://www.w3.org/2000/svg"> <metadata> <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs = "http://www.ogc.org/crs" xmlns:svg="http://wwww.w3.org/2000/svg"> <rdf:Description> <!-- The Coordinate Reference System is described through an URI. --> <crs:CoordinateReferenceSystem svg:transform="rotate(-90)" rdf:resource=""http://www.example.org/srs/epsg.xml#4326"/> </rdf:Description> </rdf:RDF> </metadata> <!-- The actual map content --> </svg> with: <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100" height="100" viewBox="0 0 1000 1000" version="1.1" xmlns="http://www.w3.org/2000/svg"> <metadata> <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs = "http://www.ogc.org/crs" xmlns:svg="http://www.w3.org/2000/svg"> <rdf:Description> <!-- The Coordinate Reference System is described through an URI. --> <crs:CoordinateReferenceSystem svg:transform="rotate(-90)" rdf:resource=""http://www.example.org/srs/epsg.xml#4326"/> </rdf:Description> </rdf:RDF> </metadata> <!-- The actual map content --> </svg> In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#GeographicCoordinates, replace: <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100" height="100" viewBox="0 0 1000 1000" version="1.1" xmlns="http://www.w3.org/2000/svg"> <metadata> <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs = "http://www.ogc.org/crs" xmlns:svg="http://wwww.w3.org/2000/svg"> <rdf:Description> <!-- In case of a well-known Coordinate Reference System an 'Identifier' is enough to describe the CRS --> <crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)"> <crs:Identifier> <crs:code>4326</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:CoordinateReferenceSystem> </rdf:Description> </rdf:RDF> </metadata> <!-- The actual map content --> </svg> with: <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100" height="100" viewBox="0 0 1000 1000" version="1.1" xmlns="http://www.w3.org/2000/svg"> <metadata> <rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs = "http://www.ogc.org/crs" xmlns:svg="http://www.w3.org/2000/svg"> <rdf:Description> <!-- In case of a well-known Coordinate Reference System an 'Identifier' is enough to describe the CRS --> <crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)"> <crs:Identifier> <crs:code>4326</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:CoordinateReferenceSystem> </rdf:Description> </rdf:RDF> </metadata> <!-- The actual map content --> </svg> In http://www.w3.org/TR/2003/REC-SVG11-20030114/coords.html#GeographicCoordinates, replace: <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100" height="100" viewBox="0 0 1000 1000" version="1.1" xmlns="http://www.w3.org/2000/svg"> <metadata> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs="http://www.ogc.org/crs" xmlns:svg="http://wwww.w3.org/2000/svg"> <rdf:Description> <!-- For other CRS it should be entirely defined --> <crs:CoordinateReferenceSystem svg:transform="scale(1,-1)"> <crs:NameSet> <crs:name>Mercator projection of WGS84</crs:name> </crs:NameSet> <crs:ProjectedCRS> <!-- The actual definition of the CRS --> <crs:CartesianCoordinateSystem> <crs:dimension>2</crs:dimension> <crs:CoordinateAxis> <crs:axisDirection>north</crs:axisDirection> <crs:AngularUnit> <crs:Identifier> <crs:code>9108</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:AngularUnit> </crs:CoordinateAxis> <crs:CoordinateAxis> <crs:axisDirection>east</crs:axisDirection> <crs:AngularUnit> <crs:Identifier> <crs:code>9108</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:AngularUnit> </crs:CoordinateAxis> </crs:CartesianCoordinateSystem> <crs:CoordinateReferenceSystem> <!-- the reference system of that projected system is WGS84 which is EPSG 4326 in EPSG codeSpace --> <crs:NameSet> <crs:name>WGS 84</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>4326</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:CoordinateReferenceSystem> <crs:CoordinateTransformationDefinition> <crs:sourceDimensions>2</crs:sourceDimensions> <crs:targetDimensions>2</crs:targetDimensions> <crs:ParameterizedTransformation> <crs:TransformationMethod> <!-- the projection is a Mercator projection which is EPSG 9805 in EPSG codeSpace --> <crs:NameSet> <crs:name>Mercator</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>9805</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:description>Mercator (2SP)</crs:description> </crs:TransformationMethod> <crs:Parameter> <crs:NameSet> <crs:name>Latitude of 1st standart parallel</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8823</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> <crs:Parameter> <crs:NameSet> <crs:name>Longitude of natural origin</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8802</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> <crs:Parameter> <crs:NameSet> <crs:name>False Easting</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8806</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> <crs:Parameter> <crs:NameSet> <crs:name>False Northing</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8807</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> </crs:ParameterizedTransformation> </crs:CoordinateTransformationDefinition> </crs:ProjectedCRS> </crs:CoordinateReferenceSystem> </rdf:Description> </rdf:RDF> </metadata> <!-- the actual map content --> </svg> with: <?xml version="1.0"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="100" height="100" viewBox="0 0 1000 1000" version="1.1" xmlns="http://www.w3.org/2000/svg"> <metadata> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:crs="http://www.ogc.org/crs" xmlns:svg="http://www.w3.org/2000/svg"> <rdf:Description> <!-- For other CRS it should be entirely defined --> <crs:CoordinateReferenceSystem svg:transform="scale(1,-1)"> <crs:NameSet> <crs:name>Mercator projection of WGS84</crs:name> </crs:NameSet> <crs:ProjectedCRS> <!-- The actual definition of the CRS --> <crs:CartesianCoordinateSystem> <crs:dimension>2</crs:dimension> <crs:CoordinateAxis> <crs:axisDirection>north</crs:axisDirection> <crs:AngularUnit> <crs:Identifier> <crs:code>9108</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:AngularUnit> </crs:CoordinateAxis> <crs:CoordinateAxis> <crs:axisDirection>east</crs:axisDirection> <crs:AngularUnit> <crs:Identifier> <crs:code>9108</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:AngularUnit> </crs:CoordinateAxis> </crs:CartesianCoordinateSystem> <crs:CoordinateReferenceSystem> <!-- the reference system of that projected system is WGS84 which is EPSG 4326 in EPSG codeSpace --> <crs:NameSet> <crs:name>WGS 84</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>4326</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> </crs:CoordinateReferenceSystem> <crs:CoordinateTransformationDefinition> <crs:sourceDimensions>2</crs:sourceDimensions> <crs:targetDimensions>2</crs:targetDimensions> <crs:ParameterizedTransformation> <crs:TransformationMethod> <!-- the projection is a Mercator projection which is EPSG 9805 in EPSG codeSpace --> <crs:NameSet> <crs:name>Mercator</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>9805</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:description>Mercator (2SP)</crs:description> </crs:TransformationMethod> <crs:Parameter> <crs:NameSet> <crs:name>Latitude of 1st standart parallel</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8823</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> <crs:Parameter> <crs:NameSet> <crs:name>Longitude of natural origin</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8802</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> <crs:Parameter> <crs:NameSet> <crs:name>False Easting</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8806</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> <crs:Parameter> <crs:NameSet> <crs:name>False Northing</crs:name> </crs:NameSet> <crs:Identifier> <crs:code>8807</crs:code> <crs:codeSpace>EPSG</crs:codeSpace> <crs:edition>5.2</crs:edition> </crs:Identifier> <crs:value>0</crs:value> </crs:Parameter> </crs:ParameterizedTransformation> </crs:CoordinateTransformationDefinition> </crs:ProjectedCRS> </crs:CoordinateReferenceSystem> </rdf:Description> </rdf:RDF> </metadata> <!-- the actual map content --> </svg> |
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 'contentScriptType' defaults to "text/ecmascript" even though it lacks a direct 'svg' parent. The specification needs to clarify how this should work and if implementations are allowed to cross namespace boundaries in search of an 'svg' parent element. Additionally, clarification of the case where there is no 'svg' parent elment. |
Resolution | We will clarify that 'contentScriptType' applies only to the current SVG document fragment. |
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: <!ENTITY % SVG.script.extra.content "" > <!ENTITY % SVG.script.element "INCLUDE" > <![%SVG.script.element;[ <!ENTITY % SVG.script.content "( #PCDATA %SVG.script.extra.content; )*" > <!ELEMENT %SVG.script.qname; %SVG.script.content; > <!-- end of SVG.script.element -->]]> <!ENTITY % SVG.script.attlist "INCLUDE" > <![%SVG.script.attlist;[ <!ATTLIST %SVG.script.qname; %SVG.Core.attrib; %SVG.XLink.attrib; %SVG.External.attrib; type %ContentType.datatype; #REQUIRED > with: <!ENTITY % SVG.script.extra.content "" > <!ENTITY % SVG.script.element "INCLUDE" > <![%SVG.script.element;[ <!ENTITY % SVG.script.content "( #PCDATA %SVG.script.extra.content; )*" > <!ELEMENT %SVG.script.qname; %SVG.script.content; > <!-- end of SVG.script.element -->]]> <!ENTITY % SVG.script.attlist "INCLUDE" > <![%SVG.script.attlist;[ <!ATTLIST %SVG.script.qname; %SVG.Core.attrib; %SVG.XLink.attrib; %SVG.External.attrib; type %ContentType.datatype; #IMPLIED > In http://www.w3.org/TR/2003/REC-SVG11-20030114/script.html#ScriptElement, replace: Attribute definitions:
with: Attribute definitions:
|
Remove exception on unsuspendRedraw | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Status | Proposed | |||||||||
Category | Substantive | |||||||||
Reported by | Erik Dahlström | |||||||||
In reference to | ||||||||||
Description |
The method unsuspendRedraw on SVGSVGElement in the 1.1 DOM is defined to throw an exception if the id given is invalid or if the id has already timed out. This is problematic, since if the exception is not caught the script will stop at that point. Imagine a case like this: h = svg.suspendRedraw(timedelta); ...timedelta+epsilon passes and the redrawing is resumed... svg.unsuspendRedraw(h); |
|||||||||
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: The calculations using the pixel values from in2 are performed using non-premultiplied color values. If the image from in2 consists of premultiplied color values, those values are automatically converted into non-premultiplied color values before performing this operation. with: The input image in is to remain premultiplied for this filter primitative. The calculations using the pixel values from in2 are performed using non-premultiplied color values. If the image from in2 consists of premultiplied color values, those values are automatically converted into non-premultiplied color values before performing this operation. |
Clarify getSVGDocument behavior | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Status | Proposed | |||||||||
Category | Substantive | |||||||||
Reported by | Anne van Kesteren | |||||||||
In reference to | ||||||||||
Comments | [1], [2] | |||||||||
Description |
getSVGDocument is an alias for contentDocument. (Edit 20 May 2009)
The Working Group revisited this erratum and changed it so that the
return type of |
|||||||||
Resolution | We will make getSVGDocument() effectively a synonym for EmbeddingElement::contentDocument . |
|||||||||
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/struct.html#InterfaceGetSVGDocument, replace: In the case where an SVG document is embedded by reference, such as when an XHTML document has an 'object' element whose href (or equivalent) attribute references an SVG document (i.e., a document whose MIME type is "image/svg+xml" and whose root element is thus an 'svg' element), the SVG user agent is required to implement the GetSVGDocument interface for the element which references the SVG document (e.g., the HTML 'object' or comparable referencing elements).
with: This interface provides access to an SVG document embedded by reference in another DOM-based language. The expectation is that the interface is implemented on DOM objects that allow such SVG document references, such as the DOM Element object that corresponds to an HTML 'object' element. Such DOM objects are often also required to implement the EmbeddingElement defined in the Window specification [WINDOW]. This interface is deprecated and may be dropped from future versions
of the SVG specification. Authors are suggested to use the
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 |
The 'contentStyleType' attribute provides the default value for style information in the current document fragment, however the spec only explicitly mentions the 'style' attribute when describing 'contentStyleType', not 'style' elements. Additionally the 'type' attribute on 'style' elements is marked as required, but it should get its default from 'contentStyleType' and fallback to "text/css" similar to how 'contentScriptType' works. |
||
Resolution |
We will clarify that 'contentStyleType'
applies to 'style' elements and
make the 'type' attribute on 'style'
get its default value from 'contentStyleType'.
|
||
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/styling.html#StyleElement, replace:
Attribute definitions:
with:
Attribute definitions:
In http://www.w3.org/TR/2003/REC-SVG11-20030114/styling.html#StyleElement, replace:
The contentStyleType attribute on the 'svg' element specifies the default style sheet language for the given document fragment.
with:
The contentStyleType attribute on the 'svg' element specifies the default style sheet language for the given document fragment.
|
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 'order' on 'feConvolveMatrix' says that it has a default value of "3", but the DTD says that the attribute is still required. |
Resolution | We will make the attribute not required. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feConvolveMatrixElementOrderAttribute, replace:
<!ENTITY % SVG.feConvolveMatrix.extra.content "" > <!ENTITY % SVG.feConvolveMatrix.element "INCLUDE" > <![%SVG.feConvolveMatrix.element;[ <!ENTITY % SVG.feConvolveMatrix.content "( %SVG.animate.qname; | %SVG.set.qname; %SVG.feConvolveMatrix.extra.content; )*" > <!ELEMENT %SVG.feConvolveMatrix.qname; %SVG.feCo\ nvolveMatrix.content; > <!-- end of SVG.feConvolveMatrix.element -->]]> <!ENTITY % SVG.feConvolveMatrix.attlist "INCLUDE" > <![%SVG.feConvolveMatrix.attlist;[ <!ATTLIST %SVG.feConvolveMatrix.qname; %SVG.Core.attrib; %SVG.FilterColor.attrib; %SVG.FilterPrimitiveWithIn.attrib; order %NumberOptionalNumber.datatype; #REQUIRED kernelMatrix CDATA #REQUIRED divisor %Number.datatype; #IMPLIED bias %Number.datatype; #IMPLIED targetX %Integer.datatype; #IMPLIED targetY %Integer.datatype; #IMPLIED edgeMode ( duplicate | wrap | none ) 'duplicate' kernelUnitLength %NumberOptionalNumber.datatype; #IMPLIED preserveAlpha %Boolean.datatype; #IMPLIED > with:
<!ENTITY % SVG.feConvolveMatrix.extra.content "" > <!ENTITY % SVG.feConvolveMatrix.element "INCLUDE" > <![%SVG.feConvolveMatrix.element;[ <!ENTITY % SVG.feConvolveMatrix.content "( %SVG.animate.qname; | %SVG.set.qname; %SVG.feConvolveMatrix.extra.content; )*" > <!ELEMENT %SVG.feConvolveMatrix.qname; %SVG.feCo\ nvolveMatrix.content; > <!-- end of SVG.feConvolveMatrix.element -->]]> <!ENTITY % SVG.feConvolveMatrix.attlist "INCLUDE" > <![%SVG.feConvolveMatrix.attlist;[ <!ATTLIST %SVG.feConvolveMatrix.qname; %SVG.Core.attrib; %SVG.FilterColor.attrib; %SVG.FilterPrimitiveWithIn.attrib; order %NumberOptionalNumber.datatype; #IMPLIED kernelMatrix CDATA #REQUIRED divisor %Number.datatype; #IMPLIED bias %Number.datatype; #IMPLIED targetX %Integer.datatype; #IMPLIED targetY %Integer.datatype; #IMPLIED edgeMode ( duplicate | wrap | none ) 'duplicate' kernelUnitLength %NumberOptionalNumber.datatype; #IMPLIED preserveAlpha %Boolean.datatype; #IMPLIED > |
Typo in the definition of the 'u2' attribute | |
---|---|
Status | Proposed |
Category | Substantive |
Reported by | Cameron McCormack |
Description | The 'u2' attribute says <number> instead of <character> in its definition, which makes it different from the corresponding attribute 'u1'. |
Resolution | We will align 'u2' with 'u1', so that they have the same attribute value definition. |
Change |
In http://www.w3.org/TR/2003/REC-SVG11-20030114/fonts.html#HKernElementU2Attribute, replace:
Animatable: no. with:
Animatable: no. |
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 |
The following attributes are missing from the attribute index appendix: additive, attributeName, begin, id, requiredFeatures, string. The following entries shouldn't be in the attribute index, since they're actually element names: animate, feColorMatrix, feComposite, feGaussianBlur, feMorphology, feTile. The following entries have incorrect "value", "type" or "default" column: baseProfile, contentStyleType, dominant-baseline, font-family, font-size, font-stretch, font-style, font-variant, font-weight, mode, pointer-events, rendering-intent, type. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 'xlink:href' on a 'script' element is animatable. |
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 |
The description of the |
|||||||||
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: float getStartTime ( ); with: float getStartTime ( ) raises( DOMException ); In http://www.w3.org/TR/2003/REC-SVG11-20030114/idl.html, replace: float getStartTime ( ); with: float getStartTime ( ) raises( DOMException ); 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:
SVG supports the standard XML attribute xml:space to specify the handling of white space characters within a given 'text' element's character data. The SVG user agent has special processing rules associated with this attribute as described below. These are behaviors that occur subsequent to XML parsing [XML10] and any construction of a Document Object Model [DOM2]. with:
SVG supports the standard XML attribute xml:space to specify the handling of white space characters within a given 'text' element's character data. Note that any child element of a 'text' element may also have an xml:space attribute which will apply to that child element's text content. The SVG user agent has special processing rules associated with this attribute as described below. These are behaviors that occur subsequent to XML parsing [XML10] and any construction of a Document Object Model [DOM2]. |
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 [ISO8601].
with:
Describes the element begin as a real-world clock
time. The wallclock time syntax is based upon syntax
defined in [ISO8601].
|
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: The DTD defines an extension entity for most of SVG elements. For example, the 'view' element is defined in the DTD as follows: <!ENTITY % viewExt "" > <!ELEMENT view (%descTitleMetadata;%viewExt;) > <!ATTLIST view %stdAttrs; externalResourcesRequired %Boolean; #IMPLIED viewBox %ViewBoxSpec; #IMPLIED preserveAspectRatio %PreserveAspectRatioSpec; 'xMidYMid meet' zoomAndPan (disable | magnify) 'magnify' viewTarget CDATA #IMPLIED > The entity <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [ <!ENTITY % viewExt "| customNS:customElement" > <!ATTLIST view xmlns:customNS CDATA #FIXED "http://www.example.org/customNS" customNS:customAttr CDATA #IMPLIED > <!ELEMENT customNS:customElement EMPTY> <!ATTLIST customNS:customElement xmlns:customNS CDATA #FIXED "http://www.example.org/customNS" info CDATA #IMPLIED> ]> <svg width="8cm" height="4cm" version="1.1" xmlns="http://www.w3.org/2000/svg"> <desc>Extend the 'view' element via the internal DTD subset</desc> <!-- Presumably, some great graphics would go here. --> <view viewBox="100 110 20 30" customNS:customAttr="123"> <customNS:customElement info="abc"/> </view> </svg> with: The DTD defines an extension entity for most of SVG elements. For example, the 'view' element is defined in the DTD as follows: <!ENTITY % SVG.view.extra.content "" > <!ENTITY % SVG.view.element "INCLUDE" > <![%SVG.view.element;[ <!ENTITY % SVG.view.content "( %SVG.Description.class; %SVG.view.extra.content; )*" > <!ELEMENT %SVG.view.qname; %SVG.view.content; > <!-- end of SVG.view.element -->]]> <!ENTITY % SVG.view.attlist "INCLUDE" > <![%SVG.view.attlist;[ <!ATTLIST %SVG.view.qname; %SVG.Core.attrib; %SVG.External.attrib; viewBox %ViewBoxSpec.datatype; #IMPLIED preserveAspectRatio %PreserveAspectRatioSpec.datatype; 'xMidYMid meet' zoomAndPan ( disable | magnify ) 'magnify' viewTarget CDATA #IMPLIED > The entity <?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [ <!ENTITY % SVG.view.extra.content "| customNS:customElement" > <!ATTLIST view xmlns:customNS CDATA #FIXED "http://www.example.org/customNS" customNS:customAttr CDATA #IMPLIED > <!ELEMENT customNS:customElement EMPTY> <!ATTLIST customNS:customElement xmlns:customNS CDATA #FIXED "http://www.example.org/customNS" info CDATA #IMPLIED> ]> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="8cm" height="4cm"> <desc>Extend the 'view' element via the internal DTD subset</desc> <!-- Presumably, some great graphics would go here. --> <view viewBox="100 110 20 30" customNS:customAttr="123"> <customNS:customElement info="abc"/> </view> </svg> |
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:
|
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 |
When assigning to SVGLength::valueAsString (or SVGAngle::valueAsString), the unitType should be changed to whatever was parsed from the given string. For example: var l = /* an SVGLength object */; l.valueAsString = '1em'; assert(l.unitType == SVGLength.SVG_LENGTHTYPE_EMS); assert(l.valueInSpecifiedUnits == 1); but the current description of valueAsString isn't clear about this. There's no indication of exception would be thrown if the given SVGLength string couldn't be parsed, or what exactly is the acceptable syntax. Exceptions also need to be added for newValueSpecifiedUnits and convertToSpecifiedUnits, in case an invalid unit type is passed. |
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:
SVG's user agent style sheet sets the 'overflow' property for 'pattern' elements to hidden, which causes a rectangular clipping path to be created at the bounds of the pattern tile. Unless the 'overflow' property is overridden, any graphics within the pattern which goes outside of the pattern rectangle will be clipped. with:
SVG's user agent style sheet sets the 'overflow' property for 'pattern' elements to hidden, which causes a rectangular clipping path to be created at the bounds of the pattern tile. Unless the 'overflow' property is overridden, any graphics within the pattern which goes outside of the pattern rectangle will be clipped. Note that if the 'overflow' property is set to visible the rendering behavior for the pattern is undefined. |
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:
|