IMHO, problems like this are best solved with some type of framework
that creates a high level abstraction, where you are taking the load
of the generation and putting it into the API that the generator
implements.
I think in the past, there has been to much talk about emulating as
you say Gordon, instead of actually solving problems that relate to
the future development of applications using new technology and
platforms.
I really doubt a project like this would last or survive trying to
emulate anything. It needs to solve a problem and be written from the
ground up solving that problem.
My point is, what is the end result in HTML5? To find it, work
backwards from something you want in HTML to the implementation in
ActionScript and the cross compilation API.
Mike
Quoting Gordon Smith <gosm...@adobe.com>:
My personal opinion is that outputting to HTML5+JS+CSS could make
sense if ActionScript is restricted to the subset that maps well to
JS and if you don't try to emulate any flash.* APIs. There is
nothing about MXML that is tied to DisplayObjects, for example.
Instead of writing <s:Button> and having it make me a
DisplayObject-based Button where DisplayObject is implemented using
HTML5 Canvas APIs or something, I would want to write <js:Button>
and have it make me a new Button component that is implemented using
HTML5 drawing APIs directly. I think the approach of emulating one
API with another is generally filled with gotchas that frustrate
developers, because there is too much mismatch and the emulation
isn't complete enough.
- Gordon
