Re: opacity, animate and mask

Hi, Jonathan-

~:'' ありがとうございました。 wrote (on 8/5/2007 3:02 AM):
> 
> Thank you once again for your reply, your example as many others I can 
> imagine is simply resolved by providing a shield with opacity="0.00001" 
> rather than 0 or none.

And your use case is simply resolved by using the pointer-events="none". 
  You earlier promised a minimal test case, which you have not yet 
provided.  Without any more information, there's no reason for us to 
reevaluate our decision.

Consider also a gradient with fading opacity:

<svg xmlns='http://www.w3.org/2000/svg'>
    <radialGradient id='fading'>
       <stop offset='0' stop-color='blue' stop-opacity='0'/>
       <stop offset='1' stop-color='blue' stop-opacity='1'/>
    </radialGradient>

    <rect x='150' y='150' width='100' height='100' fill='red'/>
    <circle cx='200' cy='200' r='100' fill='url(#fading)'/>

</svg>

At what point should the user be able to click on the red square?  At 
the very center, where presumably the opacity of the circle is at 0? 
How big is that area, 1px, slightly more?  What if the user clicks 
slightly to the left of that?  Where does it become intuitive for the 
user that they can click-through the translucent/transparent circle?

It's clear that the default behavior should be as we have specified it, 
since it's easiest to understand for both authors and users. 
Additionally, it is the least computationally expensive option, and it's 
very important that implementors can optimize in this way.

However, I've been thinking about this, and I can see a justification 
for adding another value for pointer-events (or repurposing an older 
one). Under the definition of pointer-events [1], the value 
'visiblePainted' is specified the following way:

   "The value visiblePainted means that the raster image can
    receive events anywhere within the bounds of the image if
    any pixel from the raster image which is under the pointer
    is not fully transparent, with the additional requirement
    that the 'visibility' property is set to visible."

We could add wording that this also applies to the opacity of a <mask> 
element, so that the author could specify 
pointer-event="visiblePainted", and any areas with a 0 opacity would not 
receive pointer-events (i.e. the event would pass through).  I have not 
seriously looked at this... I don't know how difficult this would be to 
implement, nor if there are enough use cases to justify including it in 
the language.

And, of course, this fails your assertion that authors should not have 
to know about 'pointer-events' in order to achieve this affect, so I'm 
not sure at all that it would satisfy you.


> regarding "The SVG WG has discussed this very issue at length..." who on 
> the working group has a learning disability or represents the needs and 
> abilities of people other than expert authors?

We all do.  While I don't know of anyone on the WG with a learning 
disability (other than myself, as I never seem to learn not to react to 
your baiting), the active participants of the WG are all thoughtful 
people who go out of their way to think of  what would be easiest for 
authors of all skill levels.  In fact, for some of them, it's vital... 
they sell SVG viewers, and so they need as much content out there as 
they can get, to create market need.  But commercial interests aside, 
every choice we make involves some level of cognizance for the simplest 
possible solution that provides the greatest benefit.  In addition, we 
actively reach out to the WAI WG for feedback, and I personally take 
time to discuss SVG accessibility matters with friends of mine affected 
by such issues.

[1] http://www.w3.org/TR/SVG/interact.html#propdef-pointer-events

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Received on Sunday, 5 August 2007 10:15:35 UTC