- They're not visual. A style is comprised of text and numbers. Not pixels and colors
- They require programming skills. This means that programmers end up implementing styles, not graphic designers or illustrators.
- They are not customizable enough for real-world needs.
In other words, styles over-complicate and under-deliver. Real-world projects demand skinning, not styling. So that's why I'm really excited that the new component set that is being developed for the next version of Flash will make skinning easy as pie (although I've always found pie quite difficult myself).
It was revealed at the keynote at FlashForward Austin that Grant Skinner is working with Metaliq to bring a version of his component set to Flash 9. The components that will be included in the next version of Flash are going to be based on the components that were originally called GLIC and are now known as the mCOM components. What's great about them is that Grant built them to be lightweight and easily skinnable. Skinning the components is as easy as specifying movie clips from your library for the various parts of a component. In other words, it's just as it should be.
I hope that the next version of Flex will feature similar skinning support for all graphic assets of all components. In fact, I wouldn't shed a tear if styling was removed altogether from the component set. It takes up a large amount of space and is, for all intents and purposes, useless. If I want to change the color of the default skin in a component set, for example, I can use the Bitmap classes to apply color transformations on them.
Skinning, not styling is the way forward and I'm very happy to see this issue being addressed in the next version of Flash. I hope the same will hold true for the next version Flex too.
The Why the new components in Flash 9 will rock or “Styles are evil and must die. Long live skins!” (And yes, this is the longest blog post title ever, so sue me.) [Please don't really sue me, it's not nice and I was just kidding, and anyway, I'm sure that someone, somewhere has written a longer title for a blog post. Right? I mean they must have. Surely!] article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.

I think that point worth remembering is that components are used throughout a very large ecosystem, from datadriven product stock applications ( which are basically datagrids , comboboxes and checkboxes ) to the next trendy fashion website.
With this in mind , I’d inclined to believe there’s a niche in this ecosystem where styles are more suitable to use than skins are. Skining has a lot of problems on itself too, and it’s success is largely dependent on how each component framework allows it to be implemented.
I think that maybe because I’m so oriented towards data manipulation applications, I’m not that excited about skinning, despite the fact that I came to world of Flash from a Design background.
yeah, skinning definitely rules over styles, though I can easily see cases where styling might be easier, such as two different colors on the same component in two different instances. Even in those cases, I’d still probably rather deal with setting different skins to the clip. To me, it seems like styles should be for formatting text, not display of graphical elements.
I agree with the other commentors here. I think its important to note that styling and skinning have very different goals. Sure, you can create a new skin to match a new style but most of the time I would just rather put in a couple of numbers and theme my component.
Styles do work, for example, when you want to carry the feel of another application but not the exact look. For example, in a number of projects I work on, the visual brand of the company needs to be carried through even in products that arent directly related to the company. Do this end, we have created widgets (not components) that are stylable but not skinnable.
“They require programming skills. This means that programmers end up implementing styles, not graphic designers or illustrators.”
And at this very moment I am porting a designers styles into a Flex 2 app. I think a big part of the problem is getting folks to seperate Applications and web pages. They are not the same. The architecture is not the same, the need is not the same and the output is not the same. Styles work well in the web page arena and have a place (currently) in Flash/Flex but I think you’re 100% right – skinning is the way to go.
Hooray for lightweight, skinnable components, but HTML/CSS support should be updated, not discarded.
There are an infinite number of good reasons to display styled text in a Flash app; why invent your own custom markup language and interpreter when HTML/CSS is already so good for the job? (And we’re all so good at using it.)
It’s especially useful when your CMS is feeding the same styled text to other, non-Flash front ends.
Or am I missing your point? Or is Apollo where all this is headed? (Flash PDF HTML…)
Hi Christoph: Styled *text*, yes. Styled *components*, no. Big difference! :)
Oh! Um, good. (…crawls back into hole…)
LOL! Don’t crawl into any holes! I was trying to say (in my usually succint manner) that styles make perfect sense for HTML and that I agree completely with you that we need even better CSS and HTML support — but for text, not for styling the visual elements of components. The latter can easily be handled by bitmap/color transformations if absolutely necessary, it doesn’t require multiple Ks of framework space. (Or by designers who can just as easily create those transformations in Photoshop and export the graphics. This doesn’t even need to be a manual process as they can use actions to automate it.)
Styles vs. skins? Umm……
When you say skins are better than styles, what exactly do you mean? A statement like that baffles me. To me it sounds like “a car’s wheels are better than its steering wheel”. Sure, your car can move with just four wheels, but then it can only go i…
Were all the support and documentation issues ever sorted out at Metaliq. I remember looking at the components, but thinking it sounded just a bit too hard to implement. Perhaps it would be easier in Flash 9.
Hi Ian,
I believe there is still a lot of missing documentation and examples. A friend of mine was using them recently and ran into issues with that and wasn’t able to get her issue resolved through support from Metaliq. From what I understand, Grant was very responsive when it was brought to his attention and helped out greatly.
I read your posts for quite a long time and should tell you that your articles always prove to be of a high value and quality for readers.