Prior to the release of 2008Q2, I used a CSS class to position controls on my page whose appearance was managed using FormDecorator.
At its simplest I might have something like this...
with this in the code behind...
"myClass" might set margins, padding, etc to finely adjust the button on the page.
Since implementing Q2 I can't do this as assigning anything to the CssClass property of my control stops FormDecorator from doing anything with it.
Try it yourself, comment out the assignment to the CssClass property and run the page; you'll have a green button with white text (bog standard 'Hay' skin fare). Recompile the page with the assignment to the button's CssClass and you'll get a standard windows button. This is a major step backwards.
--
Stuart
At its simplest I might have something like this...
| <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="TestBed.WebForm1" %> |
| <%@ Register Assembly="Telerik.Web.UI" Namespace="Telerik.Web.UI" TagPrefix="telerik" %> |
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <html xmlns="http://www.w3.org/1999/xhtml" > |
| <head runat="server"> |
| <title>Untitled Page</title> |
| </head> |
| <body> |
| <form id="form1" runat="server"> |
| <telerik:RadScriptManager ID="ScriptManager" runat="server"> |
| </telerik:RadScriptManager> |
| <telerik:RadFormDecorator ID="FormDecorator" runat="server" Skin="Hay" DecoratedControls="All" /> |
| <asp:Button ID="btnSearch" runat="server" Text="Search" /> |
| </form> |
| </body> |
| </html> |
| protected override void OnInit(EventArgs e) { |
| base.OnInit(e); |
| btnSearch.CssClass = "myClass"; |
| } |
Since implementing Q2 I can't do this as assigning anything to the CssClass property of my control stops FormDecorator from doing anything with it.
Try it yourself, comment out the assignment to the CssClass property and run the page; you'll have a green button with white text (bog standard 'Hay' skin fare). Recompile the page with the assignment to the button's CssClass and you'll get a standard windows button. This is a major step backwards.
--
Stuart
15 Answers, 1 is accepted
0
Dan
Top achievements
Rank 1
Rank 1
answered on 30 Jul 2008, 12:37 PM
I stand (slightly) corrected; it appears this is only true of buttons, other controls seem to be OK.
--
Stuart
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 30 Jul 2008, 12:54 PM
I should prolly point out that in the real world:
--
Stuart
- All RadControls have EnabledEmbeddedSkins set to "false"
- The skin name, used by all RadControls and my pages themselves, is set at runtime from a user configuration file
--
Stuart
0
Dan
Top achievements
Rank 1
Rank 1
answered on 31 Jul 2008, 07:45 AM
Anyone got any thoughts about this one? At all?
--
Stuart
--
Stuart
0
Hi Stuart,
Here is our feedback:
There was a change introduced in Q2, regarding the "conditions" which RadFormDecorator uses to determine whether to style an element or not. Namely, it was decided that if a CssClass/class is specified for an element, it should be skipped by the decorator. There are two reasons for that
- Customer feedback. The logic is simple - RadFormDecorator is aimed to unobtrusively decorate "default" browser elments - and it continues to do so. For elements that are styled, it is often not desired that the decorator would style them as it can easily "mess" them up. That is, styling already styled elements somewhat breaks the idea of semlessness and unobtrusiveness.
- Problems with integration with some of our other complex UI controls, such as RadGrid.
We have gone at great length to try making the styled elements be as close in their layout (e.g. margins/paddings, etc) as the bvrowser ones. So, in your case, perhaps the best way to proceed would be to provide us with exact scenarios why you would need to do extra padding/margins.
One other option for you to achieve the desired effect would be to "extend" the relevant RadFormDecorator css definitons that participate in the styling process and add margins and paddings to those. For example, if we assume that a class that styles a button is called radfd_button, you can extend its definiton by adding extre css settings to your aspx page like that:
.radfd_button
{
/*More settings here*/
}
This does not override the class itself, rather it simply adds to its current definitions.
Sincerely yours,
Tervel
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Here is our feedback:
There was a change introduced in Q2, regarding the "conditions" which RadFormDecorator uses to determine whether to style an element or not. Namely, it was decided that if a CssClass/class is specified for an element, it should be skipped by the decorator. There are two reasons for that
- Customer feedback. The logic is simple - RadFormDecorator is aimed to unobtrusively decorate "default" browser elments - and it continues to do so. For elements that are styled, it is often not desired that the decorator would style them as it can easily "mess" them up. That is, styling already styled elements somewhat breaks the idea of semlessness and unobtrusiveness.
- Problems with integration with some of our other complex UI controls, such as RadGrid.
We have gone at great length to try making the styled elements be as close in their layout (e.g. margins/paddings, etc) as the bvrowser ones. So, in your case, perhaps the best way to proceed would be to provide us with exact scenarios why you would need to do extra padding/margins.
One other option for you to achieve the desired effect would be to "extend" the relevant RadFormDecorator css definitons that participate in the styling process and add margins and paddings to those. For example, if we assume that a class that styles a button is called radfd_button, you can extend its definiton by adding extre css settings to your aspx page like that:
.radfd_button
{
/*More settings here*/
}
This does not override the class itself, rather it simply adds to its current definitions.
Sincerely yours,
Tervel
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 01 Aug 2008, 08:38 AM
Tervel,
Firstly thanks for the info.
Now for the rant.
Did it not occur to anyone at telerik towers that this represents a breaking change? For goodness sake, it didn't even get mentioned in the release notes.
RadControls are not like some piece of application software where we, the punters, get what we're given and have to use it. We use these products to generate product of our own, we invest time and effort trying to make our applications meet our requirements and those of our customers. It seems to me that as suppliers in to this market place you should know and understand this, and that you should also appreciate the consequences of making changes that will break stuff.
Now I'm not saying that we should be consulted about how you guys run your business, or what you do or do not do in terms of the directions your products take. But given the nature of the products I don't think it would hurt to let use know when you've made this kind of design decsion so that we can plan how and what we're going to do about it.
Granted, this particular change is minor but it's one that has affected the way that my application hangs together it is going to require a number of changes, not just to the CSS files but to the way my controls are generated the configuration documentation my clients get.
Please, Tervel, don't imagine that this is a rant at you personally; it's not. I would be grateful if, however, you could draw the attention of whoever it is at telerik towers that you think is most empowered to ensure that we don't, in future, get to find out about these kind of decisions after the event.
--
Stuart
Firstly thanks for the info.
Now for the rant.
Did it not occur to anyone at telerik towers that this represents a breaking change? For goodness sake, it didn't even get mentioned in the release notes.
RadControls are not like some piece of application software where we, the punters, get what we're given and have to use it. We use these products to generate product of our own, we invest time and effort trying to make our applications meet our requirements and those of our customers. It seems to me that as suppliers in to this market place you should know and understand this, and that you should also appreciate the consequences of making changes that will break stuff.
Now I'm not saying that we should be consulted about how you guys run your business, or what you do or do not do in terms of the directions your products take. But given the nature of the products I don't think it would hurt to let use know when you've made this kind of design decsion so that we can plan how and what we're going to do about it.
Granted, this particular change is minor but it's one that has affected the way that my application hangs together it is going to require a number of changes, not just to the CSS files but to the way my controls are generated the configuration documentation my clients get.
Please, Tervel, don't imagine that this is a rant at you personally; it's not. I would be grateful if, however, you could draw the attention of whoever it is at telerik towers that you think is most empowered to ensure that we don't, in future, get to find out about these kind of decisions after the event.
--
Stuart
0
Hi Stuart,
I understand your frustration, and we really do try to change as few things as possible. Introducing breaking changes is at the top of our customers' "don't do this" list - so with the Prometheus/ MS AJAX suite we really thought very carefully when implementing the controls, so that as few changes are made once a control is released. We have put all our existing experience from the RadControls Classic suite into producing rich, flexible yet solid, cross-browser controls.
That said, there are just too many developers out there, using the controls in so many scenarios that it is not possible for a component vendor to anticipate all those. The RadFormDecorator is a new control. What is more - it is unique in what it does and the way it does it. On the Internet there are other approaches that could achieve similar results, but non really comes close to the codeless, seamless experience of RadFormDecorator.
So, it is only logical that changes like that one occasionally happen - and we believe the reason for the change is legitimate. It simply occurred that people wish to have the best of both worlds - e.g. easy, effortless styling of the page, while at the same time preserving [some of] their existing styling.
When requests start coming, we are always trying to accommodate them if valid scenarios are presented. This is how we ended up with this change, and I hope it makes sense, considering the fact that these controls are used by thousands of people with very different requirements and mindsets.
That said, we do take backwards compatibility for the RadControls for ASP.NET AJAX suite very seriously, as we know that such changes are what customers hate the most. I am sure that you, as a long-time Telerik customer, have undoubtedly noticed that RadControl updates and upgrades have become much smoother to handle now. Would you agree with that?
Sincerely yours,
Tervel
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
I understand your frustration, and we really do try to change as few things as possible. Introducing breaking changes is at the top of our customers' "don't do this" list - so with the Prometheus/ MS AJAX suite we really thought very carefully when implementing the controls, so that as few changes are made once a control is released. We have put all our existing experience from the RadControls Classic suite into producing rich, flexible yet solid, cross-browser controls.
That said, there are just too many developers out there, using the controls in so many scenarios that it is not possible for a component vendor to anticipate all those. The RadFormDecorator is a new control. What is more - it is unique in what it does and the way it does it. On the Internet there are other approaches that could achieve similar results, but non really comes close to the codeless, seamless experience of RadFormDecorator.
So, it is only logical that changes like that one occasionally happen - and we believe the reason for the change is legitimate. It simply occurred that people wish to have the best of both worlds - e.g. easy, effortless styling of the page, while at the same time preserving [some of] their existing styling.
When requests start coming, we are always trying to accommodate them if valid scenarios are presented. This is how we ended up with this change, and I hope it makes sense, considering the fact that these controls are used by thousands of people with very different requirements and mindsets.
That said, we do take backwards compatibility for the RadControls for ASP.NET AJAX suite very seriously, as we know that such changes are what customers hate the most. I am sure that you, as a long-time Telerik customer, have undoubtedly noticed that RadControl updates and upgrades have become much smoother to handle now. Would you agree with that?
Sincerely yours,
Tervel
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 01 Aug 2008, 12:59 PM
I
understand your frustration, and we really do try to change as few
things as possible. Introducing breaking changes is at the top of our
customers' "don't do this" list - so with the Prometheus/ MS AJAX suite
we really thought very carefully when implementing the controls, so
that as few changes are made once a control is released
That's all well and good, but the fact is you did change something, something that would have an impact on the way the control was used. Now, I'm not bitching about the fact that you've changed things; after all it's your ball.
What I don't like is that you made this change without notifying anyone. I think that publishing the Release notes in advance of the release would help. And, of course, making sure all of the changes are listed, even if the release notes themselves contained just the 'major' issues with a link to another page for the 'complete' list. This should include: changes to the skins, especially where classes have been added or changed and design space changes.
--
Stuart
That's all well and good, but the fact is you did change something, something that would have an impact on the way the control was used. Now, I'm not bitching about the fact that you've changed things; after all it's your ball.
What I don't like is that you made this change without notifying anyone. I think that publishing the Release notes in advance of the release would help. And, of course, making sure all of the changes are listed, even if the release notes themselves contained just the 'major' issues with a link to another page for the 'complete' list. This should include: changes to the skins, especially where classes have been added or changed and design space changes.
--
Stuart
0
Hi Stuart,
You are making a good point here on publishing two sets of Release notes - one featuring the major changes (as we have been doing up until now), as well as a complete list, featuring all changes made (which would be quite long considering the fact that there are 23 products that get updated).
I will forward your idea to the development and marketing teams for further discussion and consideration.
Best wishes,
Tervel
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
You are making a good point here on publishing two sets of Release notes - one featuring the major changes (as we have been doing up until now), as well as a complete list, featuring all changes made (which would be quite long considering the fact that there are 23 products that get updated).
I will forward your idea to the development and marketing teams for further discussion and consideration.
Best wishes,
Tervel
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 01 Aug 2008, 01:36 PM
You
are making a good point here on publishing two sets of Release notes -
one featuring the major changes (as we have been doing up until now),
This is the one that, I'm sure, you marketing people will want to concentrate on
as well as a complete list, featuring all changes made (which would be quite long considering the fact that there are 23 products that get updated).
This is the one that'll be of real use to those of us getting our hands dirty on a daily basis. To be the useful resource I envision it being, though, requires that everyone play; not just the guys writing the control's functionality, but the visual design surfaces guys and those responsible for skins and documentation too.
I will forward your idea to the development and marketing teams for further discussion and consideration.
Good news indeed.
I look forward to hearing the responses of those you pass this suggestion to.
--
Stuart
This is the one that, I'm sure, you marketing people will want to concentrate on
as well as a complete list, featuring all changes made (which would be quite long considering the fact that there are 23 products that get updated).
This is the one that'll be of real use to those of us getting our hands dirty on a daily basis. To be the useful resource I envision it being, though, requires that everyone play; not just the guys writing the control's functionality, but the visual design surfaces guys and those responsible for skins and documentation too.
I will forward your idea to the development and marketing teams for further discussion and consideration.
Good news indeed.
I look forward to hearing the responses of those you pass this suggestion to.
--
Stuart
0
Sure thing Stuart,
Once we come up with a decision, I will post in this thread.
Kind regards,
Georgi Tunev
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Once we come up with a decision, I will post in this thread.
Kind regards,
Georgi Tunev
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Dan
Top achievements
Rank 1
Rank 1
answered on 04 Aug 2008, 12:55 PM
Georgi,
I'd appreciate it.
--
Stuart
I'd appreciate it.
--
Stuart
0
Steve Y
Top achievements
Rank 2
Rank 2
answered on 14 Feb 2009, 04:16 PM
Hi Guys,
I just bumped into the same issue of class effectively disabling radformdecorator on a control.
I was using a <fieldset> with a <legend>. When RadFormDecorator decorates this control using Office2007 skin, it adds height and line-height of 30px to the legend text - which is really large. When it decorates the control, it shifts the whole display down because of the height difference between a standard fieldset/lgend and the newly decorated one.
In addition to the differences, I wanted to change the text size, weight and color for the legend and add some margin and padding to the fieldset. My tinkering with various settings led me to lay out my code like this:
So I now have a non-decorated control behaving the way I want, but without the nice rounded corners and color on the drawn box, and, when I decorate it with Office2007 skin, it looks great and doesn't have the shift issue I experienced before.
I have at least 20 of these <fieldset> places to put into my application so the natural thing to do is put all the style info into my standard css file and use a class.
and:
This is where I went wrong I guess and I then spent over half a (precious) day trying to work out what I had done wrong. Eventually I found this post which explained why my changes were no longer being accepted by RadFormDecorator. So. I out everything back, wrote out all the styles in longhand in all my 20 fieldsets dotted around my application and it now all works.
However, I'm not happy for a few reasons.
It seems to me, there are two schools of thought on the issue of whether to decorate controls with a class attached. The first says if a control has a class then please don't touch it as I know what I'm doing and I want to override it. The second says I want to tweak the style but please decorate it anyway because I know what I'm doing.
The developers decided to make a breaking change and switch from the second to the first camp. Unlike Stuart, I did not experience the actual breaking change here but I've certainly stumbled across the issue.
I think there's something that could help me and other developers in the future and something that could have helped make a potential breaking change a non issue, because I can see both sides of the coin. i.e. do decorate it if there's a class associated with the control because I know what I'm doing; and don't decorate it because there's a class associated with the control and I know what I'm doing.
I propose a switch on RadFormDecorator that says something like. <RadFormDecorator DecorateControlsWithClass="true" (or "false"). In the future, everyone wins and, it would have saved a breaking change irritating customers like Stuart in the past. Given there would be a specific option for RadFormDecorator to do with classes, developers like me would see this and know what to do without having to stumble around trying to solve a coding issue that was not obvious.
Thanks for listening.
Steve
I just bumped into the same issue of class effectively disabling radformdecorator on a control.
I was using a <fieldset> with a <legend>. When RadFormDecorator decorates this control using Office2007 skin, it adds height and line-height of 30px to the legend text - which is really large. When it decorates the control, it shifts the whole display down because of the height difference between a standard fieldset/lgend and the newly decorated one.
In addition to the differences, I wanted to change the text size, weight and color for the legend and add some margin and padding to the fieldset. My tinkering with various settings led me to lay out my code like this:
| <fieldset style="margin:4px; padding-bottom:6px;"> |
| <legend style="color:#778899; font-size:11px; font-weight:bold; line-height:normal; height:12px;">Property Location</legend> |
So I now have a non-decorated control behaving the way I want, but without the nice rounded corners and color on the drawn box, and, when I decorate it with Office2007 skin, it looks great and doesn't have the shift issue I experienced before.
I have at least 20 of these <fieldset> places to put into my application so the natural thing to do is put all the style info into my standard css file and use a class.
| .EditPanelFieldset |
| { |
| margin:4px; |
| padding-bottom:6px; |
| } |
| .EditPanelLegend |
| { |
| color:#778899; /*LightSlateGray*/ |
| font-size:11px; |
| font-weight:bold; |
| line-height:normal; |
| height:12px; |
| } |
and:
| <fieldset class="EditPanelFieldset"> |
| <legend class="EditPanelLegend">Property Location</legend> |
This is where I went wrong I guess and I then spent over half a (precious) day trying to work out what I had done wrong. Eventually I found this post which explained why my changes were no longer being accepted by RadFormDecorator. So. I out everything back, wrote out all the styles in longhand in all my 20 fieldsets dotted around my application and it now all works.
However, I'm not happy for a few reasons.
- I don't like (nor is it considered good coding practice) having styles dotted around many source files. It makes it very hard to make changes if my customers want it changed.
- If RadFormDecorator skin office2007 or the way it styles the control changes in the future, I have 20+ places in my code I need to change to keep it consistent. Now we've already established that RadFormDecorator makes beaking changes...
- I wasted over half a day trying to work this out. I could not find references in the documentation to help me (ok, I didn't spend a lot of time looking there but I didn't expect this as an issue). The only place I found anything was in this forum.
It seems to me, there are two schools of thought on the issue of whether to decorate controls with a class attached. The first says if a control has a class then please don't touch it as I know what I'm doing and I want to override it. The second says I want to tweak the style but please decorate it anyway because I know what I'm doing.
The developers decided to make a breaking change and switch from the second to the first camp. Unlike Stuart, I did not experience the actual breaking change here but I've certainly stumbled across the issue.
I think there's something that could help me and other developers in the future and something that could have helped make a potential breaking change a non issue, because I can see both sides of the coin. i.e. do decorate it if there's a class associated with the control because I know what I'm doing; and don't decorate it because there's a class associated with the control and I know what I'm doing.
I propose a switch on RadFormDecorator that says something like. <RadFormDecorator DecorateControlsWithClass="true" (or "false"). In the future, everyone wins and, it would have saved a breaking change irritating customers like Stuart in the past. Given there would be a specific option for RadFormDecorator to do with classes, developers like me would see this and know what to do without having to stumble around trying to solve a coding issue that was not obvious.
Thanks for listening.
Steve
0
Hello Steve,
Thank you for the feedback - I logged it for future consideration. For the time being however, we are not planning to add such property. One of the main ideas behind the decorator control is that it should not interfere with custom styles - this is the reason why it does not decorate controls that have the class property. In such scenario we assume that the developer wants to have a custom style over that element and we do not change it in any way.
This logic may change in the future but please note that applying custom styling over previously styled controls and providing a consistent cross-browser output is not an easy task - there can be virtually anything in such custom style.
Kind regards,
Georgi Tunev
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
Thank you for the feedback - I logged it for future consideration. For the time being however, we are not planning to add such property. One of the main ideas behind the decorator control is that it should not interfere with custom styles - this is the reason why it does not decorate controls that have the class property. In such scenario we assume that the developer wants to have a custom style over that element and we do not change it in any way.
This logic may change in the future but please note that applying custom styling over previously styled controls and providing a consistent cross-browser output is not an easy task - there can be virtually anything in such custom style.
Kind regards,
Georgi Tunev
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
0
Steve Y
Top achievements
Rank 2
Rank 2
answered on 16 Feb 2009, 01:15 PM
George,
Thanks for your reply. Your points are reasonable and valid. However, you are making my point for me. Let me explain. You wrote...
One of the main ideas behind the decorator control is that it should not interfere with custom styles - this is the reason why it does not decorate controls that have the class property. In such scenario we assume that the developer wants to have a custom style over that element and we do not change it in any way.
This is a good assumption - as long as it is right ! In my case, it is a wrong assumption. I want to make a few changes/minor tweaks to a 'styled' control. I can do that with some inline style coding. This is perfectly fine. I have done that and it does what I want. Now I want to make those same changes in many other places in my application. The best way to do that is to place the style commands in a css file and apply them using a class. And this is where the assumptions fall apart.
That's why I propose a switch within the control which says - I know what I' trying to do. Please don't make assumptions. I want to have controls that has a class, styled anyway.
Or if it's switched the other way, it'll say - I know what I'm doing. I have classes associated with some of my controls, and, if I do, please do not format them.
Thanks and regards,
Steve
Thanks for your reply. Your points are reasonable and valid. However, you are making my point for me. Let me explain. You wrote...
One of the main ideas behind the decorator control is that it should not interfere with custom styles - this is the reason why it does not decorate controls that have the class property. In such scenario we assume that the developer wants to have a custom style over that element and we do not change it in any way.
This is a good assumption - as long as it is right ! In my case, it is a wrong assumption. I want to make a few changes/minor tweaks to a 'styled' control. I can do that with some inline style coding. This is perfectly fine. I have done that and it does what I want. Now I want to make those same changes in many other places in my application. The best way to do that is to place the style commands in a css file and apply them using a class. And this is where the assumptions fall apart.
That's why I propose a switch within the control which says - I know what I' trying to do. Please don't make assumptions. I want to have controls that has a class, styled anyway.
Or if it's switched the other way, it'll say - I know what I'm doing. I have classes associated with some of my controls, and, if I do, please do not format them.
Thanks and regards,
Steve
0
Hello Steve,
Thank you for your feedback. In fact, I believe it will soon be possible to "have the best of two worlds". Based on various feedback (such as yours) as well as considering various alternative approaches for further improvement of the control, we designed a new approach to the decoration mechanism that will rely much more extensively on using CSS inheritance propagation from the parent BODY/Decoration zone to its children. Hence, soon decorated controls will be able to pick up their styling from the parent, AND keep their current styling - in the manner that the developer styled them.
We will do our best to change a number of the decorated controls to take advantage of this new, much faster and more powerful approach for the official Q1 2009 release scheduled for March 10th. At this point, however, I am not able to confirm whether the whole decoration mechanism will be reworked by then (there are a number of challenges related to IE6 as well as, in some cases IE7 - which will require the use of code).
The new approach will also solve the current problem with "flickering" when a decorated zone is re-decorated after its content was changed during AJAX request.
Thank you once more for providing your suggestions, they have proven very helpful in making Telerik products better and more attending to the developers' needs.
All the best,
Tervel
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.
Thank you for your feedback. In fact, I believe it will soon be possible to "have the best of two worlds". Based on various feedback (such as yours) as well as considering various alternative approaches for further improvement of the control, we designed a new approach to the decoration mechanism that will rely much more extensively on using CSS inheritance propagation from the parent BODY/Decoration zone to its children. Hence, soon decorated controls will be able to pick up their styling from the parent, AND keep their current styling - in the manner that the developer styled them.
We will do our best to change a number of the decorated controls to take advantage of this new, much faster and more powerful approach for the official Q1 2009 release scheduled for March 10th. At this point, however, I am not able to confirm whether the whole decoration mechanism will be reworked by then (there are a number of challenges related to IE6 as well as, in some cases IE7 - which will require the use of code).
The new approach will also solve the current problem with "flickering" when a decorated zone is re-decorated after its content was changed during AJAX request.
Thank you once more for providing your suggestions, they have proven very helpful in making Telerik products better and more attending to the developers' needs.
All the best,
Tervel
the Telerik team
Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.