Styling

[Jacob Wright]

So I've been thinking about styling, and I think we should have it be part of our first release. Here are my reasons:

• Flex developers already use and appreciate styling. It is familiar and useful. It would be lame to create some unique mechanism that hooked up your skins with your components.
• The tool already supports it.
• The code is minimal and added only when used. This means that Flash Pro users can have a mechanism that makes sense for them, instead of both Flex users and FPro users both using something less-elagant for the sake of having the same thing between environments.
• More robust styling solutions can replace the original smaller Flex ones down the road.
• Metadata defaults with a link-in class is actually a bit hackish from the users point of view
• Even though our styling might be hackish under the hood, it looks great from an app builder's perspective.

If we use the built-in Flex styling (or our own version of it rather), we don't have to worry about the metadata defaults, people can easily see how to change out skins, behaviors, etc, and we aren't teaching people some new paradigm or spending a lot of time discussing and implementing the perfect alternative which will just end up being less useful than styling was in the first place.

And finally, if Flex themes work so they only include classes needed on compile, then using the styling mechanism couldn't be easier. App builders won't have to include a small/medium/large include file depending on what components they are using etc.

I strongly urge us to consider using our version of the Flex styling as the default method for Flex. Flash pro will use some other method like component shims that link in their classes.

Jacob

[Tyler Wright]

+1 for Flex-only styling support that's only 2.5kb and optional. Flash Pro workflow is more often custom design, so styling for Flash can come in the future.

I don't like the metadata skinning route either. It would be enough to get us by but I don't like the workflow of always being mindful of commenting out skins you're not using, commenting them in, or dealing with their full weight.

2.5 kb for the entire styling framework with all its flexibility and features, that's the size of databinding, and it's optional. I'm 100% for it.

Tyler

[James Ward]

While I agree that supporting existing workflows and methodologies is
important - and Reflex should support those - I'd like to see us at some
point rethink some of the styling stuff. I've never really liked it in
Flex. Some random thoughts on why...
- Styles are essentially configuration and I'd rather they used a more
conventional method for configuration instead of CSS (why not just use
MXML)?
- Styles in Flex are not easily debuggable.
- I don't like all the many different ways Styles can be set. Seems
very confusing to new users.
- I never liked how we had to decide what was a style and what was just
a property. Some times it's not clear and things get ugly - like with
making top, bottom, etc styles. This creates a lot of confusion.

Well it's much easier for me to critique it than to come up with
something better. But I thought I'd at least share my thoughts.

-James

On Fri, 2009-11-06 at 10:30 -0700, Jacob Wright wrote:
> So I've been thinking about styling, and I think we should have it be
> part of our first release. Here are my reasons:
>
>

> * Flex developers already use and appreciate styling. It is

> familiar and useful. It would be lame to create some unique
> mechanism that hooked up your skins with your components.

> * The tool already supports it.
> * The code is minimal and added only when used. This means that

> Flash Pro users can have a mechanism that makes sense for
> them, instead of both Flex users and FPro users both using
> something less-elagant for the sake of having the same thing
> between environments.

> * More robust styling solutions can replace the original smaller

> Flex ones down the road.

> * Metadata defaults with a link-in class is actually a bit

> hackish from the users point of view

> * Even though our styling might be hackish under the hood, it

[Jacob Wright]

While I agree that supporting existing workflows and methodologies is 

important - and Reflex should support those - I'd like to see us at some 

point rethink some of the styling stuff. 

I'm all for new ideas. I'd be open to an alternative to styling. However, I love styling. It is one of the things I think Flex got right.

 - Styles are essentially configuration and I'd rather they used a more
conventional method for configuration instead of CSS (why not just use
MXML)?

I agree, they are essentially configuration.

 - Styles in Flex are not easily debuggable.
 - I don't like all the many different ways Styles can be set.  Seems
very confusing to new users.
 - I never liked how we had to decide what was a style and what was just
a property.  Some times it's not clear and things get ugly - like with
making top, bottom, etc styles.  This creates a lot of confusion.

These points apply to Flex styling and are valid. If you don't come from an HTML/javascript background it can be confusing why Flex would have styling. If you do have that background, it's frustrating the limited CSS support Flex has.

Even though styling is basically configuration, I find it to be more readable than most configuration formats I've seen. Either you have a very robust, but difficult, XML configuration, or you have a simplistic and limiting INI type format. Styling is more readable like ini formats, but allows for inheritance and cascading, allowing you to style/configure a good deal of things with minimal directives.

The styling solution we have come up with is add-on to the core reflex framework. We would leave it this way. That means, if you don't want to use it, you don't have to. This also means that you won't have to use getStyle and setStyle to do important things such as setting left, top, right, and bottom. The styling we've created sets properties on the components once they are placed on the stage. This keeps it unobtrusive but still allows the flexibility to use styling.

 

Well it's much easier for me to critique it than to come up with
something better.  But I thought I'd at least share my thoughts.

If you do come up with something I'd love to hear about it. Sean Hess created Glue which is an MXML type styling for configuration, though it doesn't seem simpler to me than a stylesheet.

Jacob

[Jacob Wright]

Oh, and I've verified that when using themes in Flash Builder 4, only the styles for components that are used in the app are compiled in. That means, if we can get it working with Reflex like we've done with styling, that only skins and behaviors for the components used will be compiled in. We won't have data grid behaviors in an app with only a button. This was a pain point that we discussed on Skype with some less-elegant work arounds.

Shows another plus for styling: the tools support it.

I'll work on getting theming working once we have some components to actually test it with.

Jacob