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. It sat down with many companies, many web developers 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:
- language that allowed easy to read but advanced layout
- 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
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 still able to export a Flash project as a native iOS mobile app but it also prevents the benefits of it’s 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">
label="All documents in project"
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. 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. It
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 unpopular Flash is 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 run by Adobe. This has been a pain but also a blessing. Having a single vendor prevents fragmentation. They as a company are rapid to address bugs. 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.
I highly recommend the MXML specification to the W3C to be implemented as a standard going forward. The tools to view, verify and compare a browsers implementation to the Flash Runtime implementation 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.
FYI Adobe donated the Flex SDK to Apache and it’s now being developed and maintained as open source by a community of advanced 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).