W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: [css-pointer-events] proposal: opacity threshold (for easy hitmapping)

From: Paul Bakaus <pbakaus@zynga.com>
Date: Mon, 25 Apr 2011 02:44:27 -0700
To: Paul Bakaus <pbakaus@zynga.com>, Alex Danilo <alex@abbra.com>
CC: www-svg <www-svg@w3.org>, "www-style@w3.org" <www-style@w3.org>, Doug Schepers <schepers@w3.org>, Simon Fraser <simon.fraser@apple.com>, Dean Jackson <dino@apple.com>
Message-ID: <C9DB0E4F.6A9C%pbakaus@zynga.com>

It seems Alex and Simon are in alignment that this is something we want,
but hard to achieve. Honestly, I think "hard to achieve" isn't really an
argument to let it go. If everyone agrees that it is desirable, can we
just put it on the spec?

That being said, I would like to have a couple more people participate in
this discussion. I find this one of our most important internal problems,
and it is weird that there is so little public interest. Maybe a blog post

Am 20.04.11 12:01 schrieb "Paul Bakaus" unter <pbakaus@zynga.com>:

>Hi Alex,
>Understood, I was expecting the problem isn't easy to solve in WebKit. It
>however isn't easy for us as well. We need to use canvas, use getImageData
>and read out the alpha values. This fails if the graphics sit on a CDN
>(same domain security issues). So it isn't even an option that works most
>of the time.
>The alternatives we've came up with (we needed to anyway, to possibly
>support browsers without Canvas):
>1. Vectorization (this is insanely hard, we would need to automatically
>vectorize shapes into individual polygon outlines and then send to the
>2. Manual vectorization (generally easy, but a huge effort addition in the
>asset pipeline for authors. Not a good option to us.)
>3. Calculating the alpha hitmap at server level (huge traffic spike, as we
>can only transfer this stuff with UTF-8 most likely. There's weird ways to
>compress binary stuff in UTF-8, but decompressing will become the
>These are all very much half baked workarounds. Even though the way to the
>API addition proposed might be stony and steep, it would be an immediate
>win for so many developers.
>Am 20.04.11 02:56 schrieb "Alex Danilo" unter <alex@abbra.com>:
>>Hi Paul,
>>	I can see this is an important use case.
>>	However, the proposal as described is likely to be a big
>>problem for browsers such as WebKit. The basic issue is where image
>>decoding happens.
>>	For example, WebKit has a bunch of ports to different back
>>ends. On Mac/iThing etc. the images such as JPG/PNG are kept compressed
>>in the in-memory model and the decompress and paint is delegated to
>>the underlying graphics library which could optionally be H/W
>>accelerated. So in essence the hit-testing code never actually
>>sees the decoded PNG image - hit testing would normally be done
>>on the known bounds of the object. So architecture-wise this would
>>be a fairly non-trivial thing to implement at least for WebKit.
>>	It would be good to hash out some alternate way this
>>could be done to make the use case easier to handle. As it stands
>>you would need to decompress all the PNGs just to perform the hit
>>testing which will blow out memory usage and complicate things
>>quite a bit.
>>	If you used SVG for the hit testing, the authoring tool
>>could trace a path around the PNG and place a transparent path
>>object over the PNG to be the hit-testing target.
>>--Original Message--:
>>>Hi everyone,
>>>This is a proposal for a new value to the pointer-events property in
>>>both SVG and CSS.
>>>It is seldom that games have overlapping functionality as most games are
>>>very custom. Hitmaps is one of the functionalities that almost every
>>>game that runs on the open web stack needs to support. It basically
>>>describes that the player should be able to click "through" transparent
>>>areas of objects. Take an isometric image of a house that is represented
>>>as a png with some transparency around the edges. I want the click event
>>>to only fire if the user clicks on a pixel that actually includes
>>>visible content (the actual house).
>>>With current tools, and if you don't want to draw and manage every pixel
>>>using canvas, this is a non-trivial problem. We have to create dynamic
>>>hitmaps by writing the image resource into a canvas, reading out the
>>>pixel data, saving it and then later use event delegation to map every
>>>click to the right object. Therefore, I'm proposing to add syntax that
>>>looks similar to the following:
>>>.house {
>>>width: 200px;
>>>height: 200px;
>>>background-image: url(house.png);
>>>pointer-events: opacity(60);
>>>This example would say "When hovering or clicking a pixel, check if the
>>>computed alpha value is higher than 60 (either based on percentage or
>>>0-255), and only in this case fire the event, otherwise delegate to the
>>>element below".
>>>This amazingly simple API addition would make thousands of game
>>>developers a lot happier, including Zynga. I realize this might not be
>>>trivial to implement at the browser side, but I expect it will still be
>>>easier and faster than me doing it in Canvas/JS.
>>>I'm eagerly awaiting your feedback!
>>>CTO, Zynga Germany
Received on Monday, 25 April 2011 09:44:58 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC