In this part I’ll write even more about styling.
Styling is almost synonymous with CSS (Cascading Style Sheets, used by modern browsers for rendering content).
There are some “lighter” variants present in other systems – like Unity’s GUIStyles.
These are just collections of fixed properties that could be applied to any GUI element (Button, Label etc.)
However, the user is “stucked” with a given number of options, as well as states (up, down, hover etc.)
The beauty of CSS is treating different GUI element types differently, so you could easily supply different properties to different elements.
This way, the property list (and memory footprint I guess) gets much shorter.
With the rise of mobile platforms, the new need emerged: targeting different screen resolutions and supplying values via CSS but contextually (depending of the current resolution).
Media Queries are specified declaratively, within CSS.
Media Query system is actually not hard to program, because it runs (in its basic, non-optimized form) only when screen resolution changes (this in turn triggers new delivery of content to all the components in the tree).
However, this is a rare event, because the resolution change happens at the application start, as well as when changing the (mobile) orientation.
The media query logic I created for eDriven.Gui has no noticeable performance bottlenecks.
However, HTML browsers are further optimized so they do not process the whole component tree in the case of media query change.
The video by David Baron is the most useful resource on the browser layout/rendering subject:
Why HTML5 won over Flex and Silverlight
Flex framework also supports style sheets.
In early versions, there was no cascading involved, and you were able to target specific components only (not based on their position in the component tree).
However, users wanted more control over styling, forcing the Flex SDK team to produce a better CSS system.
Now, the new system was more complex and more processor intensive than its predecessor. This in turn made the application startup slower (it produced noticable delays).
One thing to note is that CSS in Flex isn’t as nearly as extensive and capable as HTML CSS subsystem.
Since the rise of the style subsystem complexity produces performance problems, at one point one would normally have to ask himself: “Why going through all this pain, considering that there’s already a system – solving all of these problems – in existence?”
The system in question is HTML5:
1. handling all the mentioned problems perfectly well
2. being open
3. being free
4. with huge user-base.
Moreover, HTML5 also solves other problems like handling layout and media queries.
Additionally it’s pretty lightweight compared to Flex because its layout and styling routines run natively.
I believe this was the main reason for abandoning Flex and Silverlight (by Adobe and Microsoft) in favor of HTML5.
Read the previous part of this article.