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

> On 09/03/2010 08:02 PM, Kevin Ar18 wrote:
> > > 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.
> 
> http://www.w3.org/TR/CSS21/conform.html#replaced-element
Seen that page several times before, but never could figure the connection even after some basic searching.  Finally tried a PDF version of the CSS specs and did a search for "replaced"
Now, I see the details on how replaced elements are handled.
 
> > > 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.
> 
> Where does SVG say that 'quotes' applies to an <svg> element?
Your right:
"Replaced elements do not have '::before' and '::after' pseudo-elements; the 'content' property in the case of replaced content replaces the entire contents of the element's box. 
To insert text around replaced content, '::outside::before' and '::outside::after' may be used."
http://www.w3.org/TR/2003/WD-css3-content-20030514/#replacedContent
So, all generated content is a non-issue (not just quotes).  Thanks.  That eliminates: content, counter-*, quotes, and maybe other styles as having any conflict with SVG.
 
> If it doesn't apply to the <svg> element when the SVG is loaded as an
> independent document, then it doesn't fulfill criterion b) and is
> therefore not an issue here. The only properties that are potentially
> an issue here are the ones that fulfill *both* a) and b).
Still agree with you there ... although we are not quite on the same page on the last issue yet.
 
> > 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"?
> 
> That's not really a personal question by my standards... but fwiw, I
> agree with Robert O'Callahan.

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 know that there are already plans to discuss this issue at the SVG face to face, so maybe it's just silly of me to even continue discussing this on the mailing list... However, your perspective interests me ... and if there's more to be learned about the specs, then great.
 
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?
 
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?
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.