On Thu, Feb 27, 2014 at 8:50 AM, Alex Harui <aha...@adobe.com> wrote:
> Thanks for that information about web components. I thought it was still
> a popular trend. Here's my latest thoughts based on your feedback.
> Everything in this reply is top-posted so you don't have to go dig through
> the prior posts.
>
> 1) I don't think using background-image is limited to built-in HTML
> controls. Well, maybe it is, but essentially, the entire UI is built out
> of DIVs and some of the built-in controls and I think background-image
> works on all of them.
>
We still have the problem of not being to control the internals of the SVG
document when used as a background-image. See my response to (2) as to why
we need this.
>
> 2) If flickering is a problem (for SVG, I didn't see flicker for
> png/gif/jpg) some sort of "embedding" is at least possible for SVG.
>
The way I am packing multiple SVG documents in one is essentially an
'embedding' mechanism. Also, this means that we need some code in the top
SVG to switch between states. We can probably use CSS to do the switching,
but then we are limited to only the CSS approved states. If we want to do
custom, complex states, we need JS.
That said, there should be a way to have this state switching code to be
outside the SVG document. I can give that a try.
>
> 3) When I say use more CSS, it isn't so much to create the actual visuals
> unless you are manipulating borders and backgroundColor or positioning
> things, but rather, to switch between visuals via pseudo-states.
>
That, I am okay with.
>
> 4) I would really love to have "code-less" skins in FlexJS. Spark tried,
> but most every skin in the Spark theme has a script block in it. I'm
> wondering if the FXG/SVG the designer creates can be free of event
> handling code and that SVG can be injected into a skin. FXG is already
> code-less right? And it gets injected into a sub component structure.
> That sub-component structure is called a View in FlexJS. So, could the
> button view be some JS and SVG with event handling and the cross-compiled
> FXG->SVG get injected into certain places in that View's SVG? It looks
> like we could do it if the FXG cross-compiles to JS code that create
> elements and addChild's them. I think it would be more efficient if you
> could actually stitch in XML though like you can for HTML via innerHTML.
>
I have seen a few mobile skin classes do this. For example, the
spark.skins.mobile.RadioButtonSkin.as sets various sections of the skin by
pointing them to various pure, codeless FXG assets like this:
upIconClass = spark.skins.mobile640.assets.RadioButton_up;
upSelectedIconClass =
spark.skins.mobile640.assets.RadioButton_up;
downIconClass =
spark.skins.mobile640.assets.RadioButton_down;
downSelectedIconClass =
spark.skins.mobile640.assets.RadioButton_down;
upSymbolIconClass =
spark.skins.mobile640.assets.RadioButton_upSymbol;
downSymbolIconClass =
spark.skins.mobile640.assets.RadioButton_downSymbol;
upSymbolIconSelectedClass =
spark.skins.mobile640.assets.RadioButton_upSymbolSelected;
downSymbolIconSelectedClass =
spark.skins.mobile640.assets.RadioButton_downSymbolSelected;
Ignoring its baseclasses, there is pretty much no other code in
RadioButtonSkin.as and all the visuals are controlled by FXG.
Is this something like what you have in mind?
It is definitely possible to stitch in SVG inline with regular HTML; most
browsers today support this.
>
> Thoughts?
> -Alex
>
>
>
>
> On 2/27/14 12:18 AM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote:
>
> >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-accessibilit
> >y/
> >]
> >[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
> >>
> >>
>
>
