Is MXML presentational markup?

Some random thoughts/questions:-

Is MXML presentational markup? I think, it is.

How does the idea of semantic web/html and microformats fit into Flex based RIAs?

How can we design applications that can be progressively enhanced or gracefully degraded?

MXML seems to be very powerful, hence very useful. If best-practices are not followed, it’s very easy to end up with bad-design/app? That’s true for AJAX (= DTHML now) also.

What should/could be the design of future flex framework (s) so that lightweight runtimes (FlashLite etc) can run flex-applications without requiring more powerful hardware and latest capabilities on devices?

MXML can be broken down into subsets:-

  • Schema for application/component structure
  • CSS for presentation – limited
  • ActionScript for behaviour/action
  • Data (XML/Model/inline-data)

Right now it’s very easy to mix all these. Experienced developers have found different ways to keep things separated but no standard as such.
Shouldn’t there be a standard way of drawing a line of separation between these as a part of development workflow/requirement? I believe, same is true in AJAX world but things (best-practices, workflow, LSM, semantic, microformats etc) are well established there?
Just wondering, if all these pieces can be separated within flex-framework, applications can be run on lightweight client by replacing cpu/memory intensive bits (which are required to parse/process/render one of the parts mentioned above) with compatible-lighter version of bits?

Does this post makes sense? 😉

Never mind the subject, I wanted to ask one question and came up with many unanswered. I have answers for some but I would be posting after some more thinking. BTW! It’s good to work with different technologies/standards, it makes me think like this.
Kevin Hoyt‘s latest post made me think some of these. Kevin has posted some more nice posts, one should read.

Technorati tags: , markup, , ,

  • Ely’s presentation at MAX (there are videos on the web) was very much inline with some of your thinking here ..
    Out of the four parts of MXML that you mention I think that presentation is the weakest link and that is what spoils it all in most cases. If we could cleanly separate out presentation into separate markup (I agree css is limited) things will become a lot more structured. The mxml graphics library coming in Flex 4 and the thoughts Ely presented at MAX are definitely steps in the right direction. Also,lately I’ve been using Degrafa a lot to achieve similar goals … things just get so much more cleaner and elegant when I describe my skin as markup using Degrafa.
    The markup story in case of data can use some improvement as well, i think we end up writing a lot of AS for data manipulation and a lot of this code is repetitive across applications .. such things should get abstracted to markup.

  • There are a couple limitations that make perfect separation of content/style/behavior difficult with MXML.
    First is the inability to set width and height in Flex CSS. Those are properties rather than styles. This can be limiting to designs. The closest available method I’ve seen for sizing is the use of constraints (left, right, top, bottom).
    You can include ActionScript by using the source property of an <mx:Script> tag, but lack of complete code hints in the external file makes that method fall short. At the minimum, you can force all of your code into an <mx:Script> block, but it’s not a perfect removal.
    One thing to note, I think, is the difference between HTML and MXML. HTML is a document markup language. Static text is still readable, if not necessarily pretty without styles. Content of a document generally shouldn’t need interactivity to be useful. Those, along with the goal of progressive enhancement to support limited user agents, is a perfect case for separation of all three.
    On the other hand, MXML is an application layout markup language. Style is mostly optional again. However, by definition, applications require behavior. For example, Flex Builder would be completely useless if all of the buttons, menus, file trees, and editors lacked interactivity.
    Ultimately, my opinion is that some separation in Flex is good because it helps with organization and maintenance, but complete separation is generally a lot of work for little gain.

  • @Mrinal: Good to hear that, I saw some videos briefly and heard about MXMLG.
    @Josh: Totally, you can use code-behind approach to keep all the code outside of MXML or use mxml for just entry-point or subclass Application etc.Most of presentational stuff can go in CSS. But this is something we learn with some experience..
    Not sure how much semantic is relevant in case of MXML which gets compiled to swf (binary) but microformats can be exposed using javascript/dom-manipulation and some deep-linking.
    HTML is structural markup but most of people still know it as presentational markup because it was/is still used for layout (without any semantic).
    As the popularity of Flex growing, I have already started seeing complex applications using bloated mxml (full of all). Probably it’s too easy to do things. I am concerned that Flex apps should not be perceived as Flash movies received some years (during dot-com time) because of intros (skip-intros) and banners?
    Developers from different background or freshers probably need a place where all these best-practices are documented or probably FlexBuilder warns/suggests you while you are trying to mix things too much?
    Thanks for feedback.

  • It is true that Flex-style code behind allows for separation. However, some folks don’t like code behind because it misuses inheritance.