[css3-ui] pointer-events Opacity Threshold (was Re: [css-pointer-events] proposal: opacity threshold (for easy hitmapping))

Hi, Paul-

I agree that this is an interesting and important use case.  To get some 
more attention on it, I've renamed the thread and added Tantek Çelik 
(editor of the CSS Basic User Interface Module Level 3 spec, which is 
where the CSS 'pointer-events' property is defined, now that it's moved 
from just an SVG thing).

I appreciate Alex's detailed technical analysis on this, and I agree it 
would be worthwhile to have a discussion about alternatives solutions 
for this use case.  But in the meantime, I really like your approach; it 
seems elegant, flexible, and very clear, simple, and intuitive for 
authors, and if it could be implemented efficiently, would be useful in 
a variety of ways.  It also has the advantage that it is currently the 
only concrete suggestion at hand.

So, my suggestion is that we put this into the CSS-UI spec's 
'pointer-events' definition (in my experience, the best way to get 
feedback is to put it something into a spec... it ups the ante), and 
brainstorm not only about alternative approaches, but also ideas on how 
this approach could be implemented efficiently (even if that doesn't 
make it into the final spec, it would be good to document).  As a naïve 
suggestion, maybe the underlying graphics library could be changed to 
pass back a "hit-map" based on the value of the pointer-events opacity 
threshold at decompress/paint time?

Note that this also solves a long-time problem in SVG about whether or 
not the opacity on masks also affects hit-testing (right now it doesn't, 
but many authors have asked for it to do so).

Tantek, what's your opinion on this issue?  Could you add it to the 
CSS-UI spec, pending some other potential solution?

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs



Paul Bakaus wrote (on 4/25/11 5:44 AM):
> Bump.
>
> 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
> helps..
>
> 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
>>client)
>>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
>>bottleneck).
>>
>>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.
>>>
>>>Alex
>>>
>>>--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!
>>>>
>>>>Thanks,
>>>>
>>>>Paul
>>>>CTO, Zynga Germany
>>>>
>>>>
>>>>
>>>
>>
>>
>

Received on Saturday, 7 May 2011 18:45:03 UTC