flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Demo of Button skinning: FXG vs. SVG
Date Tue, 02 Apr 2013 07:34:20 GMT
On Mon, Apr 1, 2013 at 10:24 PM, Alex Harui <aharui@adobe.com> wrote:

>
>
>
> On 4/1/13 3:44 PM, "Om" <bigosmallm@gmail.com> wrote:
>
> > On Mon, Apr 1, 2013 at 1:33 PM, Alex Harui <aharui@adobe.com> wrote:
> >
> >> Good progress!
> >>
> >> You may have seen that Peter checked in an HTML5 control set.  Now we
> have
> >> to figure out how to wire your stuff into that.
> >>
> >
> > I see that the AS side is pretty bare for the html5 controls.  Do you or
> > Peter have any thoughts on how I can proceed?  What would be a good entry
> > point for me?
> > Obviously adding skinning support to the AS side would be the first step.
> >  I would rather let you guys build a very simple example and I can
> > hopefully take it from there.
> I think the first step is to understand how it works in pure JS, then look
> at what it will take to replicate that in AS.
>
> I've been trying to read up on SVG skinning for HTML5.  I'm not finding a
> whole lot.  It appears that there are no new APIs on any components and it
> is just that the background-image CSS property can now point to svg files.
>

Yup, I dont think there is a lot of folks working on using scalable vector
graphics to build HTML5 apps.  We in the Flex world take this for granted.
 Which is why I think we are uniquely placed to propel Flex into the HTML5
world using SVG for skinning.

That said, take a look at http://raphaeljs.com/ where SVG is manipulated
excellently using JS.  Not sure how widespread it is being used.


>
> If that's true, then we need to finish up a CSS implementation in FlexJS,
> and teach FalconJX to output the right .css file.  Then the AS components
> need to leverage that CSS lookup to determine what FXG file to use.  In
> theory, the JS side will "just work".


I like Jude's approach to skinning on the MXML/FXG side.  That provides
more of a one to one match between FXG and SVG skins.



> Thinking about that a bit more, it
> might be necessary to have an SVG->FXG transform in AS so both the AS and
> JS
> can pull in .svg files.
>

I dont think this is a good idea.  We have excellent support for FXG in
Flash.  And it is relatively straightforward to convert FXG to SVG.  This
would serve both ends well.  Whereas writing an SVG renderer in AS would be
a big task in itself.  Not sure why this approach is better.


>
> I think I saw something about "embedded SVG" so we need to understand how
> that works as well.
>
> I also want to know more about how JS can manipulate the SVG and how you
> plan to manage any AS in an existing skin.
>

SVG can be manipulated using JavaScript quite well.  HTML5 also specifies
the SMIL [http://www.w3.org/TR/REC-smil/] scripting language.  I think JS
is sufficient.  Again, as I said http://raphaeljs.com/ is an excellent
example on how to do this.

I am hoping that the AS to JS conversion would take care of this given
sufficient modifications.


>
> And I'm still not sure that it is right to set expectations that we can
> transform existing Spark Skins because they composite other components.  It
> might be best to require the input to be legitimate fxg files.


I am more and more convinced that this would be the best option.   If we
are building the skinning subsystem from ground, I think going with your
approach of keeping skins as standalone files (FXG vs. SVG) makes a lot of
sense.


> Some other
> tool or part of the workflow might be able to pull as much fxg from an skin
> file.
>
> BTW, if you haven't please read http://www.w3.org/TR/components-intro/


I havent read the spec (yet), but I have seen this presentation [
http://html5-demos.appspot.com/static/webcomponents/index.html#1] which is
more brain-friendly :-)
But this concept seems to new for us to take immediate advantage of.  It
seems to be in draft stage since last year and most browsers dont support
it yet.

Thanks,
Om

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message