On Mon, Apr 1, 2013 at 3:48 PM, jude <[email protected]> wrote:
> Well done! This looks viable! Comments inline, > > > On Mon, Apr 1, 2013 at 2:59 PM, Om <[email protected]> wrote: > > > I was able to add quite a bit of functionality to my XSLT transform. > Just > > about enough to be able to port the standard Spark Button > > (spark.skins.spark.skins.ButtonSkin.mxml) to HTML5/SVG. > > > > Here is a demo showing them side by side: > > > > http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/flexVhtml5.html > > > > Some notes about the transformation/workflow: > > > > 1. The XSLT does not handle states yet. I am manually modifying it > handle > > different states. Each state/run of the XSLT on the produces a single > > .svg file. So we have three svg files as a result: > > > http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/button_skin_up.svg > > > > > http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/button_skin_over.svg > > > > > http://people.apache.org/~bigosmallm/fxg2svg/buttonskin/button_skin_down.svg > > > > I probably will hook it up so that ANT can do some preprocessing of the > > XSLT for each state involved. Anyone else has better ideas on how to do > > this? > > > > 2. The XSLT handles these FXG elements (and their attributes) for now: > > > > 1. Rect > > 2. fill > > 3. SolidColor > > 4. LinearGradient > > 5. stroke > > 6. LinearGradientStroke > > 7. gradientTransform > > > > As I am targetting a very specific usecase (ButtonSkin.mxml) I am > guessing > > there are quite a attributes that I dont handle - for now. > > > > 3. I tested it on the latest versions of Chrome and Firefox. Chrome > seems > > to have a more faithful rendering fidelity among the two browsers. Note > > that I have not used ANY browser specific style rules (yet!) > > > > 4. I have had to handcode some of the more fancier gradientTransform > > functionalities. A lot of fun Math is going to be involved here :-) > > > > 5. I am using pure CSS to skin the various states of the html Button > > element. I guess we could also do it using Javascript. But things seems > > to be working this way. I plan to continue in this approach unless > others > > (Alex/Erik/Jude -> I am looking at you!) have concerns. > > > > For simple buttons pseudo selectors will work (pasting your CSS here): > > .button { > position: absolute; > background: url(button_skin_up.svg) 0 0 no-repeat; > border: 0px; > font-size:12px; > } > > .button:hover { > background: url(button_skin_over.svg) 0 0 no-repeat; > } > > .button:active { > background: url(button_skin_down.svg) 0 0 no-repeat; > } > > > When you get into custom states and other controls I think you'll have to > use JS or a combination of JS, styles and pseudo states to handle it. And > it depends on how much of states we are copying over. I don't know the > inner workings of the AS->JS workflow. If we use states then we will > probably have the getCurrentState() method used by the skin classes to tell > them what state they are in. > > Then in that method you would have something like: > > skin.js: > > if (currentState=="hover") { > element.class="button ok over"; > } > else if (currentState=="down") { > element.class="button ok down"; > } > else if (currentState=="myCustomState") { > element.class="button ok myCustomState"; > } > else { > element.class="button ok"; > } > You are right, for more complex components, we need to change the skin states via JS. But from a skinning point of view I am not worried because the AS to JS conversion will (should) take care of this part. I think the key is to have a style entry for each skin state. I think we can figure out a way to autogenerate the CSS styles somehow as well. Thanks, Om
