W3C home > Mailing lists > Public > www-svg@w3.org > February 2011

Re: Announcement: Last Call WD of SVG 1.1 Second Edition

From: Erik Dahlstrom <ed@opera.com>
Date: Wed, 02 Feb 2011 13:02:02 +0100
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: "Doug Schepers" <schepers@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <op.vp9ydlv0geuyw5@localhost>
On Wed, 02 Feb 2011 12:25:59 +0100, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> On Wed, Feb 2, 2011 at 11:21 PM, Erik Dahlstrom <ed@opera.com> wrote:
>
>> You're right. What I really meant was, why should raster images get this
>> special treatment in svg at all? My guess is that this particular
>> specialcase[1] is largely unused today. I'd therefore like to open up
>> discussion on an alternative proposal, which is to simply drop the  
>> special
>> handling for raster images with alpha in the pointer-event  
>> definition[2] in
>> SVG 1.1 Second Edition. However, a thing to note is that filters aren't
>> meant to affect pointer-events processing at all, for the purposes of  
>> hit
>> detection it's as if there was no filter applied [2].
>>
>
> If pointer-events:visiblePainted is used on an <image src="foo.svg"> to  
> let
> the pointer "go through" transparent pixels of the image, and foo.svg  
> uses
> filters internally to construct the image, I would say that those filters
> *should* affect the pointer, wouldn't you?

That depends on what "raster image" means to you, since that's what the  
pointer-events section you refer to has requirements on. I would say that  
<image xlink:href="foo.svg"> is not a raster image, whereas for example  
<image xlink:href="foo.png"> is. It would be simpler if the additional  
requirements were dropped, which would make both of these cases behave in  
a consistent manner.

> Some things happened since my last message. For one thing, we implemented
> <img src="foo.svg"> in Firefox and discovered security and privacy  
> issues if
> you let foo.svg load resources cross-origin or maybe even let it load
> resources from the same origin! So we're only allowing data: URLs in  
> there
> for now :-(. So my proposed attack is blocked by that.

Could you describe these security and privacy issues in more detail? Are  
they issues stemming from CSS, HTML, SVG or a combination?

> Anyway, thanks for bringing this up again, via
>> http://weblogs.mozillazine.org/roc/archives/2011/02/distinguishing.html.
>>
>> Another question, does html:img have similar issues now that Firefox can
>> apply filters to html content?
>>
>
> No, because we don't support pointer-events:visiblePainted or anything
> equivalent.

And that's never going to change? In light of what you write below it  
seems people want that functionality.

> I'm not quite sure what you were suggesting about raster images. I've
> actually heard lots of author requests for a feature that lets pointer
> events go through the transparent pixels of images, so I'd like to keep  
> that
> feature alive in pointer-events.

It would be helpful if there was a proposal for what constitutes a  
"tainted" svg image in that case. And why only raster images and not  
vector images?

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 2 February 2011 12:02:37 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT