SVG elements embedded in html seem transparent to events

RESOLVED WORKSFORME

Status

()

Core
SVG
RESOLVED WORKSFORME
11 years ago
10 years ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

({regression, testcase})

Trunk
x86
Windows XP
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
Created attachment 222330 [details]
testcase

Updated

11 years ago
Flags: blocking1.9a1?
*** Bug 347525 has been marked as a duplicate of this bug. ***
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.
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.
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.
(Reporter)

Comment 6

11 years ago
(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.

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.
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

11 years ago
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.  
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).
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.
(Reporter)

Comment 12

11 years ago
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?
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.

Updated

11 years ago
Flags: blocking1.9a1?
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.