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: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 03 Sep 2010 22:22:28 -0700
Message-ID: <4C81D794.6050505@inkedblade.net>
To: Kevin Ar18 <kevinar18@hotmail.com>
CC: public-fx@w3.org
On 09/03/2010 08:02 PM, Kevin Ar18 wrote:
>  > 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.

http://www.w3.org/TR/CSS21/conform.html#replaced-element

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

Where does SVG say that 'quotes' applies to an <svg> element?

If it doesn't apply to the <svg> element when the SVG is loaded as an
independent document, then it doesn't fulfill criterion b) and is
therefore not an issue here. The only properties that are potentially
an issue here are the ones that fulfill *both* a) and b).

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

That's not really a personal question by my standards... but fwiw, I
agree with Robert O'Callahan.

~fantasai
Received on Saturday, 4 September 2010 05:23:03 GMT

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