Last Comment Bug 338279 - SVG elements embedded in html seem transparent to events
: SVG elements embedded in html seem transparent to events
Status: RESOLVED WORKSFORME
: regression, testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: General SVG Bugs
: Hixie (not reading bugmail)
Mentors:
: 347525 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-17 04:34 PDT by Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
Modified: 2008-02-21 10:48 PST (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (584 bytes, application/xhtml+xml)
2006-05-17 04:35 PDT, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
demo of none-rectangular widget (1.78 KB, image/svg+xml)
2006-08-26 08:06 PDT, Jonathan Watt [:jwatt]
no flags Details

Description Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-05-17 04:34:12 PDT
See upcoming testcase.
This behavior changed between 2006-03-20 and 2006-03-22:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-03-20+05&maxdate=2006-03-22+08&cvsroot=%2Fcvsroot
Not sure which bug has changed this, bug 330498 perhaps?

I'm also not sure which css should work on the svg element. Shouldn't border, width and height work? Currently, they do not. But position:absolute seems to work.
Comment 1 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-05-17 04:35:03 PDT
Created attachment 222330 [details]
testcase
Comment 2 Jonathan Watt [:jwatt] 2006-08-21 15:28:14 PDT
*** Bug 347525 has been marked as a duplicate of this bug. ***
Comment 3 Jonathan Watt [:jwatt] 2006-08-21 15:35:47 PDT
I disagree that this is a bug. In my opinion, the position and width/height of an <svg> element simply establish a coordinate system for their children. They do not establish an area that catches events.

Note it is very easy to obtain that behavior when it's what you really want simply by having a transparent rect catch events, whereas if we were to "fix" this bug it would not be possible to get the reverse. That is, events would not be dispatched to the non-covered HTML elements "underneath" with the correct target etc.
Comment 4 Arpad Borsos [:Swatinem] 2006-08-23 00:41:17 PDT
Interesting idea. However it should then be standardized/documented and interoperably implemented in other browsers as well.
Otherwise it will always look like a bug in gecko.
Comment 5 Jonathan Watt [:jwatt] 2006-08-23 01:08:12 PDT
I agree that it should be interoperably implemented, but I hold no hope of getting behavior like this specified in a W3C spec. Time spent on www-svg@w3.org has probably given me the lowest return on investment of any activity I've ever taken part in (unless premature aging counts as ROI). Feel free to have a go and/or document it on developer.mozilla.org/en/docs/SVG somewhere though.

I don't see why people would think this is a bug. Having elements block events on parts of the screen they don't paint to doesn't seem like standard behavior to me.
Comment 6 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-08-23 05:18:18 PDT
(In reply to comment #5)
> I don't see why people would think this is a bug. Having elements block events
> on parts of the screen they don't paint to doesn't seem like standard behavior
> to me.

Well, it isn't for Mozilla for html elements, see bug 102695. Perhaps this is not a bug, but wouldn't it be nice if this worked the same in html as svg?
Maybe Robert has also an opinion about this.

Comment 7 Jonathan Watt [:jwatt] 2006-08-23 05:48:17 PDT
Elements that have been given background:transparent are a different issue to my mind. Those elements have been made transparent, but since they can render :hover makes some sense for them. In this case we're dealing with an element that *never* renders anything, so :hover makes little sense IMO.

One of my issues with "fixing" this bug would be that it would eliminate the possibility of using an <svg> element to create non-rectangular widgets of all sorts of shapes and sizes. The point would be that mouse events outside the widget's painted area should fall through to the underlying elements, but if this were fixed then it wouldn't work as desired.
Comment 8 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-08-24 00:46:51 PDT
Having <svg> not catch events is a quirk. I think they should catch events, just like every other element that's not hidden or display:none.
Comment 9 Simon Lucy 2006-08-24 01:19:03 PDT
jwatt's original point that this is about coordinates and not about elements is the key thing.  Coordinate spaces alone should not be targets of events.  Actual elements within that coordinate space are targets.

Then arbitrary shaped elements can be used as targets for events.  
Comment 10 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-08-24 23:59:56 PDT
Like it or not, <svg> is an element and it can even be styled with CSS (in theory, maybe we don't implemented that, but we should).
Comment 11 Jonathan Watt [:jwatt] 2006-08-26 08:06:18 PDT
Created attachment 235563 [details]
demo of none-rectangular widget

Why do you think it should catch events? And what does "it could, or should, be stylable with CSS" mean? Some CSS properties have meaning on a given element, others are meaningless. E.g. what does |background-color: black| mean on an SVG <circle>? In SVG we fill things with |fill:black|.

I haven't heard a good reason to remove the functionality I talked about yet. I think we should be able to use SVG to create widgets where the painted area of the widget is the only part that catches events, otherwise how do we get none-rectangular widgets. Conversely it is very easy to get the opposite behavior that you guys want - check out this demo.
Comment 12 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2006-08-26 11:04:41 PDT
I would prefer it when svg and html would act the same here (in general, I would prefer that). So either, I would like it when both would be transparent to events or not. And I would like to have a way to enable/disable it.
(and personally I also prefer compatibility with IE6)
Is the whatwg working on describing something for this?
Comment 13 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-08-26 13:21:38 PDT
With an outer <svg> you can do things like <svg style="float:left; border:2px solid black;">. Outer <svg>s get their size and position set by CSS just like any  HTML element, so presumably other CSS styles like 'background' can and should also apply to it.

I think some sort of event transparency would be useful. IE provides some in a quirky way but we haven't done a very good job of reverse engineering that. Opera's done some work there. See bug 102695. It would be great if someone did a good job of reverse engineering IE, worked out a reasonably simple proposal and got Opera and Safari to buy into it.
Comment 14 Jonathan Watt [:jwatt] 2008-02-21 10:48:27 PST
So it seems this was "fixed" at some point. I'm not too pleased about that since I only realized late in the game. Anyway, for those that are interested, the bug to implement the pointer-events compromise to keep everyone happy is bug 410820.

Note You need to log in before you can comment on or make changes to this bug.