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

On 09/04/2010 07:13 PM, Kevin Ar18 wrote:
 > 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'm not really an expert in this area, but I'll try to explain the
best I can.

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

roc's point is that embedded SVG should not be treated differently than
any other replaced element. Replaced elements include:
   - opaque bitmaps
   - bitmaps with transparency
   - external SVG
   - embedded SVG
   - Java applets
   - videos
   - Flash
   - etc.

In all cases, any area of the replaced element, whether transparent or
not, accept mouse events on behalf of the replaced element unless that
event has been trapped by the object itself.

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

That's the plan. We want to extend 'pointer-events' to apply in CSS.

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

This would all be possible with SVG *and* other image formats (bitmap
or vector, XML-based or not) with the proper use of the 'pointer-events'
property.

~fantasai

Received on Tuesday, 7 September 2010 18:23:07 UTC