You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by OmPrakash Muppirala <bi...@gmail.com> on 2013/04/10 04:40:36 UTC
SVG button with skin states and JS
Hi,
Here is some more experimental work based on FXG to SVG transformation.
http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html
This time, all the skin states are in one .svg file along with the JS:
http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/buttonSkin.svg
Notes:
* 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.
* In this version, I am using the <embed> tag with the src attribute
pointing to the .svg skin.
* Inside the SVG, the states are being managed using JavaScript
* The button's label and click callback function is injected into the SVG
file via the embed tag's attributes.
* Inside the SVG, the onInit() function reads the
window.frameElement.attributes properties to read and set the required
variables
* Chrome and Firefox restrict accessing window.frameElement when working on
the filesystem (cross domain scripting security precaution) But it works
fine when running from a server. I will figure out a way around this for
development ease soon.
* Communication from SVG to the parent HTML is done via calling
top[injectedCallbackFunctionName]();
* In this function call, we can send any parameters we choose. For now, I
am sending the the original MouseEvent and the this (SVG window) object.
* In the HTML page, the embed objects are styled via CSS as usual.
* Tested to work fine with Firefox, Chrome and Android Browser. I will
test with IE9 and iOS in a bit. If someone can test it in the meantime,
that would be great.
* I need to play with the "pointer-events" property of the SVG objects to
improve the hit area of the button. In Chrome, clicking on the text seems
to work, but not on the button background.
Please let me know your feedback on this approach.
Thanks,
Om
Re: SVG button with skin states and JS
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Apr 9, 2013 7:40 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> Hi,
>
> Here is some more experimental work based on FXG to SVG transformation.
>
>
http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html
>
> This time, all the skin states are in one .svg file along with the JS:
>
> http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/buttonSkin.svg
>
> Notes:
>
> * 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.
> * In this version, I am using the <embed> tag with the src attribute
pointing to the .svg skin.
> * Inside the SVG, the states are being managed using JavaScript
> * The button's label and click callback function is injected into the SVG
file via the embed tag's attributes.
> * Inside the SVG, the onInit() function reads the
window.frameElement.attributes properties to read and set the required
variables
> * Chrome and Firefox restrict accessing window.frameElement when working
on the filesystem (cross domain scripting security precaution) But it
works fine when running from a server. I will figure out a way around this
for development ease soon.
> * Communication from SVG to the parent HTML is done via calling
top[injectedCallbackFunctionName]();
> * In this function call, we can send any parameters we choose. For now,
I am sending the the original MouseEvent and the this (SVG window) object.
> * In the HTML page, the embed objects are styled via CSS as usual.
> * Tested to work fine with Firefox, Chrome and Android Browser. I will
test with IE9 and iOS in a bit. If someone can test it in the meantime,
that would be great.
> * I need to play with the "pointer-events" property of the SVG objects to
improve the hit area of the button. In Chrome, clicking on the text seems
to work, but not on the button background.
A simple rect with no fill and pointer-events set to 'all' did the trick.
And testing on iOS worked fine as well.
Thanks,
Om
>
> Please let me know your feedback on this approach.
>
> Thanks,
> Om
Re: SVG button with skin states and JS
Posted by Alex Harui <ah...@adobe.com>.
On 4/10/13 4:43 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>
> Sounds good. What would really help me is, if you get a chance, please
> take a look at the two approaches:
I'm way backlogged trying to get FalconJX caught up with FalconJS and then
fixing the release. However:
>
> 1. Using separate skin files and CSS pseudo selectors to switch states:
> http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/flexVhtml5.html
Don't worry about this one. I have to implement CSS in the infrastructure
and this should just come (almost) for free.
>
> 2. Using one skin file and JS to switch states:
> http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html
So, start hacking on this and see what happens.
>
> Let me know what parts makes sense and what needs re-thinking.
>
> For my next steps, I am thinking of creating a parallel set of html5
> controls here:
> flex-js/frameorks/js/FlexJS/src/org/apache/flex/html5/skinnedControls/<control
> >.js
> flex-js/frameorks/js/FlexJS/src/org/apache/flex/html5/skinnedControls/skins/<c
> ontrolSkin>.svg
>
> Does this make sense?
I would suggest a separate "top-level" like org.apache.flex.svg.
>
> Some basic questions:
>
> 1. Are the controls under the staticControls hand coded, or are they
> generated?
Every JS file in FlexJS is hand coded. Pretty much has to be since the AS
impl is going to use Flash APIs and the JS version is using DOM JS APIs.
Sometimes I think about writing the AS, shoveling it through FalconJS, then
gutting the methods and rewriting them.
> 2. If they are generated, can you please point me to the how I can create
> a different set of staticControls.
You should be able to copy what Peter did in creating the html5 package from
the html package. He's due to check in a Jquery-based package soon that
will serve as another example.
>
> Thanks,
> Om
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: SVG button with skin states and JS
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Apr 10, 2013 at 4:21 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 4/10/13 4:11 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
>
> >
> > On that point, I dont think that the current practices in the HTML5 are
> > necessarily the "best" practices. A lot of them involve hacks and
> browser
> > specific rules, etc. If we see an opportunity to avoid those practices
> and
> > bring in practices from the Flex world, we should.
> >
> I expect there will be several sets of components. I would like the most
> basic Button on HTML5 to be pretty lightweight. Your plans for SVG support
> sound like a separate view bead to carry around all of that functionality.
> We don't have to decide on a single approach. We can offer several
> options.
>
>
Sounds good. What would really help me is, if you get a chance, please
take a look at the two approaches:
1. Using separate skin files and CSS pseudo selectors to switch states:
http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/flexVhtml5.html
2. Using one skin file and JS to switch states:
http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html
Let me know what parts makes sense and what needs re-thinking.
For my next steps, I am thinking of creating a parallel set of html5
controls here:
flex-js/frameorks/js/FlexJS/src/org/apache/flex/html5/skinnedControls/<control>.js
flex-js/frameorks/js/FlexJS/src/org/apache/flex/html5/skinnedControls/skins/<controlSkin>.svg
Does this make sense?
Some basic questions:
1. Are the controls under the staticControls hand coded, or are they
generated?
2. If they are generated, can you please point me to the how I can create
a different set of staticControls.
Thanks,
Om
Re: SVG button with skin states and JS
Posted by Alex Harui <ah...@adobe.com>.
On 4/10/13 4:11 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> On that point, I dont think that the current practices in the HTML5 are
> necessarily the "best" practices. A lot of them involve hacks and browser
> specific rules, etc. If we see an opportunity to avoid those practices and
> bring in practices from the Flex world, we should.
>
I expect there will be several sets of components. I would like the most
basic Button on HTML5 to be pretty lightweight. Your plans for SVG support
sound like a separate view bead to carry around all of that functionality.
We don't have to decide on a single approach. We can offer several options.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: SVG button with skin states and JS
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Apr 10, 2013 at 3:02 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 4/10/13 2:39 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
>
> >>> It is not a limitation of the SVG background-images. The same flicker
> >>> happens when you use a .png or a .jpg as background. It seems like the
> >>> images are lazy loaded and I am not sure if we can force the images to
> be
> >>> loaded into memory without resorting to hacks.
> >> Again, we want to identify the best implementation and encapsulate it.
> >> Howe
> >> are other frameworks skinning buttons?
> >
> >
> >
> > The widely acceptable solutions seem to be:
> > a) Preload the images using in an onLoad javascript function
> > b) Use a sprite sheet. So, it would look something like (copy-pasta from
> > [1]):
> >
> > /* "rollover-sprite.png" file contains images for both states side by
> side. */
> > A {
> > background: url(rollover-sprite.png) no-repeat;}
> > /* Width of image for each state is supposed to be 100px here
> > (sprite will be ~200px wide). */A:hover {
> > background-position: -100px 0;}
> >
> >
> >
> > What I am doing is a modification of the sprite sheet solution. Except
> > that I am toggling visibility of states instead of translating the sprite
> > sheet.
> >
> > Again, I wouldn't want to go this route because it limits us to built in
> > pseudo-selectors/states. For example, we wont be able to do a
> three-state
> > checkbox (selected, unselected, partially selected) with this approach.
> >
> > [1]
> >
> http://stackoverflow.com/questions/13015603/css3-background-transition-flicker
> > s-on-first-hover
> Well, if sprite-sheets are the best practice, why not use the same
> technique
> for SVG? Otherwise, how does the designer express what they want without
> code?
>
Sprite sheets are a good option for raster based backgrounds, but wont work
for vectors like SVG. If you look at the SVG skin that were made from FXG,
there are no hardcoded pixel values. Everything is relative i.e. specified
in terms of percentages.
Moreover, this whole exercise is to ensure that we continue to support FXG
while we target HTML5. I have not seen any FXG skins that uses spritesheet
concept.
And when I say spritesheet approach in HTML/CSS, I mean simple translation.
There is no way to grab certain portions of a skin to display as
background like we do in Flash based games.
>
> I'm not clear that spritesheets truly have a psuedo-state limitation. CSS
> usually allows for extensibility in most places, and/or you might alter the
> class selector name. How would you do a toggle-button bar if there weren't
> separate hover visuals for selected-and-hovered?
>
Yes, you can alter the class selector name, but that has to be done through
JavaScript in reaction to any mouse or keyboard events. You cannot do a
lot with CSS's built in pseudo selectors.
I agree that it is possible to use separate visuals for selected and
hovered, except that I dont think that we should use CSS to switch the
states. If we use JavaScript like in my current example, we can support
unlimited number of states and not be restricted by the few
pseudo-selectors that CSS supports.
On that point, I dont think that the current practices in the HTML5 are
necessarily the "best" practices. A lot of them involve hacks and browser
specific rules, etc. If we see an opportunity to avoid those practices and
bring in practices from the Flex world, we should.
Thanks,
Om
Re: SVG button with skin states and JS
Posted by Alex Harui <ah...@adobe.com>.
On 4/10/13 2:39 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>> It is not a limitation of the SVG background-images. The same flicker
>>> happens when you use a .png or a .jpg as background. It seems like the
>>> images are lazy loaded and I am not sure if we can force the images to be
>>> loaded into memory without resorting to hacks.
>> Again, we want to identify the best implementation and encapsulate it.
>> Howe
>> are other frameworks skinning buttons?
>
>
>
> The widely acceptable solutions seem to be:
> a) Preload the images using in an onLoad javascript function
> b) Use a sprite sheet. So, it would look something like (copy-pasta from
> [1]):
>
> /* "rollover-sprite.png" file contains images for both states side by side. */
> A {
> background: url(rollover-sprite.png) no-repeat;}
> /* Width of image for each state is supposed to be 100px here
> (sprite will be ~200px wide). */A:hover {
> background-position: -100px 0;}
>
>
>
> What I am doing is a modification of the sprite sheet solution. Except
> that I am toggling visibility of states instead of translating the sprite
> sheet.
>
> Again, I wouldn't want to go this route because it limits us to built in
> pseudo-selectors/states. For example, we wont be able to do a three-state
> checkbox (selected, unselected, partially selected) with this approach.
>
> [1]
> http://stackoverflow.com/questions/13015603/css3-background-transition-flicker
> s-on-first-hover
Well, if sprite-sheets are the best practice, why not use the same technique
for SVG? Otherwise, how does the designer express what they want without
code?
I'm not clear that spritesheets truly have a psuedo-state limitation. CSS
usually allows for extensibility in most places, and/or you might alter the
class selector name. How would you do a toggle-button bar if there weren't
separate hover visuals for selected-and-hovered?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: SVG button with skin states and JS
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Apr 10, 2013 at 2:25 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 4/10/13 12:40 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
>
> >>>
> >>> 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.
> >>
> >
> > It is not a limitation of the SVG background-images. The same flicker
> > happens when you use a .png or a .jpg as background. It seems like the
> > images are lazy loaded and I am not sure if we can force the images to be
> > loaded into memory without resorting to hacks.
> Again, we want to identify the best implementation and encapsulate it.
> Howe
> are other frameworks skinning buttons?
The widely acceptable solutions seem to be:
a) Preload the images using in an onLoad javascript function
b) Use a sprite sheet. So, it would look something like (copy-pasta from
[1]):
/* "rollover-sprite.png" file contains images for both states side by side. */
A {
background: url(rollover-sprite.png) no-repeat;}
/* Width of image for each state is supposed to be 100px here
(sprite will be ~200px wide). */A:hover {
background-position: -100px 0;}
What I am doing is a modification of the sprite sheet solution. Except
that I am toggling visibility of states instead of translating the sprite
sheet.
Again, I wouldn't want to go this route because it limits us to built in
pseudo-selectors/states. For example, we wont be able to do a three-state
checkbox (selected, unselected, partially selected) with this approach.
[1]
http://stackoverflow.com/questions/13015603/css3-background-transition-flickers-on-first-hover
Re: SVG button with skin states and JS
Posted by Alex Harui <ah...@adobe.com>.
On 4/10/13 12:40 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>>>
>>> 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.
>>
>
> It is not a limitation of the SVG background-images. The same flicker
> happens when you use a .png or a .jpg as background. It seems like the
> images are lazy loaded and I am not sure if we can force the images to be
> loaded into memory without resorting to hacks.
Again, we want to identify the best implementation and encapsulate it. Howe
are other frameworks skinning buttons?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: SVG button with skin states and JS
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Apr 10, 2013 at 9:22 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 4/9/13 11:39 PM, "OmPrakash Muppirala" <bi...@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?
>
These are they only supported selectors [1]. I havent seen any way to
extend them today. The WebComponent/Shadow DOM draft seems to incorporate
this idea, though. [2]
> >
> > 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.
>
It is not a limitation of the SVG background-images. The same flicker
happens when you use a .png or a .jpg as background. It seems like the
images are lazy loaded and I am not sure if we can force the images to be
loaded into memory without resorting to hacks.
> >
> > 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.
>
One obvious way around it would be to use inline SVG with HTML. If they
are part of the same DOM, then we wouldnt have this problem. I was trying
to encapsulate the skin into a separate file (with svg + JS) As a result,
I had to use either the <object>, <embed> or <iframe> tags with a link to
the embedded SVG.
If we use inline SVG, we will lose the ability to share one button skin for
different button instances.
Another approach would be to keep the SVG in a separate file, but in the
compilation step, copy them as multiple instances into the html.
Maybe use javascript to create the <embed> elements?
What do you think is ideal pattern? There are multiple ways to make this
work. If you can draw some broad strokes, I can try to figure out a way to
do it.
Thanks,
Om
> >
> >
>
[1] http://www.w3schools.com/cssref/css_selectors.asp
[2] http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/<http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/>
Re: SVG button with skin states and JS
Posted by Alex Harui <ah...@adobe.com>.
On 4/9/13 11:39 PM, "OmPrakash Muppirala" <bi...@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
Re: SVG button with skin states and JS
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Tue, Apr 9, 2013 at 10:18 PM, Alex Harui <ah...@adobe.com> wrote:
> Good progress. I didn't look at your implementation, but some comments
> inline.
>
>
> On 4/9/13 7:40 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>
> > Hi,
> >
> > Here is some more experimental work based on FXG to SVG transformation.
> >
> >
> http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html
> >
> > This time, all the skin states are in one .svg file along with the JS:
> >
> > http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/buttonSkin.svg
> >
> > Notes:
> >
> > * 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.
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 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.
> > * In this version, I am using the <embed> tag with the src attribute
> > pointing to the .svg skin.
> > * Inside the SVG, the states are being managed using JavaScript
> Do the states get tied to CSS pseudo-states or something else. If we do
> have to support two mechanisms (embedded js states and separate svg files
> with css, is there a higher level abstraction that can encapsulate both?
>
In this approach, it is not tied to css states. We could do that, but as I
mentioned, it limits us from doing custom states.
> > * 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?
> > * Inside the SVG, the onInit() function reads the
> > window.frameElement.attributes properties to read and set the required
> > variables
> > * Chrome and Firefox restrict accessing window.frameElement when working
> on
> > the filesystem (cross domain scripting security precaution) But it works
> > fine when running from a server. I will figure out a way around this for
> > development ease soon.
> Try launching chrome with these additional command-line parameters:
> --allow-file-access-from-files --disable-web-security
> > * Communication from SVG to the parent HTML is done via calling
> > top[injectedCallbackFunctionName]();
> What kind of communication is required? I would hope that most "skins"
> don't have events or other output.
>
Mainly event handlers which I want to inject into the skin. Otherwise,
there should be no communication from the skin to the containing component
or document.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: SVG button with skin states and JS
Posted by Alex Harui <ah...@adobe.com>.
Good progress. I didn't look at your implementation, but some comments
inline.
On 4/9/13 7:40 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
> Hi,
>
> Here is some more experimental work based on FXG to SVG transformation.
>
> http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/embedButtons.html
>
> This time, all the skin states are in one .svg file along with the JS:
>
> http://people.apache.org/~bigosmallm/fxg2svg/buttonskinjs/buttonSkin.svg
>
> Notes:
>
> * 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.
> * In this version, I am using the <embed> tag with the src attribute
> pointing to the .svg skin.
> * Inside the SVG, the states are being managed using JavaScript
Do the states get tied to CSS pseudo-states or something else. If we do
have to support two mechanisms (embedded js states and separate svg files
with css, is there a higher level abstraction that can encapsulate both?
> * 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"?
> * Inside the SVG, the onInit() function reads the
> window.frameElement.attributes properties to read and set the required
> variables
> * Chrome and Firefox restrict accessing window.frameElement when working on
> the filesystem (cross domain scripting security precaution) But it works
> fine when running from a server. I will figure out a way around this for
> development ease soon.
Try launching chrome with these additional command-line parameters:
--allow-file-access-from-files --disable-web-security
> * Communication from SVG to the parent HTML is done via calling
> top[injectedCallbackFunctionName]();
What kind of communication is required? I would hope that most "skins"
don't have events or other output.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui