Re: [CSS3-UI] Problems with pointer-events draft

Hi Kevin,

Thanks for reviewing this CSS3 UI editor's draft feature and providing
early feedback - really appreciate it. I've collected your list in the
issues list and will expand and follow-up there.  Feel free to add
more there as well.



On Wed, Nov 17, 2010 at 12:47, Kevin Ar18 <> wrote:
> In reference to the following section:
> I figured I would polish up some test cases based on what was put in the
> CSS3 spec.  However, there are a number of points of confusion that I want
> to clear up.
> First, off, these are only my views on the issue... so I really need some
> input to see if my reasoning is wrong or not.
> Second, I apologize for the the aggressive sounding tone; I really don't
> mean it to be that way ... and I appreciate the effort people put into
> working out the details ... however, I just want to get to the heart of the
> issue quickly, so I really hope the original author(s) won't feel offended
> by it. :)
> Issue 1. As far as I can tell, the spec does not address the most important
> issue: whether the svg rectangle should trigger pointer-events.
> There was considerable discussion over this very topic in the svg mailing
> list as well as in various meetings.  The conclusion: it was decided that
> the topmost/base svg tag should not trigger pointer events -- it should not
> act like an invisible rectangular object that you can click on.
> The relevant discussion is listed here:
> under the section:
> "'pointer-events' and (event) transparency"
> Sounds fine... but... I do not see that mentioned in the spec ... which
> means is this issue still undecided?  is it just an oversight?  am I
> mis-understanding something?
> Issue 2. Why even mention all the pointer-events properties for SVG when
> they all mean the same thing for the svg tag: "none"?
> * According to the SVG spec and the discussions, the svg tag never triggers
> pointer events -- no matter what the "pointer-events" property is set to.
> (There is one exception: the "boundingBox" property from SVGTiny)
> * Thus, "pointer-events" has no effect on the svg tag; it only affects it's
> children. (Again, "boundingBox" is the 1 exception.)
> * Example: auto, none, all, visible, visiblePainted, visibleFill,
> visibleStroke, painted, fill, stroke ..... do not affect the base svg tag in
> any way; these properties are merely inherited by it's children.  Note:
> "auto" is the only property that is different. "auto" changes to
> "visiblePainted".
> So, why even list many of the attributes like "visible", "visiblePainted",
> "visibleFill", etc... when they have no effect?  Or..., does this imply that
> the CSS3 specs actual means something different?  Do things like "visible"
> and "visiblePainted" work differently than in SVG?  Really, that is probably
> the most imortant thing; does listing this info in the spec imply that there
> is something different about it?
> Issue 3. There is no way to specify that the svg tag should trigger events.
> Based on the points 1 & 2, none of the current properties allow the svg tag
> to trigger events.  I can forsee this being a pretty big issue when you
> specifically want to treat the svg element like a drawing surface and
> capture mouse events.
> SVG Tiny added another property called "boundingBox"
> (  Should
> a property like this be added to the CSS3 specs to allow the svg tag to
> trigger events?

-- - I made an HTML5 tutorial!

Received on Wednesday, 17 November 2010 23:16:07 UTC