Hi Peter,
Ripple echoes some thoughts I have had ever since I became infatuated with
the seperation of content and presentation when studying XHTML and CSS2 and
being awestruck with the CSS based demos at www.csszengarden.com.
It seemed to me that Flash was ripe for the same kind treatment, especially
now that Flash seems to be geared towards use on multiple devices such as
mobile phones and PDAs etc.
I've done a few small proof-of-concept experiments and came up with the
following ideas:
* Use a valid XHTML document to represent the page content and structure
using elements with named IDs and seperating out wherever possible any
graphical content into CSS rather than embedding them in the XHTML.
* Use external CSS to style the content for web browser, print, devices and
Flash.
* Use JS to redirect a user's browser to the Flash version if available.
Reading over the Ripple page, the link to "Descriptor XML format" is a link
to a topic that does not yet exist. I'm not sure I understand exactly what
the function of the Descriptor XML is, but my guess is that it is to contain
metadata relating to named page elements that Flash would use to render that
content.
My concept would use an extensible Flash-centric version of CSS to contain
the same type of info - location, size, position, colours, links to
external jpegs and swfs or library items, class info, property
initialisations etc.
I figured this would be possible since you should be able to load any text
file using XML.load and grab the raw contents with XML.onData and then pass
the CSS string onto a custom CSS parser instead of the XML parser. From
there the string could parse the data into a CSS object, which would contain
a list of element selector IDs and attributes.
Parsing the XHTML document into an object will also yield something that
looks almost identical to the javascript DOM. This would make it fairly
simple to match the CSS selectors to the document elements. That would
probably avoid the need for including XPATH too.
Rendering would be handled by other classes which could easily be extended
and would allow you to have a very lightweight renderer which only supports
a few tags, to supporting the full XHML/CSS set for larger projects, to
adding XUL or even MXML... so your code overhead would only be as large as
your requirements.
Anyway I've gone on long enough, but I'd be interested to hear your thoughts
on these possibilities and how they relate to Ripple.
Thanks for your time,
- Scott W.
_________________________________________________________________
Read the latest Hollywood gossip @ http://xtramsn.co.nz/entertainment
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
