On Feb 25, 2007, at 3:32 AM, Nikolas Zimmermann wrote:
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.
How about cases like this:
- <use> referencing <g> which contains another <use> referencing
something else (valid double use chain).
- valid <use> chains of larger size, like 2 or 3
- <use> inside one <g> referencing another <g> which contains a <use>
reference back to the original <g> (loop with two <use> elements
referencing each other's parents)
- <use> inside a marker
- <use> referencing a path with markers
- <use> referencing a path with markers which themselves contain
<use> references (valid ones)
- <use> referencing a path with markers which themselves contain
<use> references to a parent of the original <use> (invalid loop via
markers)
I'm sure there must be other complex cross-referencing cases along
these lines.
I'd also like to hear from others what they think of this level of
testing. For now I will disable <use> along with other experimental
features, but we could bring it back, given evidence of sufficient
testing.
Regards,
Maciej
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."
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
