Hello List,

Can someone tell me the big advantage of theme over css? Is there a major thing theme can do but css?
Currently skin do not support design time editor. will it support in the final release?

Thanks in advance,

Themes employ the use of CSS pages. They also utilize .skin files. These two approaches seem to conflict somewhat, but I'd suggest using CSS as much as possible. .skin files are useful for either 1) setting default properties of complex controls like Calendar. It's hard to reverse engineer how the Calendar renders to know how to work a CSS to fit, or 2) Where the complex control does support CssClass properties, it allows easy default setting of those properties. The GridView has on the HeaderStyle a CssClass property, so instead of having inline styes everywhere for your grid, you can now just set the CSS class (which will be defined in the Theme's CSS file, of course).

-Brock

Here are the major advantage of Theme over css

Theme is a collection of control styles applied to webcontrols on website.
User will write asp.net controls in the skin file instaed of html and take the advantage of styles features of asp.net controls
It gives the common looks and feel to all webcontols in a simple way.
Its allows to abstract the styles so that it can be reused.
Using skinId you can apply different skin to differnt controls
User can granularly specify at contorl level that if a style should be applied to a perticualt webcontrol or not by using EnableTheming = "true/false"
User can difine the order in which styles applied to the page. eg style defined in StyleSheetTheme will be overridden by the page and style defined in the page will be overridden by the Theme.
Themes also have support for css
and the list will go ooon

Theme doesnt work at Design Time but StyleSheetTheme works

For more details about Themes please see - http://weblogs.asp.net/vimodi/articles/ThemesFaqs.aspx   

HTH,
Vishal

vimodi wrote:

Here are the major advantage of Theme over css

I assume you're talking about skin files, over CSS used in a Theme. If so....

vimodi wrote:

User will write asp.net controls in the skin file instaed of html ...

The same approach is taken for CSS. I don't see how this is an advantage over CSS.

vimodi wrote:

... and take the advantage of styles features of asp.net controls

The downside of this is a bloated page since those styles are all embedded inline in the rendered tags.

vimodi wrote:

It gives the common looks and feel to all webcontols in a simple way.

I suppose the key word here is simple. Perhaps server control properties are simpler than CSS. But there's a price for this (my point from above).

vimodi wrote:

Its allows to abstract the styles so that it can be reused. Using skinId you can apply different skin to differnt controls User can granularly specify at contorl level that if a style should be applied to a perticualt webcontrol or not by using EnableTheming = "true/false" User can difine the order in which styles applied to the page. eg style defined in StyleSheetTheme will be overridden by the page and style defined in the page will be overridden by the Theme.

I don't see why this can't also be done for CSS classes.

Anyway, this is just meant to be a "counter-point" post. Personally CSS for ms is lighter weight and it's not too complex. If you're building pages for the web, at some point you're going to have to deal with CSS.

As I suggested above, I like to use skin files to set the CssClass property. That way, for my entire app the class property is set in a single location. The actual CSS then controls those styles.

-Brock

Some other comments.

Themes can be applied in 2 ways, as customizations or "stylesheet" forms which support two potential scenarios:

Customization of a site, post development (theme="mytheme"). Any theme applied in this manner overrides the control itself and therefore means that if controlled through a config entry can be used to affect the site simply This is regarded as a non-development scenario and themes applied like this are not supported in the designer

Stylesheet themes, during development (stylesheettheme="mytheme"). A theme applied in this manner is applied to the control before it's declarative property sets, and allows for the same logical abstraction of let's say, styles, like CSS into a form that can be repeatedly consumed. Then, like CSS, the control's property sets 'being most local', override that defined through the theme. Note that this form of themeing IS supported in the designer.

It is true that like server controls, style property sets will result in an in-line style, so the skin/theme also will result in the same and ptentially increase the payload. The skin/them though is not necessarily bound to stylistic propeties, it can be used for template definitions (hence contrent), and collections too (hence content). In fact it is the control that effectively defines properties that arre themeable.

Since themes can be a collection of skin files (controls propetrty sets),  but also other resources, like CSS files, images etc (since they can be applied as a property set), the theme gives a good logical grouping of the factors that a developer might want to use to apply look and feel to a site, in both manners described above.

Strongly-typed properties, which of course give good programmability in the control sense, do abstract the page developer from requiring good knowledge of CSS. Similarly, the related attribute properties in the declaration of a control also simplify development. However, there are great arguments for using cssclass definitions too.

Of note I think also, are the manners in which you can programmatically select themes and skins(customization themes), during a framework lifecycle, rather than having to cope with potential cssClass changes, or even linked .css file changes. Even if you set up a theme to be a folder with a CSS defining known css classes, then simply selecting the theme means that the framework will add the css reference to the response/rendered page and rebase the url to that css for the page.

Ultimately, it comes down to a combination of what are the skill-sets, requirements for payload, development paradigms and scenarios that you are trying to achieve.