W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2010

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

From: Kevin Ar18 <kevinar18@hotmail.com>
Date: Fri, 3 Sep 2010 23:02:26 -0400
Message-ID: <SNT110-W35A0CB34D70AAB3BD56C87AA8E0@phx.gbl>
To: <fantasai.lists@inkedblade.net>, <public-fx@w3.org>

> 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"? 		 	   		  


Received on Saturday, 4 September 2010 03:03:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 4 September 2010 03:03:03 GMT