[webkit-dev] SVG Stabilization

[Nikolas Zimmermann]

Hey Maciej,

> Seems like there is rough consensus around this plan. So I filed bugs
> to disable the experimental features for now:
> http://bugs.webkit.org/show_bug.cgi?id=12883
>
> And to do some kind of additional testing/review of the various SVG
> microsyntax parsers (it turns out there are a lot):
> http://bugs.webkit.org/show_bug.cgi?id=12884

Perfect. I think this covers most cases.

> Some people have suggested that <use> should also be left on. I think
> to make this possible would require significant additional testing,
> including test cases of unusual situations like circular references,
> nested references, etc. If anyone wants to do that testing, feel
> free, and ideally please document it with test cases. Note: rewriting
> <use> in a completely different way is unlikely to make it more
> suitable for prime time, since the biggest problem with it is that it
> is new, relatively untested code.

Agreed, it's definately new code, though the scenarios you are mentioning
are covered by tests (LayoutTests/svg/custom). In detail:

SVGElementInstance tests / (SVG) DOM scripting:
use-elementInstance-event-target.svg
use-elementInstance-methods.svg
use-instanceRoot-modifications.svg
use-modify-container-in-target.svg
use-modify-target-container.svg
use-modify-target-symbol.svg
use-property-changes-through-dom.svg
use-property-changes-through-svg-dom.svg

All of these tests operate on the new SVGElementInstance interfaces.
(instanceRoot method of SVGUseElement, returns the root SVGElementInstance).

The built SVGElementInstance tree is tested automatically within
use-elementInstance-methods.svg (checks instance tree consistency)

event handling on <use>:
use-event-handler-on-referenced-element.svg
use-event-handler-on-use-element.svg

Tests the various ways to set up event listeners on <use> elements:
either on the <use> element itself, or on the referenced element.
events have to be propagated to the SVGElementInstance (!) object, not
the original referenced element, nor our internal clone.
 
<use> on <use> tests:
use-forward-refs.svg
use-recursion-1.svg (<use> on <g> which references the <use> itself again.)
use-recursion-2.svg (<use> direct self-referencing>
use-recursion-3.svg (<use> on <g>, containing a <use> which references itself)
use-recursion-4.svg (same like -3.svg, but one level deeper referencing)

This covers the "hairy" parts. Complex deep references, circular references,
self-references. All test work excellent w/o crashs or leaks.

Simple <use> examples (no deep referencing):
use-on-g-containing-use.svg
use-on-g.svg
use-on-rect.svg
use-on-symbol-inside-pattern.svg
use-on-symbol.svg
use-on-text.svg
use-on-use.svg

The usual suspects: simple tests - w/o fancy features.

Misc:
use-events-crash.svg
use-symbol-overflow.svg
use-transform.svg

Other simple tests.

--
I hope the <use> on <use> tests are quite sufficient to test the tricky parts 
of the new SVGUseElement / SVGElementInstance code.

I'd like to invent anyone interessed to stress test the <use> code.
We're already much better than Opera/FF/Batik (yes even Batik) with the
current implementation - and all it needs is heavy testing IMHO.

Niko

P.S. The only known <use> problem is that the event dispatching is not 
completely implemented. IIRC the last missing issue is: (quote from 1.1 spec)

"An element and all its corresponding SVGElementInstance objects share an 
event listener list. The currentTarget attribute of the event can be used to 
determine through which object an event listener was invoked."