RE: Should the base svg element support CSS or trigger events? (test suite)

I am trying out the pointer-event="none" concept.  I modified the test suite and attached it to this email.  See the zip file.  I tested Firefox, Opera, and Webkit.  Maybe someone else can help me test IE9 or any other engines out there?
 
BTW, here's how I did it code-wise:
<svg pointer-events="none"><g pointer-events="visible">
... normal svg content...
</g></svg>
It does make for "dirtier" code, but that's what would be required if using pointer-events="none"

Results:
Firefox: Good enough to use now (near 100% pass)
Opera: Good enough to use now in some cases (inline SVG fails 100%).
Webkit: Fails 100%; unusable now.
 
 
The Webkit one is surprising.  Everyone keeps telling me it works.  So either I'm doing something wrong, or people misunderstood.  Can anyone get Webkit to work?  I have attached an extremely basic test case (doesn't cover all features) that maybe someone can find out what I did wrong.
 
Full test results are as follows:

Basic Summaries:
Firefox: Good enough to use now
Opera: Good enough to use now in some cases (inline SVG has a big issue).
Webkit: Totally unusable now.
　
　
>Gecko 2010 08 24
>Firefox 4.0b5pre
Automated:
PASSES: 1,2,3,4 (7of 8)
FAILS: 1.8, 2.8, 3.8, 4.8 (does not support mousewheel event)
Conclusion: Not sure about the mousewheel issue (if it's non-standard or not).
Manual:
PASSES: 1all,3all,4all,5all,6all,7all,
FAILS: 2.1, 8.4, 8.5 (not really issues? Firefox does not appear to have any SVG context ... making this a moot point.)
Conclusion: Not sure about the lack of SVG context menu.
 
>Opera 10.61.3484
Automated:
PASSES: 1,2,3
FAILS: 4(all8)
Conclusion: Opera does not work for inline svg (test 4)
Manual:
PASSES: 1all,2all,3all,5all,7all,8all
FAILS: 4all, 6 (not sure why)
Conclusion: Opera does not work for inline svg; I am uncertain about test 6.
　
>Webkit 7533.18.5 (r66933)
Safari 5.0.2
Automated:
PASSES: 2 (all)
FAILS: 1,3,4 (all)
Problem: Webkit is causing the svg element to be the event target and a blocking layer to content underneath
Manual:
PASSES: 2, 6, 8
FAILS: 1, 2.1, 3, 5, 7
?: 4
 
 
 
> Date: Tue, 7 Sep 2010 11:17:42 -0700
> From: fantasai.lists@inkedblade.net
> To: kevinar18@hotmail.com
> CC: public-fx@w3.org
> Subject: Re: Should the base svg element support CSS or trigger events?
> 
> On 09/04/2010 07:13 PM, Kevin Ar18 wrote:
> > I would like to take some time out to focus on this area. I hope you
> > won't mind discussing this further with me.
> 
> I'm not really an expert in this area, but I'll try to explain the
> best I can.
> 
> > Anyways, as I understand it, your basic premis is that that all replaced
> > elements should act like an invisible blocking layer to content underneath.
> > On the other hand, according to the current SVG spec, the svg element
> > (even the topmost svg element in a document) does not block access to
> > content underneath it (does not act like an invisible blocking layer)
> > and does not trigger events.
> > So, that would mean something special happens to replaced elements when
> > integrated into CSS styled content? Somehow all replaced elements are
> > forced to act like an invisible blocking layer and trigger events.
> > My question is this:
> > Is there any particular areas of the CSS specs that suggest to you that
> > this is the correct behavior? Or, in other words, is there a particular
> > line of reasoning that would explain why all browsers must act this way
> > regarding SVG?
> 
> roc's point is that embedded SVG should not be treated differently than
> any other replaced element. Replaced elements include:
> - opaque bitmaps
> - bitmaps with transparency
> - external SVG
> - embedded SVG
> - Java applets
> - videos
> - Flash
> - etc.
> 
> In all cases, any area of the replaced element, whether transparent or
> not, accept mouse events on behalf of the replaced element unless that
> event has been trapped by the object itself.
> 
> > On a related note, for the sake of argument let's assume that blocking
> > content underneath is the correct behavior for svg in html (or xml+css).
> > Then consider this hypothetical question:
> > Which spec would you change to accomodate an svg element that does not
> > block access to content underneath it? Would you introduce some special
> > CSS property? Maybe add pointer-events to CSS and specify how it affects
> > svg elements?
> 
> That's the plan. We want to extend 'pointer-events' to apply in CSS.
> 
> > BTW, just so we are both on the same page, here's my reasoning why this
> > is so important; I know I said this elsewhere, but it's possible you
> > just don't have the time to read through all that past info.
> >
> > The ability to integrated SVG and HTML, presents some interesting
> > possibilities for future websites. Consider the following:
> > * Using SVG to circle text or html items on a wepage.
> > * Drawing arrows from one part of the page to the other (but not block
> > content underneath).
> > * Having oddly shaped menus, borders, layers, etc....
> > * Adding a "hazy" or semi-tranparent layer over html object, yet still
> > be able to interact with the html object underneath.
> > * Creating a graphical object "under" the cursor that follows the mouse,
> > but still lets you click on items underneath it.
> > None of this is possible is the topmost svg element blocks content
> > underneath or triggers events.
> 
> This would all be possible with SVG *and* other image formats (bitmap
> or vector, XML-based or not) with the proper use of the 'pointer-events'
> property.
> 
> ~fantasai