On Wed, Feb 26, 2014 at 7:44 PM, Alex Harui <aha...@adobe.com> wrote:
> > > On 2/26/14 4:03 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > > >On Wed, Feb 26, 2014 at 9:57 AM, Alex Harui <aha...@adobe.com> wrote: > > > >> Sorry, wasn't clear. > >> > >> Thanks for reminding me that FXG is a class linked into the SWF and > >> referenced as a class by the AS code. On the JS side, do we want that > >>FXG > >> class to be a "class" (its own JS file that loads or has SVG data in > >>it)? > >> Or is more "conversion" needed. > >> > >> > >I have been thinking of a spark skin (ex. spark button skin) having an > >equivalent SVG document on the JS side. The button class itself will have > >an equivalent in js. > > > >Example: > >TextButton.as + TextButtonSkin.mxml === TextButton.js + TextButtonSkin.svg > > > >The TextButtonSkin.mxml links all the required FXGs to make up the various > >button states' visuals. It also has the code required to switch the > >states, etc. The same thing happens in TextButtonSkin.svg - it contains > >all the SVG elements and the JS code (or SMIL) > > > >I suppose this is quite similar to the spark architecture. > I finally got a chance to look at your .js and .svg files. For those who > haven't looked, the SVG file has SVG for different view states in it and > logic to handle mouse activity and switching SVG "trees". > > Therefore this TextButton is not using an HTML Button with an SVG > backgroundImage and is instead emulating a button in SVG. Did you rule out > the HTML Button with BackgroundImage option? I think there were concerns > with flickering? Yes, flickering was a big problem. Also, this approach is limited only to built in HTML components. > Have you looked into what it will take to implement > accessibility in the SVG button? > Accessibility comes free with SVG when implemented via ARIA. I havent tried it yet, but doesnt look like a problem. [http://blog.paciellogroup.com/2013/12/using-aria-enhance-svg-accessibility/ ] [http://caniuse.com/wai-aria] > > Anyway, back to skinning. The following is long-winded and mostly just > thinking out loud. None of this is set in stone. > > I think the most straightforward cross-compilation that would be easiest > to implement in the compiler would simply make a .js file for each .fxg > file where the JS file knows how to inject the SVG into the DOM. > > > Here's a pseudo-code example: > <!-- someskin.mxml --> > <Skin backgroundImage.normal="{normalfxg}" > backgroundImage.hover="{hoverfxg}"> > <states> > <State name="normal" /> > <State name="hover" /> > </states> > </Skin> > > <!-- normalfxg.fxg --> > <Graphic> > <Path x='0' y='0' data='M0 100 100 100 100 0 0 0> > <fill> > <SolidColor color="#ffff00" /> > </fill> > </Path> > </Graphic> > > The MXML compiler generates code for someskin.mxml that essentially does > this: > if (currentState == "hover") > backgroundImage = new hoverfxg(); > else > backgroundImage = new normalfxg(); > > And I believe the .fxg files becomes essentially > public class normalfxg extends Sprite > { > public function normalfxg() > { > graphics.beginFill(0xFFFF00); > graphics.drawPath(...); > graphics.endFill(); > } > } > > The cross-compiler would cross-compile the fxg files to normalfxg.js and > hoverfxg.js. > normalfxg = function() { > this.element = document.createElement('div'); > this.element.innerHTML = '<svg><polygon points="0,0 0,100 100,100, > 100,0" > style="fill:#ffff00;" /></svg>' > } > Actually, I like this approach. Also, it just occurred to me that we can actually skip the FXG to SVG translation and write a subsystem to cross-compile the graphics drawing code. For example, <svg> <polygon points="0,0 0,100 100,100,100,0" style="fill:#ffff00;" /> </svg> can be drawn in Javascript as: function drawPolygon() { this.polygon=document.createElementNS("http://www.w3.org/2000/svg ","polygon") this.polygon.setAttributeNS(null,"points",{0,0 0,100 100,100,100,0}) this.polygon.setAttributeNS(null,"fill","#ffff00"); document.documentElement.appendChild(this.polygon) } I wanted to do this do build our FlexJS charts in SVG as well. We can build up a library for drawing graphics this way which we can reuse for drawing other components like Charts. And I dont think we need the extra div because we can directly add it to the documentElement if needed. > I think this puts an extra div in the DOM though. It may be possible to > optimize away the extra div. But the .js file for someskin.mxml as the > same logic: > if (currentState == "hover") > backgroundImage = new hoverfxg(); > else > backgroundImage = new normalfxg(); > > > Now, I'm currently calling these skins "views" in FlexJS and am > distinguishing skinning as something else. Yes, I realized that. We should get in sync with our terminologies :-) > The above example generates > what I call a static view. It's look cannot be changed by CSS unless you > swap out the entire view. But since the browsers have powerful CSS > implementations, I want to use CSS more. The Web Components spec and its > Shadow Dom also makes me want to head in the direction of more CSS as I > think browsers are going to optimize for it. > Browser support for Web Components/Shadow DOM is already very poor. [http://caniuse.com/shadowdom] Also, I wouldn't pin my hopes on Web Components becoming prevalent any time soon. Webkit recently removed all its Shadow DOM code. [ http://trac.webkit.org/changeset/164131] That takes away a chunk of users (Mac, OSX) who cant make use of this feature any time soon. > This will have an interesting impact on skinning. In Spark, you specify > whole skins via CSS via skinClass and maybe there are some styles > supported by that skin. In FlexJS, we've been forced by the HTML > components to have separate View and "Skin" concepts. A Button's View is > baked into the native control, but for a more complex component like a > Panel, the View is composed of a TitleBar and a ContentArea, and other > Panel Views may have a StatusBar and/or ControlBar. But the actual > visuals of the TitleBar are defined (or will be defined as we haven't > fully developed this yet) via CSS. To change the look, you change the > CSS, including backgroundImages. Themes are effectively different CSS > files. > I am not entirely against using CSS. But having to deal with the various vendor prefixes -moz, -webkit, -o etc. is not fun. Also, I am doubtful about the tooling side of this. With FXG/SVG, we can at least have Fireworks or Illustrator spit out FXG which we can directly use in our apps. Photoshop/Illustrator, etc. have pretty poor support for exporting CSS. > > It is certainly allowed to bake your visuals into the View, but then it > won't respond to CSS changes unless you swap in whole Views. So, do we > want to encourage folks to do that or encourage them to separate out the > SVG from the subcomponent structure in the View? > > If you separate out the SVG files then I think we end up loading .svg > files like we would the png/jpg/gif files for backgroundImage in the HTML > controls. > We may have flickering problems with this approach. Also, you lose the ability to control the innards of the SVG documents. > > BTW, I think both of these two plans also mean that the SVG doesn't have > to have event management in it. The event management goes in the View > logic and makes for "code-less" skins which are easier for designers to > work with. > The only reason I am handling the events in SVG is because the SVG eats all the mouse events. I don't think there is a way around this problem. > > Anyway, enough rambling for now. What are your thoughts? Both of these > proposals would result in a different setup than you have now. What are > the advantages of the way you configured things? > Here is my reasoning for my approach: I am looking at this from a tooling and rendering fidelity point of view. As I mentioned earlier, CSS export support is quite poor. Whereas, we already have a robust export to FXG functionality (if Adobe does not pull that feature). This will let us build and skin our Flash apps quickly (like the current Flex SDK) At the same time, we know that there is almost a one-to-one feature match between FXG and SVG. Rather, FXG is a subset of SVG. Which means that we can relatively easily get all the features of FXG in an SVG version. Plus, FXG/SVG is all vectors. Building for multiple screen sizes and resolutions becomes a breeze. Again, the current Flex SDK excels at this. HTML/JS/CSS apps are striving for responsive layout these days. Flex solved that problem a long time ago. I want to take this idea from the Flex world to into the HTML5 world. FXG/SVG both support bitmap images. So, we are not just restricted to vector shapes for skins. As for SVG handling events, it just seems natural to me. Most modern browsers allow inlining of SVG in HTML. Which means that every SVG element is part of the HTML DOM and is more than capable of handling events. Check out all the D3.js examples where everything you see in the screen are interactive SVG elements. The reason I am packing each SVG documents with different states is for a)encapsulation and b)to avoid flickering. I think my approach solves both problems. At the very least, we could have a mouse catcher inside the SVG and pass the event back to its parent element which would do the actual 'event handling'. Would that work for you? In the end, you can very well decorate SVG elements with CSS. We can have the best of both worlds. [http://css-tricks.com/using-svg/] Thanks, Om > > Thanks, > -Alex > >
