Over the last 10 years I’ve been using Flex MXML markup to make pixel perfect layouts that create and run in mobile, desktop and web browsers. It has been an environment that made all projects a blast. Before that I was a web based developer using HTML, CSS and JavaScript. This environment was one of the most frustrating, under developed, misappropriated set of technologies to build or design anything more than a text and pictures document. Hence, it was a terrible fit for applications.

But the HTML stack has improved and continues to improve. However, many problems exist when you rely on the browser to layout and position your content using HTML markup. First, there are different layout types, with different layout rules. Many are confusing and do not make sense outside of the context of a document. For example, a Division element stretches to fill all available space on the screen by default but not the available height. An Span element on the other hand, ignores all width and height sizing that you might require and then fills only the space of it’s content. There are many quirky layout rules that don’t make sense when trying to layout an application.

These type of issues make sense in 1990 when the internet was about sharing documents. Now, we are creating online stores, advanced interactive social networks, inline social video games, online tv and video sites. Many new and different types of applications are being created and the new wine is being poured into old wine skins pouches (this results in the old wine skins pouches to stretch at the seems and burst).

In the early 2000s Macromedia and Adobe recognized the HTML stack was stretched into doing things it was not original designed to do. They sat down with many companies, many web developers, many application architects and asked an important question:

If we could redesign the web today, knowing what we know, knowing what people are building and what people need what would it look like?

With this in mind, Macromedia and then Adobe (who purchased Macromedia) went on a quest to create all the components necessary to create a perfect environment for accomplishing these goals. Those goals included:

• markup that was easy to read and write
• a programing language with advanced object orient programming
• a user interface that can take advantage of the benefits of Cascading Stylesheets
• a set of preset collection of components that could used in layout
• a compiler to check for and prevent errors at runtime
• a collection of runtimes that allowed your application to run on the most popular platforms without changing your code base. This means you can build an application with one code base and export it to web, desktop and mobile without changing your code and get the same pixel perfect results. Instead of multiple teams you can have one team and focus on a better product rather than maintaining multiple code bases

This product was named Flex and used MXML for markup and layout, CSS for styling and ActionScript3 (an advanced optionally object oriented version of JavaScript). As soon as I started using Flex (after using HTML, JS, CSS, Flash 7 and ActionScript2) my world opened up. I could create applications and it was fun. It looked the way I wanted. It was performant. As a content creator, originally a designer, it was amazing.

Now, after spending years of energy and time learning Flex, creating applications and then later fighting for the Flash platform I’ve come to the conclusion of a couple of things.

• Flash will never be on iOS (iPhone or iPad). You are able to export a Flex or Flash project to a native iOS mobile app using LLVM but an app is does not have the benefits of the ubiquitous nature and ability to run in a browser.
• Apple may never upgrade it’s Safari browser with necessary features. All the new HTML5 web features may never see the light of day in this browser. This choice by Apple prevents the web from progressing. So an HTML alternative may be necessary. A boycott by developers of the Safari browser may be more effective.

In these cases, I would suggest that browser manufacturers instead agree to support the MXML specification. It provides a very clear layout and markup language, supports CSS and is designed for the web. It fixes numerous web related issues. Most of all, you can use the existing MXML and the Flex compiler to confirm the layout, look and functionality of the markup.

<s:HGroup width="100%" verticalAlign="baseline">

    <s:Label text="Export:" 
         color="black"
         fontWeight="bold"
         minWidth="120"/>

    <s:RadioButton id="selectedDocumentButton" 
         label="Selected Document" 
         color="black"
         selected="true"
         groupName="amountOfDocuments"/>

    <s:RadioButton id="allDocumentsButton" 
         label="All documents in project" 
         minWidth="120"
         groupName="amountOfDocuments"/>

</s:HGroup>

Being able to see and test MXML documents in the browser are very close to being possible. A few months ago I created a Live MXML Editor app that lets you see code rendered live (new versions on the download page). Using Mustella, an open source Flex SDK testing harness, MXML documents can be rendered in the Flash or AIR Runtime and then that rendering can be compared via the software to a browser manufacturers rendering. This allows browser manufacturers to implement and test layout and CSS support and confirm it using tools that exist now.

This specification will allow a structured, strongly typed UI and layout for browser manufacturers to aspire to. Using the Flex compiler you can take any MXML document and export and view it in the browser. With a companion web app, which would probably take a week or two to develop, you would be able to type MXML live using the Flash runtime and in time, see and compare the output to the same MXML rendering generated by the browser. The Flash runtime would be the baseline.

Note: As Flash has been unpopular in some in the media it is loved by millions of developers (and users who mostly enjoy it’s features without knowing what it is or has done for them on sites like YouTube, Vine, Vimeo, Facebook, Google, etc). The downside and upside is that Flash is developed by Adobe. This has been a blessing but also at times a pain. Having a single vendor prevents fragmentation and they are rapid to address security issues and bugs but at the same time they control what features are added and bugs that are fixed. Even so, they have a multitude of unit tests and stringent quality control. The same code written in 1998 runs the same in the latest version of Flash and the latest Flash app or game runs exactly the same across browsers, operating systems and devices because of their abstraction layer. The main downside to the Flash Platform is Adobe not allowing open source development. It is proprietary.

The solution, I firmly believe, is to adopt the MXML markup specification to the W3C and implement it as a standard. This will allow browser manufacturers a way to help developers with a consistent language, a way to help users with consistent and expected results, and a way to help manufacturers with an open source way forward to implement an awesome language specification completely in their control and time frame. This allows the benefits of MXML across browsers, and platforms when plugins aren’t available. The tools to view, verify and compare a browsers implementation to the Flash Runtime allow manufacturers a way to test their implementation. The existing browser rendering engines can start by creating tags that have the predefined layout rules described by MXML and then comparing them to the Flash Player’s rendering using bitmap compare or Mustella testing suite.

FYI Adobe donated the Flex SDK to Apache and it’s now being developed and maintained as open source by a community of developers. Any browser manufacturer developers can join and improve MXML and Flex. Browser manufacturers can test their MXML interpreters and make sure it works in their browser and Adobe and or the Apache Flex community can test their MXML interpreters and make sure it works in the Flash and AIR runtimes (the same runtimes that run in the browser, as iOS and Android apps, and as Mac, Linux and PC apps).