On 4/9/13 11:39 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>>> * My earlier approach of using each .svg file as a background of each
>>> button state has a major problem - it is not runtime scriptable because
>> of
>>> security restrictions.
>> If you don't need runtime scriptability, is separate svg files a better
>> solution? Maybe we need to support both? Especially because a quick
>> search
>> of "how-to" seemed to find the separate svg file approach.
>>
>
>
> I dont think separate svg files are better for any situation. For example,
> when we use css and pseudo selectors, we are limited by the selectors
> themselves. If we need custom states, it is better if we have all states
> in one .svg file and use JavaScript to switch states.
Are you sure there isn't a way to extend the set of pseudo states?
>
> Moreover, in the separate svg files approach, the svg for a state is loaded
> only when that state is triggered, which causes an obvious flicker when
> loading for the first time.
I think I saw the flicker, but is that not solvable? If that's the state of
the world for svg as background-images it seems like nobody would be using
it.
>
> I am thinking that inert graphics (like backgrounds for panels, etc) can be
> skinned using a single svg with no JS. Anything that is interactive is
> better off with a single svg with JS scripting.
I will have to look at your code someday. I still don't think a skin needs
code like that. The interaction should be in the control, not the skin.
>
>>> * The button's label and click callback function is injected into the SVG
>>> file via the embed tag's attributes.
>> Why is the callback for click part of the "view"?
>>
>
> Because the embedded SVG eats all the mouse events. The approach I have
> taken seems to be the only way to add interactivity to a component created
> in this fashion. I did quite a bit of research on this. I will be glad to
> be proven wrong.
>
> I tried bubbling events, but it seems like the browsers create a new
> document context when rendering embedded SVG.
>
> There are other approaches we could try like positioning a transparent div
> on top of each button, but I am not sure which approach is worse. What do
> you think?
Either the browser manufacturers intended for SVG to be a valid button skin
or not. Maybe they only considered container backgrounds. We want to
identify the optimal pattern and then encapsulate it, if possible.
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
