RE: Should the base svg element support CSS or trigger events?

> This option would actually be inconsistent with the CSS specs, which
> consider an <svg> element to be a (styleable) replaced element.
Can you show where it describes that in the specs?  That would help me out at least.
 
> What needs to be defined is what happens when a property is set on an
> embedded <svg> element that is both
> a) applicable to replaced elements in CSS
> b) applicable to the root <svg> element in SVG
> If there are any properties that match both a) and b), then we need some
> integration work in the specs. If there are no such properties, then no
> further work is needed, except perhaps some examples in the specs to help
> people understand the differences and similarities between external and
> embedded SVG.

 
Yes, very good point.  I had started working on that very issue a day or two ago; so I decided I'd better hurry up and finish.  The attachment contains all the details.
 
1) I went through almost every CSS style that is being currently worked on and checked for conflicts with the svg tag.
2) The css.rtf document lists my results.  Many CSS properties have no problems/issues.  However, there are some tricky ones.
3) In almost every single case, the conflict has to do with events as I outlined here:
http://lists.w3.org/Archives/Public/public-fx//2010JulSep/att-0077/index.zip  (start with index.html)
 
 
 
 
-----------
On another note, I wonder if I could ask you a more personal question?
What is your opinion about the whole events and blocking vs non-blocking question?  Basically, my argument was that the svg element should not act like an invisible blocking layer that blocks html content underneath it and it should not trigger events -- only SVG graphical items can do that.
In bugzilla.mozilla.org I am reminded of a statement Robert O'Callahan made here: https://bugzilla.mozilla.org/show_bug.cgi?id=410820#c26 "I don't really like this because it's carving out an exception for <svg> elements as the only replaced elements which can be transparent to events."  Basically, he believes that the opposite approach should be taken regarding SVG... and Firefox is actually implemented this way.
I was wondering if maybe you had a different perspective on "why the svg element should act like an invisible blocking layer and should trigger events"?