Re: opacity, animate and mask

Doug,

I do appreciate your measured responses, and expect that you are  
becoming well versed in maieutics

pointer-event="visiblePainted" does seem interesting...

My concern is that after more than a decade the SVG authoring tools  
are not easy to use.
This is not a personal view, but one based on extensive user testing  
and questioning.

Who is tasked with finding out what naive users would like to be able  
to do easily?

slideshows are generally popular.... in os x, drag over images, ctrl- 
click slideshow and it's done!

if Inkscape has a simple method to create a slideshow, I've yet to  
find it....

I personally find hand coding extremely time consuming.
It may be that SVG is feature rich, but for a naive author, it's not  
easy to learn.
Today for instance I found Antoine's helpful article, please note  
well "Advanced" :
"Advanced SVG Animation Techniques"

yet I appear to need this and much else besides to set up a simple  
slideshow with opacity fades.

thanks so much once again

~:"

Jonathan Chetwynd

http://dev.opera.com/forums/topic/165853

personally it seems to me that your opacity example provides ample  
and sufficient reasoning to support my request.
had the author desired they could choose 0.0001 or similar and there  
would be no issue.
however if the author wishes to provide some scripted fractal like  
opacity with links it seems this may not be do-able.




On 5 Aug 2007, at 11:15, Doug Schepers wrote:

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 16:22:26 UTC