Opera Problems or Bugs with SVG and (X)HTML

Date of last update: 2008-06-22

SVG, test-suites and Opera
Operas fixed bugs history of SVG (if you miss an identifier on this page, it is maybe moved to this page)

SVG bug list for Opera:

title and desc title displayed since build 272 in simple situations (already very useful)
activation of animation with id.activate
activation of animation with accessKey partly fixed in build 344 (already very useful)
attribute font-style
attribute font-weight
wallclock value for begin and end
to animation
path rendering
rendering of stroke-dasharray
stroke-dasharray rendering of basic shapes
painting a path of length zero
repeatEvent, beginEvent, endEvent
animateColor and calcMode paced almost fixed in build 272
(build 181 and later) closed subpaths and stroke-dasharray
foreignObject element partly fixed in 9.50 alpha (build 1629)
dx and dy attributes for text and tspan partly fixed in 9.50 alpha (build 1567)
animateTransform or animateMotion with to
referencing transformed views
text x and y not additive
stroke-dasharray and masked path
writing-mode, glyph-orientation-*, direction
linear and spline animateMotion
animateMotion and pathLength
stroked circle, ellipse or rectangle
accuracy and circle
large path and animation interpolation partly fixed in 9.50 alpha (build 1567)
foreignObject crash
beginEvent crash
path normalisation
vector-effect non-scaling-stroke
view
path interpretation and timing
accuracy of keySplines interpolation
by animateMotion
rendering error
script and requiredFeatures (or requiredFormats)
attributeType and priorities
editable default
viewport-fill (-opacity) and animation element
discard to crash
conditional processing and animation
animateMotion and zero path length
animateMotion and keyTimes
xlink:role and xlink:arcrole
event bubbling
corrections for rx and ry due to animated width and height of rect
animation of the font property
textLength
tref and external text reference
overflow inherit

Opera problems with (X)HTML:

~~link-element~~ fixed in 9.50 alpha (build 1567)
datetime and cite attributes of del and ins elements
cite attributes of q and blockquote elements

Author

SVG, test-suites and Opera

Up to now, unfortunately the test-suites of W3C for SVG are not very detailed. A lot of SVG-features can not be tested with them, but nevertheless, they are part of the specification. So we need to help developers with simple examples, what is not working yet, but should, according to the specification. I tried to reduce errors to minimal and essential examples, maybe helpful to test other user-agents too.

(Ich bin) Ein Teil von jener Kraft,
Die stets das Böse will und stets das Gute schafft. ...
Ich bin der Geist, der stets verneint!
Mephistopheles, Johann Wolfgang Goethe (Faust I, Studierzimmer, 1335ff)

Opera 8.x was published with the ability to support the tiny profile of SVG 1.1 and Opera claims, that Opera9 supports the profile basic of SVG 1.1 since the version beta 1 (published 2006-04-11, build 236). Of course, this is not completely true, there are several errors and gaps for both profiles. And even in Opera 9 there are errors and gaps in the support of the tiny profile. There is still a lot of work and many errors and gaps to find and to be fixed - lets get them!
Opera published lists of supported parts of SVG for Opera9 (This is build 344 from 2006-06-16, just for comparsion). These lists contain some further gaps, not mentioned here. Some points in these lists are not consistent with errors and gaps noted here, mainly because these lists are less detailed as a systematic test of these features. Maybe we can take it as lists, Opera believes, these features should work (or it is already known, that they do not work yet). Deviations between real behaviour and these lists seem to be worth to report to Opera, either to correct the lists or the behaviour.

For animation I offer a special test area with a systematic test ensemble for animation of SVG. Tests will be continued until I give up or it will work ;o)

For users and authors: Do not blame anybody, if you have not even read the specifications.
And you have to read the specification carefully and you have to distinguish between different profiles and versions. Note, that SVG tiny or SVG basic cover just a large part of SVG, but not everything, so it is not an error, if features of SVG are not supported, that are not included in SVG tiny or SVG basic. You have to read SVG mobile specification to optimize your files. Normally, SVG mobile just refers to the SVG specification. You have to look carefully at the restrictions.
Opera 8 is already able to support a few parts of SVG basic like opacity and parts of gradients, the Opera 9 Technology Preview 1/2 support already more parts of of SVG basic like tspan, parts of text on a path, filters, for them the author has to try examples, what already works and what is incomplete and contains errors. Opera 9 beta 1 is expected to support the basic profile completely. For Opera 9.50 (alpha etc) is noted, that it supports parts of SVG tiny 1.2 too.
Often it is easy to reduce SVG documents to SVG tiny. For example instead of CSS you have to use almost the same presentation attributes of SVG and you can collect elements with the same values of attributes in groups to define something like CSS classes. Instead of animation with (ecma-) scripts declarative animation can be used, not just with SVG tiny, but with deactivated scripting and full SVG support, too. So in many cases the accessibility with more user agents gets better with a reduction to SVG tiny.

All examples were tested on Debian-Linux (stable) with the static versions, most of them tar.gz

2008-06-20:01 overflow inherit

Example:
overflow and symbol
overflow of a symbol is set to inherit. Therefore the overflow property is inherited from the referencing use element, scroll/hidden on the left, auto/visible on the right. The area for the symbol defined by a use element is indicated with thin black stroked rectangles, if clipped, fragments of the symbol are only inside this rectangle.
Opera uses always visible instead of inherit.

Comment: Ok in Squiggle 1.7, KSVG and the adobe plugin use always hidden instead of inherit. The Geckos and Inkscape always use visible instead of inherit. bug-341985

2008-06-19:03 tref and external text reference

Example:
text from another document with tref
'Text 1?' from file tref01a.svg is used and ':' before and after tref is inside the local text element. If something red gets visible, an error is occured.
Opera does not display the final ':'. bug-341979

2008-06-19:02 textLength

Description: wrong/incomplete interpretation of textLength for tspan-text combination.

Example:
textLength in tspan and text
The tspan attribute textLength changes from 400 to 600 in 5s with textLength explicitely set to 1000 for the text element. The light grey and grey rectangles show the corresponding scaling and the grey stroked text the approximate glyph positions using an animation of the x attribute of text. Even if the guess for the glyph positions is not very good, obviously all glyphs should be at least inside the largest rectangle, representing the textLength of the complete text. bug-341975

2008-06-19:01 animation of the font property

2008-06-18:01 corrections for rx and ry due to animated width and height of rect

Severity: specification violation SVG tiny 1.1 (Regression compared to Opera 9beta1 and earlier versions)

Description: the wrong order to add missing rx or ry of a rect element or to correct them is used.

Example:
animated rects with rounded corners
For two blue rectangles the attributes width and height are animated and either rx or ry given explicitly. The animation is compared for the top left corner of each rectangle with an animated ellipse with the same rx and ry. If the top left quarters of the stroked ellipses do not fit exactly to the top left rounded corner of the related rectangle, an error is occured. Because the correction rules to imply the other r is before that of the rule for the corrections for width or height, the width/height correction is applied to the implied value and not the width/height corrected r is implied. Here the implied r remains constant, the other is corrected.

Comment: This sample is ok in the adobe plugin, in Batik/Squiggle 1.7, KSVG and Amaya (only the ellipse is not animated in Amaya). For example Squiggle has some other problems with those correction rules, not appearing in this example. bug-341954

2008-06-17:01 event bubbling for repeatEvent, endEvent, (maybe beginEvent too)

Description: repeatEvent, endEvent, (maybe beginEvent too) bubble in Opera (≥ 9.50). According to the SMIL animation recommendation, SMIL2 and SMIL3 repeatEvent, endEvent, beginEvent do not bubble, most other events do due to the DOM event specifications. However repeatEvent, endEvent, beginEvent are specific for animation and are not covered by DOM events. For the specific requirements of timed elements in SMIL and animation in SMIL it is useful not to bubble those events, which is the case for SVG too.

Example 1:
event bubbling and repeatEvent
For the event repeatEvent bubbling is not applicable. The repeatEvent of the stroke animation of the circle starts the animation for cx directly. If bubbling would be applicable, cy would start too, but without bubbling the cy animation does not start at all. The cx animations itself is repeated once, but because it depends on the repeated stroke animations the behaviour is slightly more complex. The circle moves always along the grey line. If the red fill of the circle gets visible, an error is occured.

Example 2:
event bubbling and endEvent
For the event endEvent bubbling is not applicable. The endEvent of the stroke animation of the circle starts the animation for cx directly. If bubbling would be applicable, cy would start too, but without bubbling the cy animation does not start at all. The cx animations is repeated once. The circle moves always along the grey line. If the red fill of the circle gets visible, an error is occured.

Example 3 (caution - this sample currently crashes Opera 9.50 due to bug-286635):
event bubbling and beginEvent
For the event beginEvent bubbling is not applicable. The beginEvent of the stroke animation of the circle starts the animation for cx directly. If bubbling would be applicable, cy would start too, but without bubbling the cy animation does not start at all. The cx animations is repeated once. The circle moves always along the grey line. If the red fill of the circle gets visible, an error is occured.

Comment: Because either these events are not interpreted in previous Opera versions and bubbling did not work for previous versions, this problem appears only since 9.50 alpha...
The adobe plugin ignores such events, Batik/Squiggle 1.7 does it right for these samples.
bug-341948.

2008-03-05:01 xlink:role and xlink:arcrole

Description: xlink:role and xlink:arcrole references not accessible
xlink:role and xlink:arcrole for elements like a, image, use etc provide a possibility to give a description of the referenced document respectively the referencing arc in an external document. Obviously this becomes only useable both for authors and users, if the noted URIs are accessible somehow. This could be done for example on demand in the content menu similar to zooming or pausing of animation. In an alternative text representation of the document this should be noted too.
SVG and XLink do not note details, how this has to be realise, but SVG references XLink as normative description for them and it is obvious, that they have a well defined functionality related to accessibility similar to the SVG elements title and desc and should be accessble too somehow.

Example:
image, xlink:role and xlink:arcrole
Note, that the URIs of xlink:role, xlink:arcrole, xlink:href are not even available in the info panel of Opera.

Comment: Other viewers have a similar accessibility problem for these elements. bug-316543.

2008-03-04:01 animateMotion and keyTimes

Example 1:
animateMotion and keyTimes
Some circles are moved along a square with a duration of 30s. All have the same timing, therefore the top blue circles cover the other red ones. The blue ones use a simple path referenced by mpath or the same path using the path attribute or values, all with keyTimes and calcMode linear. The red circles below use values and either keyTimes with animateTransform or a group separated animateMotion resulting in the same timing for comparison. If something red circles gets visible, an error is occured.

Example 2:
animateMotion and keyTimes
Some circles are moved along a path with a duration of 30s. All have the same timing, therefore the top blue circles cover the other red ones. The blue ones use a simple path referenced by mpath or the same path using the path attribute, all with keyTimes and calcMode linear. The red circles below use path and a group separated animateMotion resulting in the same timing for comparison. If something red circles gets visible, an error is occured.

Comment: Ok in the adobe plugin and wrong in Squiggle 1.7 (only problems with multiple M/m commands here) and Opera.

Example 3:
animateMotion and keyTimes
Some circles jump a few times along a path with a duration of 30s. All have the same timing, therefore the top blue circles cover the other red ones. The blue ones use a simple path referenced by mpath or the same path using the path attribute or a simple path given with values, all with keyTimes and calcMode discrete. The red circles below use path and a group separated animateMotion resulting in the same timing for comparison. If something red circles gets visible, an error is occured.
Note, that control points and M/m commands except the initial from the path do not contribute as jump points, therefore there are exactly 5 jump points for each path.

2007-12-16:01 animateMotion and zero path length

Example:
linear animateMotion and zero path length
A path with several path fragments of zero length is used for a linear animateMotion of a blue square. The path is given in gray, some simpler animateMotion elements are used to perform the same motion for a red square exactly below the blue one. If something red gets visible, an error is occured.

Comment: There are more problems the calcMode discrete or paced. This example is correct in the adobe plugin (but has other problems than Opera for the other values of calcMode). bug-285856 (not send by me).

2007-12-10:01 conditional processing and animation

Example:
switch and animation
A switch is used with systemLanguage on a set element. The set switches the color of a gray square to blue at 2s, not to red as the alternative set would do, if the systemLanguage is not supported. Red indicates an error.
The systemLanguage is derived from the related parameter HTTP_ACCEPT_LANGUAGE from the viewer. An additional string of a supported systemLanguage can be given manually with the GET parameter 'lang'.

2007-11-10:01 discard to crash

Severity: crashes Opera 9.50 (including alpha/beta) (and error in the interpretation of discard).

Description: Opera 9.50 (including alpha/beta) crashes with the given interactive discard example

Example:
interactive discard example
After several (two or more) clicks on different dark blue circles in the bottom line Opera 9.50 alpha crashes. Note, that there is an error with the discard of the right circles too, they are not always removed.

Description of the test sample:
Using the an event to discard the circle respectively the g element around the circle and using the begin of the discard as a syncbase-value to set the display of the small circle to none at the same time. Test is ok if the circles above are discarded and not displayed, if the bottom circles are clicked or activated, the left and the right ones directly, the middle ones 2s retarded. bug-303309.

2007-11-04:01 viewport-fill (-opacity) and animation element

Description: Opera 9.50 (including alpha/beta) does not fill the viewport of an animation element completely with viewport-fill (-opacity)

Example:
viewport-fill and animation element
The viewport-fill for an animation is animated in the blue range within 20s. If the viewport is not completely and always somehow blue an error is occured. If it is red, the animation is not applied.
On bottom right there is a small rectangle having the same fill animation as the viewport for comparison.
Opera only fills behind the referenced document, not the viewport parts on the left and right of the referenced document. They appear due to the combination of widths and heights and preserveAspectRatio.

Example:
viewport-fill-opacity and animation element
The viewport-fill-opacity for an animation is animated in the blue range within 20s.
On bottom right there is a small rectangle having the same fill animation as the viewport for comparison.
Opera does not animate the opacity left and right from the referenced document.

2007-10-31:02 editable default

Description: Opera 9.50 (including beta) does not switch back to the underlying value of editable if its animation is ended.

Example:
editable sample
After a click on the small blue circle the textArea with a silly poem can be edited for 10s, indicated by a blue stroke of the rectangle. With the small magenta circle editing can be stopped alternatively.
In Opera 9.50 beta editable does not switch back to none automatically after 10s. bug-295471

2007-10-31:01 attributeType and priorities

Severity: specification violation SVG tiny 1.1. Regression compared with Opera 8 and 9 < 9.50.

Description: animation corrupted if attributeType XML is overwritten with a higher priority attribute auto animation

Example:
attributeType and priorities
If an attributeType XML is overwritten with a higher priority attribute auto animations beginning at 2s, Opera9.50 (including alpha/beta) ignores the higher priority animations. In this fill animations the fill is switched to black instead of performing the higher priority animation in the blue range.

Comment: Ok in the adobe plugin and in previous versions of Opera 8 and 9. bug-295469

2007-10-23:01 script and requiredFeatures (or requiredFormats)

Severity: specification violation SVG 1.1 (respectively tiny 1.2 for requiredFormats).

Description: Opera claims to support scripting, even if scripting is switched off by the user

Example:
testing script and requiredFeatures
The display of this document depends on a switch of the feature string for script and on ecma-script.
First case: feature string returns true for script and scripting is active - the user gets a request to switch off scripting to continue with the test (with a reload).
Second case: feature string returns true for script and scripting is not active - the user gets an information about an error. The document contains only ecma-script. If the viewer is not able to interprete this, it should have returned fail for the feature string for this document.
Third case: feature string returns fail for script and scripting is active anyway - the user will see an animation and an information about an error - scripting should be not available, if the feature string returns fail in general.
Fouth case: feature string returns fail for script and scripting is not active - the user will see a comment to switch on scripting to continue with the test (with a reload).
Note that the featureString gives an information, wether the feature is supported for this document or not, not if it is in general possible that the feature can be supported under some specific condiditions, in this case only if scripting is enabled. If feature strings have any benefit for authors, the return value of the feature string has to depend on the specific current conditions for the related document and user preferences, not on a general philosophical statement of the viewer.
The scripting used in this document is similar to set animations of the display property to none, respectively to block to display the additional information to the user related to scripting.
similar tiny1.2 test including requiredFormats

Opera claims always to support scripting, even if it is switched off by the user. This is an accessibility problem. With this behaviour it is very difficult for authors to switch between content without scripting and alternative content using scripting for whatever purpose. Note, that using requiredFormats in SVG tiny 1.2 instead of requiredFeatures would be even more effective, but does not work with Opera either.

2007-10-14:01 rendering error

Description: rendering error: residual mysterious line in Opera 9.50 (including alpha/beta)

Example:
path with rendering error
On top there is a small horizontal line, this is the rendering error. Because stroke-width is the smallest structure, there cannot be a smaller structure as the stroke in the image. The horizontal line is clearly smaller as the stroke-width. The error depends strongly on the height of the svg, the viewBox and the choosen path, the presence of the z command, the stroke-linejoin.

2007-09-29:01 by animateMotion

Example:
by animateMotion
Test whether a by animateMotion is additive or not. Red indicates an error.

2007-09-27:01 accuracy of keySplines interpolation

Example:
animate with calcMode keySplines
The cy of a blue stroked circle is animated with six different values animations using calcMode spline and keySplines. The cx is animated linear with values animations to get two dimensional trajectories.
The resulting trajectories are displayed within the active duration as gray paths. These paths cover always completely the red fill of the circle.
If the red center of the circle gets visible, an error is occured.
The timing of the cx animations is choosen in such a way, that the keySplines correspond directly to a cubic path as trajectory. The keySplines values have to be multiplied only with the related values, to get the path data.
The required accuracy of positioning has to be within one device pixel.
Opera does not meet this required accuracy indicated in situations with large acceleration when the red center of the circle gets visible.

2007-09-26:01 path interpretation and timing

Severity: specification violation SVG tiny 1.1 for Opera9.50 (including alpha/beta); regression compared with Opera 9.0x, 9.1x, 9.2x.

Examples:
quadratic path interpretation and timing
cubic path interpretation and timing
Testing accuracy of path interpretation using stroke-dasharray, stroke-dashoffset and animateMotion.
A symmetrical quadratic path stroked in dark blue is used for the test. Magenta is the painted curve fraction of 0.5 of the complete path. The end point of the painted fraction is painted yellow - this is the test point at the half path.
Centered black concentrical circles test the accuracy of animateMotion stopped with different methods at the test point at the half path (after 1s of animation). A dark blue scale with yellow markers is aligned in such a way, that the yellow markers are between the different circles, respectively mark the positions of the stroke-dasharray fractional path.
Click the dark blue path to see the complete path, click the magenta path to see details around the test point.
The required accuracy of positioning has to be within one device pixel.
Opera 9.50 alpha does not meet this required accuracy anymore. Previous versions did.

2007-09-23:01 view

Severity: specification violation SVG 1.1 for Opera9.50 (inlcuding alpha/beta); regression compared with Opera 9.0x, 9.1x, 9.2x

Example:
element with static and animated view targets
Four views are given as targets of an animated xlink:href attribute of an a element. Colors are changed and the outline of the view displayed just to give a timing. Another static view is given with the dark blue small centered circle. Click on the circles to see the target view.

2007-09-22:02 vector-effect non-scaling-stroke

Description: stroke with vector-effect non-scaling-stroke disappears if scaled to zero

Example:
scale a rectangle to a height of zero without changing the stroke-width
The size of a blue path is scaled down in 5s with several values for x and y to zero. The vector-effect is non-scaling-stroke. This means the stroke does not change with scaling. The vector-effect is set to none at 20s. If something red gets visible, an error occured.
Opera9.50 alpha interpretes the vector-effect, but if something is scaled to zero, the stroke is not displayed anymore. Note that in the specification it is only noted for the type matrix, if it is completely zero, that the display is disabled, not for other types or if the resulting matrix is equal or not equal to zero...

Application example:
harmonic oscillator
Application: using vector-effect non-scaling-stroke and animateTransform rotate to realise a one dimensional harmonic oscillation. A blue circle represents the harmonic oscillator, the trajectory is displayed as a gray path.

2007-09-22:01 path normalisation

Severity: specification violation SVG tiny 1.2; regression compared with Opera 9.0x, 9.1x, 9.2x

2007-09-10:02 beginEvent crash

2007-09-10:01 foreignObject crash

fixed in 9.50 alpha (build 1589)
crashes again in 9.50 (including beta, build 1834 for example)
Severity: crashes some versions of Opera 9.50.

Description: A SVG document containing foreignObject crashes Opera 9.50 (some builds).

Example:
animated foreignObject
(show source code)
The crash happens sometimes immediately or after a few seconds or if the tab containing the document is closed.

2007-06-15:01 large path and animation interpolation

partly fixed in 9.50 alpha (build 1567)
Severity: annoying only (but NO specification violation).

Description: If a large path is stroked in a document, the animation interpolation quality is very poor to unusable

Example 1:
large path and animateTransform with only a few values
animateTransform and a long fractal path. The path is related to the Lorenz attractor.
The buttons bottom right do the following after clicking:
red: set the stroke of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation

Example 2:
large path and animateMotion
animateMotion along a long fractal path. The path is related to the Lorenz attractor.
The buttons bottom right do the following after clicking:
red: set the stroke of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation

Example 3:
large path and animateTransform with a long values list
animateTransform along a long fractal trajectory. The trajectory is related to the Lorenz attractor.
The buttons bottom right do the following after clicking:
red: set the stroke of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation

Example 4:
large path stroked
animateMotion along a long fractal path. The path is related to the Lorenz attractor. The path itself is stroked/painted using a stroke-dasharray animation.
The buttons bottom right do the following after clicking:
red: set the stroke and the stroke-dasharray of the path to none for 20s
green: set the stroke to #aaf again
yellow: restart the animation
This one is still a problem for Opera9.50 - very rough interpolation.

Application:
Lorenz Attractor, random start and view
Animation of the Lorenz-Attractor.
The buttons bottom right (or the related GET parameters) can be used to influence, wether the animation continues manually or automatically or if it restarts.
In case of need the GET parameters can be used to define the start position and other parameters. s is a parameter for scaling, dur the duration in seconds (optional anz the number of animation points, per default 20*dur).
Differential equation:
dx/dt = k(y-x)
dy/dt = l x - y - x z
dz/dt = x y - m z
The problem is rotated with an angle o (in degree) around the direction (x, y, z).

The animation quality is in all examples very poor, if the path is stroked. If the stroke is set to none with the red button, the quality is ok again. This indicates, that the problem is more related to the path itself and not to a specific animation. In comparison: the adobe plugin manages the situation without any problems except the missing stroke-dasharray animation in the example 4 and the application of course. This is clearly improved in Opera 9.50 alpha.

2007-05-05:01 accuracy and circle

Examples:
simple blue circle between two thin black circles
Well, lets go back to the basics - lets stroke a simple circle. It uses number values from the number range of SVG 1.1 tiny or from the even more restrictive SVG 1.2 tiny. What do we get in Opera? - A squared surprise!
But we can do it better: simple blue circle between two thin black circles
Accuracy of rendering is tested using a circle. For the tiny profile a number range from -32767.9999 to +32767.9999 has to be supported and the rendering accuracy has to be within one device pixel. The blue circle has to cover the red circle always completely. The blue circle is completely inside the large black circle and outside the small black circle.

Comment: First example works in Geckos 1.8 (SeaMonkey), second has an irregular doughnut as result. Konqueror+KSVG1 or Inkscape: First example ok, second a little bit shifted but wellformed circle. Adobe plugin: First ok too, with the second it gets interesting, it is not just irregular, it is cut! Gimp2.2: both examples ok. bug-263655

2007-04-09:01 stroked circle, ellipse or rectangle

Description: stroked circle, ellipse or rectangle with rounded corners displayed wrong, if the size gets smaller than the stroke-width.

Comment: Problems with this in many viewers. Except for the animation subtest the best results I have seen are from Mozilla with the current Geckos 1.8 (SeaMonkey, Firefox), wrong in the adobe plugin and KSVG1 too, stroke is always a surprise in Amaya 9, in general we get some very creative interpretations from different viewers.
bug-259672

2007-02-04:01 animateMotion and pathLength

Severity: specification violation SVG 1.1 tiny. Regression compared to Opera 8.x

Description: animateMotion confused by explicitely given pathLength. Regression compared to Opera 8.x.

Example:
animateMotion confused with pathLength: Rectangles are moved along the same paths with animateMotion with repetition. For each path the pathLength is explicitely given. The correct pathLength of 2400 is used for the blue rectangle, for the red rectangles the given guess for the pathLength is 10% bigger or smaller or animated between these guesses. The motion has to be paced without any jumps or stops. And because there are no other restrictions the motion has to go along the complete path. A given pathLength attribute for the path used for animateMotion confuses Opera9. Either the velocity of the motion gets to fast or too slow. Some errors are reduced in Opera9.50 alpha, but some are still remaining.

Comment: It is pretty nice that Opera9 supports the attribute pathLength, but in this situation as given in the example, pathLength has no visible effect on animateMotion, because the intrinsic behaviour of animateMotion hides the effect of a corrected pathLength again. Ok in Opera8 and in the adobe plugin, but this is no surprise, because they ignore pathLength in general even if it should have a visible effect ;o)
bug-250326

2007-01-30:01 linear and spline animateMotion

Description: different wrong or confused timing for linear and spline animateMotion. Different hehaviour in different builds from Opera8 or Opera9, but always wrong.

Examples only for behaviour still wrong in Opera 9.10 and later:
Example 1:
linear animateMotion for paths with Z command: Comparing linear animateMotion with animateTransform for a rectangle. animateTransform is blue and covers completely the red animateMotion. Dark red uses the mpath element, light red the path attribute and red values The path consists of a triangle indicated in gray. The paths are using explicitely the command Z to close the path. In a linear animation the Z command consumes time too, even if the length of the subpath is zero. If something red gets visible, an error is occured.
Ok in Opera9.50 alpha.
Example 2:
linear animateMotion for paths with M command: Comparing linear animateMotion with animateTransform for a rectangle. animateTransform is blue and covers completely the red animateMotion. Dark red uses the mpath element, light red the path attribute and red values. The path consists of three simple lines as subpaths indicated in gray. Except the initial M command the other M commands do not count for the timing of the linear animation. If something red gets visible, an error is occured.
Example 3:
linear animateMotion with elliptical arcs, SVG 1.1 full only: Comparing linear animateMotion with animateTransform for a circle as a path for a rectangle. animateTransform is red and covered completely by the blue animateMotion. The path consists of three parts respectively two rotations of 90 degree and a final of 180 degree back to the initial position. The paths are indicated in gray. If something red gets visible, an error is occured.
Example 4:
spline animateMotion with elliptical arcs, SVG 1.1 full only: Comparing animateMotion with animateTransform for a circle as a path for a rectangle. animateTransform is red and covered completely by the blue animateMotion. The path consists of three parts respectively two rotations of 90 degree and a final of 180 degree back to the initial position. The paths are indicated in gray. If something red gets visible, an error is occured.
Example 5:
spline animateMotion for paths with Z command: Comparing spline animateMotion with animateTransform for a rectangle. animateTransform is blue and covers completely the red animateMotion. Dark red uses the mpath element, light red the path attribute and red values The path consists of a triangle indicated in gray. The paths are using explicitely the command Z to close the path. In a linear animation the Z command consumes time too, even if the length of the subpath is zero. If something red gets visible, an error is occured.
Ok in Opera9.50 alpha.

2006-07-31:01 writing-mode, glyph-orientation-*, direction

Description: writing-mode and glyph-orientation-* for several glyphs wrong or ignored, direction wrong.

Comment: compare with the behaviour of the adobe plugin. I think it is correct except the fact, that the adobe plugin ignores several generic font-families. bug-223007.

2006-07-07:01 stroke-dasharray and masked path

Severity: specification violation SVG 1.1 full or basic (regression compared to Opera9tp1 build 1428).

Description: Wrong display of dashes in a masked path. Worked already in Opera9tp1.

Example:
stroke-dasharray and masked path: Note, that stroke-linecap is butt for the stroked path. Even if linecaps are applied to the end of dashes, butt is not round. This seems to be somehow inherited from the mask, but there is no reason to do it, because the path in the mask has no stroke-dasharray and there is no reason for inheritance from or into a mask referenced with the mask attribute. The mask just rounds the caps of the complete path. Animation of stroke-dashoffset and of stroke-dasharray with a click on the blue buttons is just added to see the general behaviour for different values of dashing.

2006-06-22:01 text x and y not additive

Description: text x and y animations are not additive. Different errors in different versions of Opera9 - either the lower priority animations are ignored or the higher priority animations are ignored as in Opera9.00.

Example:
additive animations of x and y of text: Two from to animations are added with additive sum for x and y of text. The visible result is that the blue 'text' covers exactly the red 'text' without any visible animation effect. If something red is getting visible, an error occured.
Note that x and y for each glyph are of the type coordinate. And this type supports additive animation.

Comment: works with the adobe plugin and with Opera8 (not under all conditions, but for this example). bug-216720.

2006-05-25:01 referencing a transformed view

Severity: specification violation SVG 1.1 basic or full (regression compared to Opera 9tp2).

Description: Opera9 later builds as tp2 ignore transformed views as a target of an a element. Regression compared to Opera 9tp2. Wrong behaviour and strange residuals in Opera9.50 alpha.

Example:
referencing a transformed view: Four transformed views are given directly with SVG specific fragment identifiers as targets of an animated xlink:href attribute of an a element. Colours are changed just to give a timing. Click on the circle to see the target view. bug-211239

2006-05-15:01 animateTransform or animateMotion with to

Description: Opera8 and Opera9tp1 do not animate animateTransform using to, wrong animation in Opera9tp2, different wrong animation in Opera9beta1 and later versions.

Example 1:
animateTransform using to: Two blue circles are moved to one position marked with a gray circle, using animateTransform with to for a translation to the absolute final value. Two red circles are animated as simple references just for comparison. If the red circles become visible, the animation of the blue circles is wrong. Note that to animations have a special additive behaviour, defined in detail into the SMIL recommendation, which overwrites die additive attribute. Opera does something different and uses the value of the additive attribute somehow.
Ok in Opera9.50 alpha.

Example 3:
animateTransform using to: A blue square and a test text are transfomed with a matrix. After 3s an animateTransform with a scale to -1,1 and a duration of 10s and calcMode linear is applied to the group. This means, after 3s the group morphes to a mirrored group continuously. matrix itself is not animatable, but it is the initial value for the animateTransform. If a red group becomes visible, an error occured.

The problem with this example is, that in the SVG specification it is not mentioned, that the type matrix is animatable, unfortunately this seems to be needed to get the correct result in general. Of course for this example it is simpler, because the initial transformation is just a scaling.
To get the to-animation correct, a special rule has to be used. If C(t) is the current transform matrix and T the to value of the animation represented as a matrix, t the time, d the duration, the Opera can use additive replace and the following transform matrix for a to-animation: C(t) + (T - C(t))* t/d.
In many cases it is possible to define this as a multiplicative matrix with additive sum too, but then the inverse matrix of C or T has to exist. Just for scaling the inverse of T exists not alway, this happens, if the scaling factor for x or y is zero. Therefore the formular above is much simpler.
If C(t)^-1 exists, the following formular can be used for an additive sum animation (I is the identity transformation): I* (1-t/d)+ C(t)^-1F*t/d
If F^-1 exists, F can be used as the initial value and the formular is: I * t/d + (1- t/d) F^-1C(t)

Comment: This example is wrong in the adobe plugin too, it trys a discrete animation with the correct final value and crashes a moment later.
Note, that this problem is not related with the SVG1.2 mobile working draft problem mentioned in 2006-05-14:01, because to-animations are clearly excluded in the concerning part of the working draft.
bug-212137.

Another unsolved problem without any changes since Opera9tp1 with to-animation is 2005-10-18:01 (bug-185982).

2006-04-25:01 dx and dy attributes for text and tspan

partly fixed in 9.50 alpha (build 1567)
Severity: specification violation SVG 1.1 basic or full.

Description: Opera9 beta1 and later builds has a wrong interpretation of the dx and dy attributes for text. If a list is used, the values are not incremental, the are used for each glyph relative to its initial position and not incremental or relative to the current text position. Linear animation is misinterpreted as discrete animation.

First Example:
animated dx and dy attributes for text: dx and dy attributes are set from 0 to 40 after 3s for the top text. dx and dy attributes are set from 0 to 40 60 80 100 after 3s for the bottom text. The gray 'text' displays the correct final position of the top text, the gray 't' displays the final position of the last t of the bottom 'text'.
Ok in Opera9.50 alpha.

Second Example:
animate dx and dy attributes for text: dx and dy attributes change continuously from 0 to 40 in 5s for the top text. dx and dy attributes change continuously 0 to 40 60 80 100 in 5s for the bottom text. This means, the first text moves a little bit right down. In the second text each glyph moves a little bit right down relative to its predecessor. The gray 'text' displays the correct final position of the top text, the gray 't' displays the final position of the last t of the bottom 'text'. Discrete animation in Opera9.50 alpha.

Comment: Opera9 interpretes this attributes since tp1 in this way, before it was ignored, but from Opera 9 beta1 a correct interpretation of these basic attributes can be expected. Correct display with the adobe plugin, no interpretation for lists with KSVG1. bug-205738 (just for text).

2006-04-24:02 foreignObject element

partly fixed in 9.50 alpha (build 1629)
Severity: specification violation SVG 1.1 tiny.

Description: Opera8.x ignores the foreignObject, Opera9 does not show the content of foreignObject but animates it since Opera9tp2. Build 256 does not show anything and does not animate.

Example:
foreignObject element: animate animation of specific attributes of the foreignObject element. The foreignObject contains a small XHTML document containing a small blue circle from SVG. x and y change from 500 to 100 in 10s. width and height change from 400 to 700 in 10s. The initial dimensions of the foreignObject are given with a light gray stroked rectangle, the final dimensions are given with a dark gray stroked rectangle.
9.50 alpha (build 1629) displays and animates the XHTML, but does not display the SVG inside XHTML.

Comment: Note, that the doctype is for XHTML+MathML+SVG because as far as I know, it is not possible to generate a valid document with another doctype. Anyway foreignObject is defined for SVG tiny.
What should happen, depends on the xhtml abilities of the user-agent. If it knows xhtml, it should display both xhtml and the circle from SVG, if not, it should display the circle as a minimum. The animation is applied to the foreignObject. This moves the circle and the xhtml as a visible effect. The animation of the foreignObject is ok, if the SVG circle is visible and moves.
Related bug number from opera forum for another example (not send by me): bug-205048

2006-04-11:02 (build 181 and later versions) closed subpaths and stroke-dasharray

Severity: Regression of 181, 197, 225, 229, 236, 256 compared to 1670 and older and specification violation SVG 1.1 tiny.

Description: Wrong close path behaviour with closed subpaths and stroke-dasharray.

Simple examples:
two rectangles as two closed subpaths
A path is composed out of two closed supaths, representing two squares. This works without stroke-dasharray, but with stroke-dasharray Opera9 (builds 181, 197, 225, 229, 236 fail, ok up to 1670, which have other errors explained in other errors reports) presents something different. If something red is getting visible, an error occured. Looks like a wrong close from the second z to the first M, ignoring that this path contains two subpathes, each of them closed separately. Note that stroke-dasharray is only a stroke pattern, this means, it is not possible that it is outside the stroke.
bug-203951

2006-03-19:02 animateColor and calcMode paced

Description: Opera 8.x and Opera 9tp1/2 up to build 256 do not animateColor with calcMode paced. Minor error in builds since 320.

Example:
animateColor and calcMode paced
The colour of a circle is animated with several values. The duration is 10s and the calcMode is paced, this results in a slow change of colour from green to red to blue. The colour of the stroke is animated with the same values, but with keyTimes, resulting in the same visual effect, therefore there is not visible difference in the colours of fill and stroke. The small circle bottom right shows a linear animation with the same colours for comparison - should be different except in some certain points in time. OK since Opera 9 build 272.

Second example:
animateColor and calcMode paced The colour of a circle is animated with several values. The duration is 10s and the calcMode is paced, this results in a slow change of colour from green to red to blue. The final value of fill is frozen and the same as for stroke. Opera since build 272 freezes to a wrong final value.

2006-02-14:02 repeatEvent, beginEvent, endEvent crashes Opera9tp2, ignored by other versions

Severity: crashes Opera9tp2, specification violation SVG-tiny. beginEvent crashes Opera 9.50 again...

Description: Opera9tp2 crashes with repeatEvent, beginEvent, endEvent. Other versions ignore these events.

If something red appears, the animation is wrong, for example because the events are ignored.

2006-01-24:01 painting a path of length zero

Description: Opera9tp1/2 and later builds and Opera 8.x do not paint a path of length zero with line-cap round. See explanations for stroke in the SVG specification for the painting of such a path.

Simple example:
painting a path of length zero. A path with length zero has to be painted as a circle, if stroke-linecap is round. The blue paths cover the red circles completely.

Comment: No problem with the adobe plugin, partly correct with Konqueror, and wrong with Opera9tp1, Opera8.x, the Geckos like Mozilla, SeaMonkey, Firefox etc, Gimp, Imagemagick and Inkscape.
Reported to Opera as bug-196705.

2005-11-17:01 stroke-dasharray rendering of basic shapes

Description: Opera9tp1/2 and later builds and Opera8.x have a wrong rendering of basic shapes, which becomes visible, if stroke-dasharray is applied to a basic shape.
At the initial and the final value of the path of the most basic shapes there is an additional gap as error if stroke-dasharray is applied to the basic shape.
Often it is not very important, where the rendering of a basic shape is started and where it ends, but of course for stroke-dasharray and related properties it gets important. Therefore it is exactly defined in the specification, which path represents a basic shape.

Simple examples:
stroke-dasharray rendering of a rectangle. The shape of the rectangle is given in red. For a rectangle (with rounded corners) rendering starts with the horizontal part at the top, marked here with a green arrow on a green dash. The path end is marked with a magenta arrow on a magenta dash. Note that there is no gap or overlap between the green and the magenta dash.
The rendering of Opera goes from the final to the initial value of the path and an additional gap becomes visible between these two values.
KSVG has the same errors, correct display with the adobe plugin. The gap error occurs with serveral other user agents too, often the path is correct, but not with all.
stroke-dasharray rendering of a circle. The shape of the circle is given in red. For a circle rendering starts at the '3 o'clock' position, goes down to 6 and proceeds to 9 and forward to 12 and finally from 0 to 3 again. The begin is marked here with a green arrow on a green dash. The path end is marked with a magenta arrow on a magenta dash. Note that there is no gap or overlap between the green and the magenta dash.
The rendering of Opera goes from the final to the initial value of the path and an additional gap becomes visible between these two values.
The adobe plugin has no gap, but the wrong initial point. KSVG has the correct path, but the additional gap, the same for sodipodi and inkscape.
stroke-dasharray rendering of an ellipse. The shape of the ellipse is given in red. For a circle rendering starts at the '3 o'clock' position, goes down to 6 and proceeds to 9 and forward to 12 and finally from 0 to 3 again. The begin is marked here with a green arrow on a green dash. The path end is marked with a magenta arrow on a magenta dash. Note that there is no gap or overlap between the green and the magenta dash.
The rendering of Opera goes from the final to the initial value of the path and an additional gap becomes visible between these two values.
The adobe plugin has no gap, but the wrong initial point. KSVG has the correct path, but the additional gap, the same for sodipodi and inkscape.
stroke-dasharray rendering of a polygon. The shape of the polygon is given in red. The begin is marked here with a green arrow on a green dash. The path end is marked with a magenta arrow on a magenta dash. Note that polygon is a closed path and the magenta dash is much longer than needed to cover the stroke-linejoin and the green dash has a stroke-dashoffset long enough to cover the stroke-linejoin. As far as I know, it is not defined, if the stroke-linejoin belongs to the initial part of the path or the final, but maybe it would look most suitable, if the stroke-linejoin is shared symmetrically between the initial and final part. Alternatively and maybe easier for rendering: The z command is at the end of the path, therefore the stroke-linejoin can be completely painted at the end after the final value.
Here Opera has only the problem of the additional gap instead of a stroke-linejoin with the z command. Similar problems with KSVG, adobe plugin and other user agents.

Reported to Opera as bug-187204. Since Opera 9tp2 the rendering direction is correct, but there is still a gap at the end of the closed paths.

2005-11-12:01 rendering of stroke-dasharray

Description: Opera9tp1/2 and later builds and Opera8.x interprete dashes of the paint property stroke-dasharray as subpathes and not as a pattern, leading to a wrong rendering of stroke-dasharray dashes and gaps.

Simple example: rendering of the stroke-dasharray. stroke-dasharray controls the pattern of dashes and gaps used to stroke paths. dasharray contains a list of comma-separated lengths that specify the lengths of alternating dashes and gaps.
Because dashes and gaps are defined as pattern, and not as subpaths, stroke-linecap has not to be applied to the dashes or gaps, and dashes and gaps are just a (one-dimensional) pattern inside the stroke and not outside. The lengths of each dash and each gap is exactly defined in the given list. Because it is a pattern, it will be repeated forward and backward along the stroke an its linecaps.
For the red circle this means, nothing is outside the shape marked with thin black strokes. In the center of the stroke, the dashes and the gaps both have a length of 100 and gaps and dashes have the same shapes and sizes.
For the rectangle this means, the gaps are clearly visible and have the same length 100 as the dashes.
For the line this means, the linecaps are round, not the dashes themselves. Depending on the stroke-dashoffset the linecaps might be not visible, because the pattern in this area is a gap, but this can be controlled by the author with stroke-dashoffset.
The caps of the dashes and gaps are straight lines perpendicular to the stroke-direction given by the path of the shape. Other caps for dashes or gaps are not defined in SVG 1.1 (both mobile or full). If needed, this has to be added in a future version of SVG for example as stroke-dashcap, stroke-gapcap, stroke-dashbegincap, stroke-dashendcap, stroke-gapbegincap, stroke-gapendcap or maybe better stroke-dashpattern, in parts this is maybe already covered by the pattern element (not part of tiny), which can be applied to the stroke in SVG 1.1.

Workaround for this simple example to show how it should look like: workaround.
Note, that there are additional errors, in parts not directly visible in the example, but corrected here too - use of the correct path for the rect and add the missing bevel corner top left; use of the correct path for the circle (therefore we have to go away from svg-tiny). See comments in the source code for details.
Correct display of the workround for example with Opera, KSVG1, adobe-plugin, inkscape, imagemagick, sodipodi.

Comment: Slightly different errors in KSVG 1 and the adobe plugin and many other user agents, the circle is correct with inkscape, the rectangle almost correct with inkscape, which has unfortunately the same error as Opera, already noted below as 2005-11-10:01, the dasharray itself is correct for the rectangle, for the line it is wrong too for inkscape.
Reported to Opera as bug-186670.

2005-11-09:01 path rendering

Description: First problem: Opera 9tp1/2 and later builds and Opera 8.x display wrong pathes for the begin of the initial and the end of the final part of the path of quadratic and cubic curves.
Second problem: slopes in cubic pathes are displayed as corners. Together with a wrong interpretation of the stroke-linejoin this causes wrong rendering of the slopes.

First simple example for the first problem: path rendering cubic path. The cubic paths show the same continuosly differentiable path, just the stroke-width differs. The initial and final points in the paths are the same and the derivation at this points too. Because the connection from the end point to the start point is continuosly differentiable and this points are the same, it is not necessary to finish the d attribute value with z to close the path. Note, that the derivation of the red path is in the start and end point perpendicular to the x-axis. This means, in both cases the stroke starts exactly in y-direction and ends exactly in the y-direction and in both cases the stroke-with is aligned exactly in the x-direction. In this point additionally there are no edges or corners, because the given curve is closed and continuosly differentiable.
With Opera the paths are not closed, this looks like a wrong determination of the derivation at the begin and at the end of the path and causes a cascade of further problems, for example with stroke-dasharray, stroke-dashoffset and with animation of this properties, whereat this problems are not easy to correct as for this example (unfortunately I started at an end of the problem cascade and had a long way to this cause).
Second simple example for the first problem: path rendering quadratic path.

Comment: This is displayed correct with KSVG, the adobe plugin, inkscape, amaya (which has other nasty problems with cubic paths) and imagemagick. Gimp, sodipodi, gecko/librsvg have the same error as Opera.

Simple example for the second problem: rendering of slopes of a cubic path. A closed continuosly differentiable path is shown (the circles are the control points). Therefore this path does not contain any edges or corners, just some slopes. The thin red line give the original path (mainly visible with magnification), for the same shape the stroke-width of the path is animated for the blue one within 50s. After 50s the stroke-linejoin is set from miter to round, after another 50s back to miter. Both animations are repeated. Because the path is continuosly differentiable and has no corners and edges, the change of the stroke-linejoin cannot have a visible effect on the presentation. In general even if the path would be not continuosly differentiable corners can only appear at the end points of the bezier curves, marked with yellow circles. There is one exception for cubic paths - if a slope is degenerated to a cusp, this is a not continuosly differentiable point and therefore this is an edge or corner. But the path in this example does not include any cusps.
Opera shows edges and corners instead of slopes.

Comment: The best rendering for this example is similar to a rounded end of the slope, with the adobe plugin and sodipodi this looks already very good, for the given example I cannot recognise, if they render the slope complete correctely or only as a round end. Many others use something similar to a bevel and a few use something like miter as Opera, which gives the worst result.
Reported to Opera as bug-186475.

2005-10-18:01 to animation

Description: Opera 9tp1/2 and later builds, 8x have a wrong interpretation of the additivity of animation with just a 'to' attribute, Opera 8.x in general, Opera9tp1 just in combination with fill freeze for the higher priority to animation. For the correct behaviour SVG specification points to SMIL animation recommendation, giving a special default behaviour for such animation, which overwrites the additive attribute. Opera 8.x seems to use additive="replace" as default. This is wrong, for this special case additive="sum" is incorret, too, see recommendation. With Opera9tp1 fill freeze for the higher priority to animation does not freeze the complete values, looks like a freeze of a lower priority animation. Similar animations with animateTransform and animateMotion still completely wrong.

Simple animate example: two to animations. Test of the correct additive default behaviour of to animations. A circle moves on a quadratic path using two to animations for cx and one simple for cy. The animation for cy and the first to animation for cx is repeated two time, the second to animation for cx just 1.5 times. Note that the second to animation is frozen on the have way. Because it has higher priority, the whole animation in cx is frozen. The path is given in gray for comparison, thin line for the first turn, thick line for the second turn. If the red center of the circle becomes visible, an error occured.
If t is the time, d the duration and i the initial value, a(t) is the animation function of the first to animation with the final value a and b(t) the animation function of the second to animation with the final value b, die overall animation function f(t) is:
a(t)=i + (a - i) t/d
f(t) = a(t) + (b - a(t)) t/d
If the second to animation is frozen, the whole f(t) is frozen, see SMIL animation recommendation for details.

Simple animateColor example: animateColor and to animation. Changes from blue to green in 4s, back to blue in another 4s and stopping after further 4s with green. Note, that color values outside the range 0 to 255 have not to be corrected within the animation calculation, just the current value for presentation has to be corrected. Anyway, if the animation is correct, there is no value outside the range 0 to 255.

2005-09-26:01 wallclock value for begin and end

Description: Opera 9tp1/2 and later builds, Opera 8x ignore wallclock values for begin and end

Simple example: analogue clock with local time. Opera ignores a wallclock value for begin and therefore does not animate the clock.

Comment: Ignored completely by KSVG 1, Opera and adobe plugin.
Reported to Opera as bug-186671.

2005-08-21:05 font-weight

Description: Opera 8.01/8.02/8.50 have fragmentary support of font-weight-attribute and do not animate it. Opera 9tp1 and later builds animate it, but do not support all font-weights.

Simple example: font-weight for text-elements. 'Text' is shown thirteen times with different values of the font-weight attribute and with different colors. Top left shows the values normal (red) and lighter (blue). Of course, if the font-weight is lighter, it should not cover the normal completely, but this does Opera.
Top right shows the values bolder (red) and bold (blue). Of course, if the font-weight is bold, it should not cover the bolder completely, but this does Opera.
Bottom shows all numbers for font-weight with a large font-size. It starts with 900 (red) and every 2 seconds it is displayed a font-weight of 100 less (magenta, blue, cyan, green, yellow, white, gray black). Anyway at the end, it should be possible to see all colors, because of the different font-weights, but with Opera you can just see cyan and black. This means for Opera: 900 = 800 = 700 = 600 and 500 = 400 = 300 = 200 = 100? Sounds like nonsense.

Does it animate itself? In principle: yes. But not in Opera8, this is another error. You can see it top right: 'A?' should change the font-weight from 100 to 900 after 3 seconds - but nothing happens.

Comment: KSVG 1 has similar problems with the difference between several font-weights, but the animation works. The adobe plugin knows just one font-weight and is not able to animate it. Opera 9tp1 animates, but some font-weights are the same as with KSVG 1.

2005-08-21:04 font-style

Description: Opera 8.01/8.02/8.50 and Opera9tp1 do not support the font-style attribute and do not animate it. Opera 9tp2 and later builds animate, but there is no difference between italic and oblique.

Simple example: font-style for text-elements. From top to bottom it is shown normal, italic and oblique. The shown styles are always the same and not the same as in xhtml/css: font-styles in xhtml/css. Why?
The large T and e show the difference between italic and oblique (T red oblique behind black italic, e red italic behind black oblique).

Does it animate? In principle: yes. But of course not in Opera8, this is another error. You can see it bottom right: 'Animation?' should change the font-style from oblique to normal after 2 seconds and then to normal after another 2 seconds.

Comment: It does not work in the adobe-plugin, too. But with KSVG 1 it works almost correct and with animation. Only oblique and italic seem to be nearly the same for KSVG 1.

2005-06-27:03 No activation of declarative animation with accessKey

partly fixed in build 344 (already very useful)
Severity: Specification violation SVG-tiny.

Description: SVG-tiny allows interactivity with declarative animation. For example with attributes like begin="accessKey(b)" and end="accessKey(e)" id should be possible to start and stop an animation. This does not work with Opera 8, wrong with Opera 9tp1/2 and later builds.

Simple example: activation of a declarative animation. b should begin the animation and e should end. Access key with xhtml works in opera with the following operation: first use together shift+esc, second press the desired key (check on this page with keys b and e) - but no reaction with svg! Anyway, in SVG it has to work without additional keys!

Comment: Works again fine with adobe-plugin, but not with Opera8. If the circle is clicked, it is possible to start the animation with Opera 9tp1, but not to stop. Just a very small progress, far away from correct. Since build 344 (Opera9.00) it works as for xhtml with shift+esc. Then a menu gets visible, which keys are available.
Reported to Opera as bug-174505.

2005-06-27:01 No activation of declarative animation

Description: SVG-tiny allows interactivity with declarative animation. For example with attributes like begin="id1.activate" and end="id2.activate" id should be possible to start and stop an animation. This does not work with Opera 8, Opera 9tp1 and later builds.

Workaround for this simple example to show how it should look like: animated workaround

Comment: Works again fine with adobe-plugin, but not with Opera8.
Reported to Opera as bug-174503.

Hint: If this error ist corrected, check if something like begin="id1.activate+3s; id1.click+1s" and end="id2.activate+3s; id2.click+1s" works or confuses the browser, too. Maybe there are other problems with other events like focusin, focusout, mousedown, mouseup, mouseover, mousemove, mouseout. I did not check them.

2005-06-26:01 With Opera content not of all title- and of no desc-elements is accessible

title displayed in build 272, if there is no further title in an embedded element, desc still not accessible.
Severity: Specification violation SVG-tiny.

Description: In SVG title and desc are the most important elements for a good accessibility and for general explanations of complex graphics. In the specification it is not specified, how they should be displayed, but their content should be accessable for the user in a comfortable way. Each SVG-document may contain several titles and descs. The desc element should be available as an alternate text view to the graphics. It is not displayed directly in the image, but alternatively. Container-elements like g or graphics-elements can contain title and desc to explain the function or as a non graphical replacement of the element or the group of elements. Opera 8.x and Opera 9.x just show the first title of the document and no desc-element.
Opera 9, build 272 shows the title for elements, but not for example for groups, if the embedded elements contain themselves titles.
Note that in this document the title-tag shown as caption from Opera belongs to the first rectangle for the background color and not to the svg-tag as the outermost container (corrected in build 272). Inner titles are shown in build 272 like the title-attribute in XHTML, others displays are possible too, this is free for the creativity of developers. Description could be available maybe in a first step with an additional list point in the menu, that shows up, when the right mouse-button is used within the area of the graphics or container-element. According to the painters model only the title and desc of the top object should be shown in such a graphical and interactive environment. Because desc is mainly alternate content, it is enough to have this accessible, just for the alternate text view, but if just the titles are available with the mouse, authors may put some more information into the text-element as useful for a title, this can be avoided, if the desc is available similar to each title element. Another Problem occurs, if all elements in a container like g already contain title and desc - but this problem has to be avoided with an additional invisible background element without a title by the author of the document, but user agent may show a cascade of titles and subtitles and descriptions to solve this in a more useful way.

As a workaround until this problem is solved, it can be useful simply to link a structured XHTML-document with marked up text of titles and descriptions. Anyway, XHTML ist much more useful for text than SVG: workaround for invisible title and descs, just click on the background and you will get text with XHTML.

This might be a useful display of inner title and desc elements as an alternate text-view of the image. Therefore the user agent has to generate a structured output according to the parent and child structure of the related elements, but this should be not additional problem, because the user agent has to analyse the structure anyway for the display of the image.

Comment: To be fair, in later specification titles and decriptions may be restricted to a maximum of one per element. Authors should place title and description at the top inside the according element to aviod confusion. But the user-agent has to understand the structure of the document anyway to be able to render it correctly.
Maybe Opera just has to show descriptions in an additional tab as simple text as an alternative presentation of the document and title and desc both as tool tips for the rendered version.
Amaya 9.51 has already a very good support of desc elements (and good for titles too) - they are accessible with an alternate view.
Squiggle 1.7 supports at least title and desc for the related element, displaying them as tool tips.
The KSVG behaviour is confusing, it displays just the last title and a short description, but not other titles and descs. But with an alternative view Konqueror can show all titles, descs and text without graphics. This is the best I have seen for this elements up to now.
The Adobe-plugin in Konqueror shows no title and no description, the same for SVG-mozilla even with several extensions for better accessibility - but up to now not available for SVG-documents.
Reported to Opera as bug-174502. No progress in Opera 9 up to build 272 - this displays the title-element similar to a title-attribute in XHTML, but the desc-element is not accessible.

Opera problems with (X)HTML

Opera8 support for HTML and XHTML is already very good, but changing vom Opera7 to Opera8 I was a little bit disappointed, that there seems to be no progress in removing the few maybe last very annoying errors of Opera - especially the full support for the link-element as available in mozilla and lynx already for years. :-(
The errors here are mainly related directly to elements or attributes used on this page. Only if this errors are fixed, Opera will be able to display this page in a complete and useful way.

~~2005-07-03:01 Incomplete interpretation of link-element, link-types~~

fixed in 9.50 alpha (build 1567)
Severity: Specification violation of HTML4.01, XHTML1.0, XHTML1.1. Seems to be OK with HTML3.2, maybe not for HTML2.

Description: Opera 8.x, 9.0x, 9.1x, 9.2x ignore values for rev- and rel-attributes of link-element as given in specification.

But Opera supports some values, not given in the specification, similar to author-defined values. These are "last", "up", "author". In Opera 9.50 alpha link elements are available now, but this is well hidden - use the info button in the panels called bar (View -> Toolbars -> Panels -> Info). This is not very ergonomic and can be improved, but now link elements are accessible in Opera too.

Comment: Many browsers have problems with the link-element in general and especially with many values and space-separated lists of values. They should already be able to interprete this element since html2, this means ignoring the specifications for more than 10 years (congratulations!).
Mozilla interprets it complete, including space-separated lists, hreflang-attribute and author-defined values. The same engine in Firefox is just able to do almost the same with a special extension - this is almost the same as to offer a car with the steering-wheel just as an extension - it is ridiculous. Lynx interpretes links, but not space-separated lists of values and knows no meaning of links, given by the value itself but it shows the title-attribute instead. ELinks manages the link-element complete. Opera 7, 8, 9 are able to interprete parts of the values, but ignores them, when it is getting interesting like with chapter, section and subsection. Konqueror and microsoft internet explorer ignore the link-element if not used for style-sheet.
Early complete support of the link-element maybe would have avoided the silly table-design as seen up to now on many webpages with authors beeing not able to use CSS and (X)HTML in a useful way. With the link-element it would have been possible to move the whole navigation to a link-navigation-bar of the browser ten years ago and every author and user would have known, how to use it. Now not even in Mozilla it will be used often, because for other browsers other navigation has to be offered. It is late, but hopefully not too late to use it in the future, if supported by browsers, who try to interprete (X)HTML correctely.
For example in this document the ul-list with a-elements could have been completely skipped, because it is already there as link-menu.
Reported to Opera as bug-174949 (duplicate of bug-128991).

2005-08-22:02 Opera ignores datetime and cite attributes of the elements del and ins

Description: With the elements del and ins it is possible, to mark corrections in xhtml. Opera shows this as line-through and underline. But Opera ignores the datetime and cite attributes of the ins-element.

Example: Dr. ~~h.c.~~ rer.nat. Hoffmann
Somehow datetime="2005-08-22" cite="#b2005082202" should be accessable,
for example similar to the display of a title-attribute: Dr. ~~h.c.~~ rer.nat. Hoffmann

Mozilla already displays this, but a little bit hidden. If the users clicks on an ins-element with the right mouse button, it is accessable as 'properties'. bug-127295 (only cite).

2005-08-22:03 Opera ignores cite attributes of the q-element and blockquote-element

Description: With the cite-attribute of a blockquote oder q element it is possible to offer the source of a citation. Opera ignores this attribute.

Comment: For blockquote the title attribute seems to be ignored, too (title attribute works in Opera 9tp1 but for the error no progress). Mozilla already displays cite attributes, but a little bit hidden. If the users clicks on an cite- oder blockquote-element with the right mouse button, it is accessable as 'properties'. bug-127295.