42 Comments

• Nathan Pledger 23 Feb 2009
  Thank god we haven't got to allowing users to define their skins in our development yet, then! (A pretty bold step to offer to refactor your customer's skins, though!)

  
  

  This looks very exciting for us, as I was worried about how easy it would be to develop new skins. And with the new [designer tool], our [designer person] will be able to get into it quicker. Will this tool be released with the Q1 release?

  
  
• PureCode 23 Feb 2009
  Oh dear.. We have at least 12 custom skins.. and two more in development..
  
  Bad news this, very bad news..
  
  While the "Change skin, keep the layout' was the first thing i commented about on the forums when that Skin Manager control was introduced, because of the major inconsistencies within each of the embedded skins, this same issue also 'forced' us to roll our own some time early 2008, because we HAVE to over various skins for our framework(s), high contrast, etc sorta stuff.
  
  I cannot see Telerik rebuilding 12+ skins for us while we haven't even purchased the suite yet (framework is still in development, we still haven't settled on a suite to use, and i am not buying three suites just for development when we will end up picking one out of the three for the final product, in the industry we serve, our customers are huge, but we're a small outfit.).
  
  Besides that, png format? Bye bye backwards compatibility to older browsers, that alone makes Telerik Q1 2009 entirely useless for us. We are forced to support all the way down to IE4 (albeit that not everything works on those browsers, but custom code has fixed much of that) and even sillier browsers of the olden days (Netscape anyone?).
  
  Both things considered, i have to admit that i may have to 'shelf' the Telerik based version of the framework entirely and stick to the other two suites, even though the Telerik one, despite MAJOR workarounds, seems to perform the best.
  
  I am not a happy man.
  
  Regards,
  
  Mike
  
• PureCode 23 Feb 2009
  I guess i should state the reasoning behind my 'anti-PNG' stance a little.
  
  Simple example, Internet Explorer for Windows did not support 'full alpha' for PNG until version 7.0. Sure, IE6, IE5.5 and IE5 support PNG, but with MAJOR issues.
  
  A little list:
  
  Broken alpha support in earlier versions, inconsistent/broken gamma support, no ICC-profile (iCCP) support, no color-correction support, progressive display of interlaced images, broken OBJECT support in version 4.x, version 4.0 crashes on large PNG chunks, version 5.0 prints palette images with very dark background under Win98, as well as destroys coloring sometimes, some times fails to display PNG images used as CSS backgrounds (!!!), fails to display PNG images of 4097 or 4098 bytes in size, sometimes completely loses ability to display PNG images. Oh, and do note that IE5+ (the only IE versions to support PNG under MacOS/OSX) has its own, unique issues.
  
  Microsoft even states that IE4 doesn't support PNG (unless a third party ActiveX control is used, which does a crappy job).
  
  This is just Internet Explorer and i am sure these are hardly ALL the issues. You don't even want to SEE the list for Netscape and even a relatively newer browser like FireFox had versions with issues. Opera didn't get full support until version 6.0, with previous versions having some very odd issues, 4.x and 5.x going so far as to segfault under Linux. Safari states "full support for all versions", but adds the interesting note that "PNG behaves differently depending on the host OS", whatever THAT may mean.
  
  These are just a few browsers, there are MANY more browsers out there and it is impossible for us to garantuee a customer that our software will actually work across ALL versions of IE, FireFox, Netscape, Safari, etc. GIF does allow us to garantuee this. In the end, not being able to garantuee compatibility (especially on the presentation side of an application, that what my clients customers SEE), can and WILL cost me sales. Worse yet, an application screws up entirely under some obscure browser and my customer looses a (big) customer, meaning that i loose a customer as well.
  
  Obviously, the risk is too great for a small outfit like mine, PNG support is extremely inconsistent across browsers, and i much prefer inconsistent skin layout over inconsistent rendering within browsers.
  
  Regards,
  
  Mike
  
• Mike C 23 Feb 2009
  Transparent PNGs do not work properly in MSIE 6, which is a Web browser I am required to support. PNGs are also usually larger than GIFs without adding much benefit. Switching from gifs to PNGs would be a step backwards and might even force me to reevaluate the other competing libraries since compatiblity with older browsers is essential.
  
• Alexander Gyoshev 24 Feb 2009
  Err... Guys, the post omitted that it's PNG8 that is replacing the GIFs. I see that you went through a load of docs to come up with all these statistics, but they are for PNG24. Consider the following read: PNG8 - the clear winner, and watching the following presentation on PNG8 (from a fellow bulgarian at Yahoo! Exceptional Performance team).
  
  IE6 will be supported, as always. Why should we dump its support? We know that you need to support it! Why should we turn our back on you when we already support it :-) We've halved the image sizes and sprite'd the images. I'm talking about a huge gain in client-side performance, and no losses.
  
  And for versions prior to IE6, well, PNG8s are supported (as seen in the sitepoint article).
  
• Olivier Vanbiervliet 24 Feb 2009
  I'm really looking forward to this, even if this means I have to rewrite a lot of stuff.

  
  

  That's what progress is about...
• Tervel 24 Feb 2009
  Re: Mike / PureCode
  
  I can see that you are very concerned about PNG support - but I think most of the information you posted is not relevant to what we have done with the skins.
  Did you have the chance to check the WebMail demo in IE6 and lower?
  If you have not done it yet, please have a look and see how things look like.
  
• Shocked 24 Feb 2009
  @PureCode - man, I think you are in BIG SH*T if you really have to support IE4 (and even IE5). What was that... Windows 95?!?!? :-D :-D :-D
  
• Nick 24 Feb 2009
  I agree Any client wanting IE4 Support is one to stay clear of! - i would hazard a guess most websites/Web applications out there wont fully support IE4 - and i would be surprised if any component vendor would guarantee  there products working with it either!
  
• Amir Geri 24 Feb 2009
  The new face lift is good and all, but is the right to left compatability is fixed in those skins?

  Many CSS skins were screwed up once i put them in rtl mode...
• Anders M. 24 Feb 2009

  So the new default is the "new new default" - it's gray and not black as the "new default" was. But where is has the black default skin gone then? Am I missing something here?

• Grady Werner 24 Feb 2009
  I like that we're moving to PNG8, but there's a more pressing issue for me.
  
  The editor dialog ascx files need MAJOR clean-up in order to be styled properly and standards compliant.  Almost all of them use inline styles and absolute pixel widths instead of using CSS to define them.  The code is improperly formatted, and there's even syntax errors in some of the HTML.  For example, there are places in the file managers where the HTML gets rendered like this (from memory, so may not be exact):
  
  <table>
  <div style='top: -20px; width: 694px;'>Address bar</div>
  <tr><td>........
  
  Just terrible....
  
  For the love of Pete, please have an upper level programmer take a look at those dialogs and clean them up. 
• Not Again 24 Feb 2009
  Sigh...  Not again.  I just finished upgrading our skins from the previous version to the ajax version.  Now it seems I have to do it again.  It took me two weeks.
  
  Who can I bill at Telerik for the next two weeks I have to spend on this?
  
• Ken 24 Feb 2009

  I work in a custom and dynamic .NET code environment.  And yes I did say Custom.  I have been using Telerik controls in LIVE Production for the last 5 years.  I have NEVER been disappointed with a new upgrade. 
  
  I just upgraded a project that has 120,000 lines of code with 9 Telerik controls with 4 custom skins.  It took us less than a day to have the new controls upgraded and running bug free.  There may be upgrade challenges, new code to write, and yes even a few standards to change.  However, the end result has ALWAYS been a cleaner, better performing product.  No other suite offers the wide range of support and products that Telerik offers. 
  
  I learned a while back that you cannot write code for 10 year operating systems and browsers.  You should have a level of expectation that users can, should and if necessary be held to update their software and OS to modern standards. After all it does not cost them a dime to update their OS through Microsoft. Writing for IE4 is just nuts.
  
  And to my friend Mike...You should buy the controls.  There is no better support for controls than the Telerik Team.  And no, I do not work for Telerik.  Just a really big FAN!
  
  To the Telerik Team, Bravo,  well done.  Look forward to Q109.
  
  Best Regards,
  Ken Weatherford
  .Net Developer

• PureCode 24 Feb 2009
  Re: Tervel,
  
  Yeah, i just did check, with just FireFox 3 and IE7.
  
  Have a look at this.
  
  Seems to me that you guys have a few more issues than just PNG files. Layout is clearly not consistent across the two most popular browsers, worse some controls are drawn differently, the 'Date' drop down being the major example since it is drawn two pixels taller under FF3 and very visibly has the text offsetting wrong because of it.
  
  There is also a missing image in FF3 (even after several reloads and a few time of clearing of the cache).
  
  Since i had to re size the browsers to get the screen shots of them, i am assuming that this causes some of the issues i outlined in the comparison image, but still, they do not have a consistent layout, worse, it is quite visible that they are different. That missing image is obviously an issue as well as the sizing of the 'Date' drop down. The biggest hit on the layout is the vastly differing sizing of the grid columns/rows.
  
  One interesting detail is that the IE7 image has 67 less colors than the FF3 image (2325 over 2392). Another interesting detail is that with the browsers at exactly the same size (no toolbars/tabbar/etc), the FF3 image is 1 pixel less high than IE7 (i double-checked this by loading the web mail demo in FF3 normally as well as in an IETab under FF3, still 1 pixel height difference).
  
  This, however, kinda scared me, albeit that you guys have a lot of stuff on a 'single' page there:
  
  Total size: 1432.5K
  Requests: 61
  
  Also, while the page itself runs in IE6 Standard Mode, there are five IFRAMEs that are running in IE5 Quirks Mode.
  
  YSlow kindly gives 'Default.aspx' of the demo an F (53) for a performance grade. It is kind of silly to see you guys all enthousiastic about compression all over your website and blogs, yet your latest demo, showcasing the latest of your work, doesn't compress 19 of its components (mostly "http://demos.telerik.com/webmail/WebResource.axd?d=..." components). It seems you also forgot to use your style sheet combining control, since the page loads no less than 18 external style sheets. No less than 17 of these external style sheets are outside the page header as well. One single, over a megabyte in size, javascript file is not minify'd, possibly the combined scripts used on the page?
  
  If i pull YSlow over the good old CRM Application Demo, there are a few interesting differences. The CRM Application demo is MUCH smaller, about a megabyte or so and does not combine javascript files, yet it gets the performance grade of F (47).
  
  In practice, the CRM Application loads and functions a LOT faster than the new Web Mail Demo, which is downright slow in loading and functioning (we're on a 20mbps line here, not exactly 'slow' by any means).
  
  While i stick with my stance on using the PNG format (albeit that i will have someone do some testing with PNG8), and at the same time i am very much into making an application look 'good', i am still questioning whether or not you guys are concentrating on the right issues here. Skinning would be the last thing on my list if my product comes back from performance testing like both the Web Mail and CRM demos do, with the side note that the CRM demo is lightning fast here, while the Web Mail demo is extremely slow comparatively. At the same time, the 'consistent layout' bit is obviously incorrect and is also well above skinning in priority (especially the control rendering). Of course, there is no layout without skinning in this case, but i think you understand the point.
  
  This was just two browsers, if you really want, i can pull this through a large number of different browsers and different browsers versions, including ones you probably never even heard of, but if the two main browsers in the world are already this 'inconsistent' (i can look past most of the differences, but the control rendering differences, missing image and vastly different grid layout are definitely a major issue IMHO) with the presentation, it is probably just pointless to do, i think we can guess the results quite accurately.
  
  Regards,
  
  Mike
• PureCode 24 Feb 2009
  Tervel,
  
  I will add that during a quickish test with PNG8 vs GIF, we still see erratic behavior of the PNG8 images.
  
  We did two tests.
  
  We turned an image with semi-transparency (eg, PNG32) into a PNG8 using Fireworks, which resulted in a semi-transparent PNG8 (not normally the case since PNG8 is pretty much exactly the same as GIF and is supposed to be 1-bit transparency). This worked fine under IE7 and FF3, however, under IE6, IE5.5, IE5, and IE4 the semi-transparency was ignored so far that it didn't even draw, it did however retain the 1-bit transparency we'd set up.
  
  We took one of our GIF files, turned it into a 1-bit transparency PNG8 using Photoshop. Filesize remained pretty much the same, and the 1-bit transparency works all the way down to IE4 without issues (as expected).
  
  So, the question here is.. why?
  
  We pumped a few more GIF/PNG32/JPG files through Photoshop and converted to PNG8, the high color images started looking as 'crap' as the same files converted to GIF, the file sizes remained pretty much the same between high-color images converted to GIF and PNG8, both have their 1-bit transparency.
  
  I fail to see any gain here by switching to PNG8 over GIF. Only 'gain' i see is that it works as PNG within IE4 (without semi-transparency), but so do GIFs.
  
  The advantage of PNG is the high color combined with semi-transparency capabilities, which means PNG32, and returns us right to square one. GIF/PNG8, who cares?
  
  Regards,
  
  Mike
• PureCode 24 Feb 2009
  To clarify,
  
  I have no issue with PNG8 over GIF in skins, albeit that it seems unnecessary to convert, but i do have 12+ skins that need to be entirely redone, and that takes time (especially since the style editor is now several months away? didn't i read something about a beta of sorts at the end of february?). and taken time, means money, a lot of it.
  
  That's besides the bigger issue that showed up, the layout still being inconsistent.
  
  Regards,
  
  Mike
  
• Todd 24 Feb 2009
  Hey Mike-
  
  Thanks for all the testing and feedback! We definitely feel your pain and we are always very, very reluctant to ever make changes that break existing apps. That said, sometimes changes are better for long term support (just look at the baggage Windows is carrying) and this change is falls in to that category. Our goal is to provide as much help and support as we can to ease the pain of the transition.
  
  Let me underscore a few important points that may help:
  
  - Telerik is willing to covert all of your custom skins. Really. Just create a project (or page) that has all of the RadControls that you use with your custom skin applied and send it to us in a support ticket. We'll do all the conversion work for you. Hopefully that will help save you a lot of time and show you how serious we are about support (and maybe help you make your decision to pick a toolset...).
  
  - PNG8 is really a superior format for the web than GIF. I'm a long, long time web developer and I switched to PNG8 about 3 or so years ago because it produces images that have better quality than GIF at (usually) equal or smaller sizes. I suppose it's a matter of opinion, but let's leave that argument to other forums on the Interwebs. :)
  
  - If you check the "official" Telerik browser support page, you'll see that the RadControls are designed to work with IE 6+ (as in the case for all major UI component vendors). I know sometimes you have no control over tough client environments, but hopefully this won't be a showstopper for you:
  http://www.telerik.com/products/aspnet-ajax/resources/browser-support.aspx
  
  - Finally, to the concerns you had about the size of the Web Mail demo. I agree completely. We need to do a better job optimizing this code. There is a lot we can do with Telerik's own tools, such as using the RadScriptManager and StyleSheetManager to reduce requests and we'll try to do this for the final Q1 release. The primary goal of the beta demo is to show you how consistent the new skins are. Clearly, a few beta issues remain, but hopefully that doesn't obscure the overall progress we've made.
  
  Hope that helps, Mike. I want reiterate that we appreciate your feedback and will use it to make our tools and demos even better. For now, send us your skins and we'll start getting them converted for Q1!
  
  -Todd
  Microsoft MVP
  Telerik Chief Evangelist
  
  
  
• Tervel 25 Feb 2009
  Re: PureCode
  I would also like to thank for the extensive feedback. The skin rework is a major effort to bring the consistency and the overall layout quality of the controls at a qualitatively new level. As Todd noted, the WebMail demo is by no means finalized - and its major goal now was to preview the skins as well as how much easier it is to create a nice looking complex interface.
  
  We are still making small adjustments to the sizes of some elements, and we appreciate your pointing several of these remaining little differences. One point here - in your screenshot you mention "Scroll bars have no skins" - perhaps implying that they should. This is not the case. Scrollbars can be skinned in IE only, and this demo does not do this (at this point).
  
  =====================================================
  Re: all concerned with customs skins
  As I said in the blog post itself about custom skins - if your skin breaks, we will fix it for you. All you need to do is, once the release comes out, send us a sample running project with your skin(s), the way it/they worked with the previous version. Whether it is one skin or twelve, and whether you are already a Telerik customer or still evaluating - we will covnert those skins for you, so that you don't have to.
  
  =====================================================
  Re: Amir Geri
  Amir, I think it is a good idea for us to provide a RTL version of the WebMail demo as well :) I will add this to our TODO list. With time there has been tremendous progress with RTL support - hence I am not sure about which controls and which Q release you are referring to. I invite you, however, to take a look at the current BETA's RTL examples and/or give the BETA a run in your own project, and if you encounter issues - please open a support ticket and send us some screenshots. We will do our best to correct those for the official release.
  
  =====================================================
  Re: which control's css have been changes, and which controls stay the same (needed to determine what chances there are for your skin to break):
  
  CSS convetions changed
  ------------------------
  ColorPicker
  Editor
  FormDecorator
  Grid
  Rotator
  Slider
  Spell
  Splitter
  Window
  ToolTip
  
  Not changed
  ---------------
  Ajax
  Dock
  Calendar
  ComboBox
  Input
  Menu
  PanelBar
  Scheduler
  TabStrip
  ToolBar
  TreeView
  Upload
  
• Tervel 25 Feb 2009
  Re: Grady Werner
  
  Grady, the FileManager dialogs of RadEditor now use the new control RadFileExplorer.
  In the last one year there has been a number of other important changes in the dialogs rendering and implementation. The original approach taken was thoroughly revised, because while in theory it was the most flexible, in practice there was enormous price to pay for this capability. One example - the original skin-specific CSS for the dialogs was 3000+ lines, while right now it is down to 30. That is a hundred-fold reduction in styling effort. True, it is due to a large extent of bringing more and more RadControls that take care of their own skinning into the dialogs (e.g. RadTabStrip, the RadFileExplorer, RadSlider and most important of all RadFormDecorator).
  
  It is very easy to get an idea of what the dialogs look like, by opening a demo page with the editor, popping a dialog and giving it a quick check using FireBug or IE DevToolBar. I will be happy to comment on any *strange* findings that you encounter in the BETA.
  
• Alexander Gyoshev 25 Feb 2009
  Re: PureCode
  
  Thanks for the YSlow review of the Web Mail Demo :-) The stylesheet combining was disabled due to a Chrome bug (triggered by our CSS :-( ), which we didn't catch in time for the beta. It's all resolved now and the combining is on (meaning we've halved the loading time in half given the change in HTTP requests).
  
  Now, regarding the PNG8 vs GIF drama: the presentation I linked to showed real results, by people who work at Yahoo. Even Google use PNGs as a standard - and I believe they have the most agressive performance strategy in the world. Furthermore, our images are currently not crushed. With Q1, they will be, squeezing them even further - right now they are half the size of their GIF siblings.
  
  If you really need to be convinced even further, I will provide actual images from the assembly.
  
• Chris Metzl 25 Feb 2009
  Question about some of your JS files...I've noticed a lot of js.aspx.  Is that for some kind of compression?  Or are you putting server tags in your external JS files?
  
• PureCode 25 Feb 2009
  Re: Tervel, Todd, and Alexander,
  
  Thanks for all the feedback regarding my 'fears'. I'll just update you guys a little on the integration of the Q1 2009 BETA into our framework, as well as the results of our VERY extensive testing of PNG8 (with thanks to a few of our customers who were willing to let us use expensive cpu time on their 'somewhat larger' systems).
  
  As expected the framework blew right up, but with the side-note that it was less bad than we expected, it seems 99% of our custom skinning seems to work just fine.
  
  We have made massive amounts of custom code that inherits (sometimes very 'hacked' inheritance, sadly.. good example is adding the ability for font sizing within your combo box, pretty nasty hack that we will need to revisit, one of my developers actually called your combo box 'disastrously flawed', bit harsh, but it does lack some features and it is highly inconsistent, resulting in it being a pain to work with) from the Telerik assemblies. You probably wouldn't recognize your grid anymore considering what we did to it. This, however, goes for all three third party suites, it still takes less time to 'extend' existing controls than write them from scratch. I will note that Telerik is the only suite that does not let us 'integrate' our, for example, custom column types into the 'builder' you provide, the other recognize the existance of the custom column types and allow use from within the VS designer, not too big a deal, but frustrating at times. Anyways, many of these customizations completely died and REFUSED to work, which is common with your updates, but this is a pretty bad one, we're not sure yet what is causing this.
  
  Functionality-wise (eg, outside of the presentation layer that malfunctions now), everythign this fine. That is good news to me.
  
  As for the PNG8 bit, while it indeed works okay with most browsers, we are noticing that they don't work under larger systems, medium-sized servers such as the AS/400 simply refuse to display them, but that was to be expected, it required some major work to get such machines to properly deal with anything coming from ASP.NET (to clarify, the AS/400 in question retrieves the web pages and such from a (very large) cluster of Windows Server 2003 based machines, does a crapload of data insertions and feeds the resulting completed pages to the 'green screens', long story, but an extremely interesting project we did).
  
  Now, what i totally expected, a Fujitsu super-computer completely rejected any PNG8 data, it simply doesn't support PNG at all, which can be fixed, we'll whip up some code that allows it to process the data. This is another situation where presentation comes from the outside, and the huge computer outputs it to the workstations and a few 'green screens' after doing some data magic/simulations/anything heavy math/etc and adding the resulting data to the web pages.
  
  WIthin the comments of this blog post, some users think that we are nuts for supporting IE4, try supporting systems that were already 'ancient' when the interwebs were invented. We actually have to do this, the two above examples of larger systems, one a database server, the other a machine that does the sort of mathematics that Einstein would run away from. Our industry is extremely demanding and there are hunderds of legacy systems they still use, IBM mainframes from the 70s are fairly common for example. We actually have to make systems like that support whatever the customer needs it to do (not always web based of course, many different things). We don't just make 'web applications', we develop anything from plugins to Office to complete simulation models for the above super-computer.
  
  Our framework is massive mainly due to the amount of code it requires to actually 'talk' to systems like that. It is not an easy task to make a super-computer talk to an iPhone and get the presentation of whatever is going back and forth correct at all times, which is what our framework makes possible. As much as the industry is way behind on technology in places, it is also way AHEAD of 'common technology' in other places, simply because they have to develop completely new technology to do what they do. Our framework deals with those situations as well.
  
  The main reason for the development of such an extensive framework with such ridiculous functionality is the same as anywhere else, our customers want to access their systems using anything, from anywhere, at all times.
  
  This is pretty tough work of course, so i tend to get a little 'anal' regarding big changes in products we might end up relying upon once we hit production stage at the customers.
  
  Regards,
  
  Mike
  
• Alexander Gyoshev 26 Feb 2009
  @Chris Metzl: I assume you are talking about the qsf.js.aspx and CodeViewer.js.aspx (these are the only .js.aspx files in the entire Telerik.Web solution). It has nothing to do with compression, we are just using ResolveUrl to get the proper URL to the web service that fetches the code blocks in the code viewer.
  
• Grady Werner 26 Feb 2009
  I would assume that if you make your own custom skin, nothing stops you from using GIFs instead of PNGs, so I don't see what all the hubub is about it.
  
  One thing to remember is to use pngcrush on 8 bit pngs, however, to fix the colors in IE (and reduce the size), so if you have custom skins don't forget that step or your designers will wonder why the palette is off a bit.
  
  PngCrush can be downloaded from http://pmt.sourceforge.net/pngcrush/
  
  I recommend the settings below:
  
  pngcrush.exe -brute -force -rem alla "originalfilename" "outputfilename"  
• Moon 02 Mar 2009

  Really looking forward to the RadSkinBuilder! But a couple of months!
  
  I need it now! Wah! hehe.
  
  In fact, today I was going to start creating custom skins. I guess I'll use the defaults until the new release and work on something else for now.

  Thankfully I didn't make any headway on this last week or I'd really be crying.
  
  :)
  
  P.S. I figured when you said it supported PNG that you also took into consideration that IE6 does't support PNGs so you'd add the css necessary for that, or whatever. I wasn't alarmed. :)
  

• Levi 12 Mar 2009
  I can only ask myself what were you guys thinking when you once again changed all the existing skins making them look totally inconsistent with any interfaces using your current skins. This is STUPID STUPID STUPID.
  
  If you guys want to do something creative, make NEW skins, don't ruin old skins to look totally ridiculous and bearing little resemblance to Vista or anything else they are supposed to represent. I hoped you guys would have learned the lesson the first time, but I guess you want to make it impossible for anyone to smoothly upgrade without ruining the look of their application. It's funny that none of these so called improvement look any nicer other than a few small exceptions. The usability is just crap. The colors are too busy, no contrast, just mostly unusable skins. The few that were clean now are too dark, just a step backwards in so many ways.
  
  And no more skin previews in the demos section? Come on guys!! This whole release just doesn't make any sense to me. You guys have the best controls but these are such bad moves in my opinion.
  
• Graycrow 13 Mar 2009
  The 2008 Q3 runs smoothly with my application and looks nice. Q1 2009 is total disaster.
  
  For example, I'm using 5-6 RadTabStrips almost on every page on my project (yes, I know that it complex, but I have no choise - this is complex project), and they should looks different (not just different colors!). So, I created 4 custom skins and use 3 Telerik skins, and it was perfect! After update it's disaster - custom skins is broken because you changed base skin and Tererik skins with same names now have completelly different colors, shapes, font and sizes and it looks UGLY and non-professional.
  
  Also I'm using 2 custom RadGrid skins - broken, Gray RadGrid skin - not exist anymore, Gray Rad Window skin - not exist, "Default" replacement is ugly. Such things like calendars and RadFileUpload I even didn't checked yet - I have enough info to decide that I'm not going to update to the new version. And after 2 years of subscription I asking myself - should I renew it? Probably no, because Telerik doesn't understand how important back-compatinility is.
  
• Alexander Gyoshev 16 Mar 2009
  @Levi: The skin previews have been replaced by the skin chooser that is available in all of the demos that do not have a custom design (e.g. resembling Microsoft Word). It contains thumbnails, as the skinning example did (as the smart-tag within VS design-time). Regarding your other statements, please read below the response for Graycrow.
  
  @Graycrow: Please send us your custom RadGrid skins and they will be fixed. All RadTabStrip skins can be used without modification with the new release by removing the embedded base stylesheet (EnableEmbeddedBaseStylesheet="false") and linking to the one from the Q3 release. We will port Q3 skins to the new namiing convention / base stylesheet, but you should threat that as a temporary solution, as we will be comitted to improving the embedded skins to their best.
  
  I am really sorry that you guys don't like the new look. The motivation behind it was that through the "dimensional" changes, we're providing you with another feature of the controls - seamless support of theming. You can rest assured that when you change a skin, only the colors change, and that the page won't break - which was a great pain if one tried it with any previous version of the controls. Furthermore, this time the skins have been crafted cautiously, and are more performant. And this is the last dimensional change - take it as a promise. We had to make it, in order to break out of the vicious circle of hacking away a new skin and not allowing it to be changed, ever.
  
  Now, if you don't like the colors, please share your feedback more specifically. We are going to take it into account, and any usability suggestions beyond color are also welcome.
  
• Ole Michelsen 16 Mar 2009
  I must admit that I don't like these skins  AT ALL. While this might be harsh, let me mention my two first "deal breaker"-impressions:

  
  

  Why on earth are font-family's hardcoded into the skins, to completely disregard the settings for the rest of the page? This means I have to at AT LEAST change the font manually for EACH Telerik control, just to keep a minimum of similarity with the rest of the site?!

  
  

  Secondly I'm using the Grid, and the new "grouping-color" adds a heavy dark line around the entire Grid. I just think that is plain ugly, so that I also have to change. Especially since there is no "light" skin any more.

  
  

  The most ironic thing is, that if your reply to my post is something like "then just create your own", then think about the fact that you have just thrashed all the custom skins I made in the first place. All your new skins look alike, just in different colors, but that is not good, because the overall "style" is "glossy ugly Windows". No stylish, elegant, and simple skins at all. 

  
  

  I fully support streamlining your skin style specs, so no argument there, but I think all the new skins are useless and I have to disable them all and start from scratch. Happy coding :-/
• Rob 16 Mar 2009
  Dear God what has happened to the skins? The one we use is gone and our custom ones are ruined due to the ridiculous references to font families and all manner of properties that shouldn't be referred to where they are.
  
  I honestly can't believe you've thought this through.
  
• Div 19 Mar 2009

  After seeing so much of grief I don’t think I have to say much but I think re-design or re-development team should have thought of it before doing all this mess.
  
  Some of the changes have broken the control totally. Only 2 ASP.Net Ajax controls (i.e. RadGrid, RadEditor) we have used extensively and they both are broken with new released dll (i.e. Q1 2009). I don’t know what else I could say. I am not sure, and I have not found any solution for it yet.
  
  I will have to fluff around and figure out what changes I can do to controls/skins to fix them, which I don’t think is acceptable but I don’t know what more I can do about it.

   

  BTW – issues I have with controls,

   

  RadGrid’s Page Footer is broken so I always get page footer in 2 rows

  RadEditor layout is totally messed up (all the tools on top is broken into new row from the dropdown tool e.g. Cut, copy and paste in 1 row but as soon as it hits font name dropdown it goes toolbar breaks into row if I have 3 dropdown tools in a bar then obviously it breaks toolbar into 3 rows and my editor is 5 rows in height so I am not able to see editor)

   

• CS 19 Mar 2009

  Why not keeping all existing skins, that's a crazy idea.
  Thanks for adding new skins, but don't remove existing ones....to much useless work to adapt.

  CS

• andrea 19 Mar 2009
  Why i'm not amazed?
  
• -DJ- 20 Mar 2009
  
  @ All IE 6 and .gif guys.
  
  Firstly, IE 6 was released in 2001. It's an 8 year old browser that has no business being used today. I don't support it in any of my projects and I would like to see everyone stop supporting it. You know, we have IE 7 now and IE 8 on the way.
  
  Where and when will you draw a line in the sand? Why not support IE 4?
  
  But it's easy for your clients not to upgrade their browsers as long as you go out of your way to support their ways.
  
  Regards,
  -DJ-
  
• matt del vecchio 26 Mar 2009
  BRING BACK *GRAY* SKIN!!
  
  seriously guys -- all your skins are futuristic, glossy, shiny, sci-fi skins.... they simply arent usable or practical for the vast majority of my business apps.
  
  i want and need PLAIN skins. "GRAY" fit that bill PERFECTLY... it was CLEAN, and ELEGANT. *not flashy*. let me repeat: **not flashy**.
  
  ...and now, after just one quarter, its gone. that is a mistake.
  
  
  separately...in the prev quarter, many of the Input controls were all mis-matched -- NumberTextBoxes didn't match MaskedTextBoxes didnt match ComboBoxes -- they all had different heights, colors, and font. have you fixed this for a CONSISTENT EXPERIENCE ACROSS THE BOARD?
  
  i really do love RadControls other than the above.
  
  
  thanks!
  matt
  
• saberint 29 Mar 2009
  TBH I'm not concerned about PNG's and the rest of it, but rather a product that actually works. Everytime a new version comes out, we spend days re-testing the product and then a week or 2 writting code to work around the bugs.
  
  RadControls shows a lot of promise, but rather then striving to be the company with the newest product, how about just making sure the old one actually works? Or actually having the Telerik team reading through the forums more often rather then making us do a support ticket.
  
  A forum is the first place people go to when they have a problem. But if you do put a problem up there, it can take days before anyone from Telerik looks at it, if indeed they do.
• Tervel 13 Apr 2009
  I believe the second post I wrote answers most of the outstanding questions from the last comments posted here:
  http://blogs.telerik.com/tervelpeykov/posts/09-03-20/using_pre-q1_2009_skins_with_q1_2009.aspx
  
  @matt del vecchio
  Matt, probably you noticed this as your post is from two weeks + ago, but I will write it anyway: the Gray skin is meant to be replaced by the current Default skin, which is gray-based, simple and can fit in huge variety of color schemes.
  
  
• Tommy K. 27 Apr 2009
  Tervel, your latest build has broken the Rotator.  You guys said you would fix the issue in IE where the first rotated image that has a transparent PNG is fine, but every rotation afterwards, transparency goes away and you're left with the solid color filling in the transparent part of the PNG.
  
  RE: http://www.telerik.com/community/forums/aspnet-ajax/rotator/white-background.aspx
  
  Now, in IE8, we can't even choose an animation type of "none" to get around this bug. 
  
  I've tried everything to no avail:
  
  

  .RadRotator_Default .rrClipRegion {
   width: 100%;
   height: 100%;
   background-color: Transparent !important;
   overflow: hidden;
   position: absolute;}
  .RadRotator_Default ul li div {background-color:transparent !important;}

  .RadRotator_Default .rrRelativeWrapper {background-color:transparent !important;}
  .RadRotator_Default .rrRelativeWrapper .rrClipRegion {background-color:transparent !important;}
  .RadRotator_Default .rrRelativeWrapper .rrClipRegion .rrItemsList {background-color:transparent !important;}
  .RadRotator_Default .rrRelativeWrapper .rrClipRegion .rrItemsList .rrItem {background-color:transparent !important;}
  .RadRotator_Default .rrItem div {background-color:transparent !important;}

  .RadRotator_Default .rrRelativeWrapper .rrClipRegion .rrItemsList .rrItem div {background-color:transparent !important;}
  
  .rrClipRegion {background-color:transparent !important;}
   
  .rrItem div {background-color:transparent !important;}
  
  Please advise, my company doesn't want to remit our source code for security reasons.

• ANKIT 29 Apr 2009
  .
  
• Fiko 19 Jun 2009
  The described behavior is not directly related to the RadControls but to IE browser behavior in such case. You can observe it without any RadControls on the page - you can  examine the attached project(IEBehavior.zip) to confirm this::
  
  http://www.telerik.com/community/code-library/aspnet-ajax/rotator/fix-the-jagged-text-appearance-under-ie.aspx
  
  You can see that the page does not contain any RadControls(even reference to the Telerik.Web.UI.dll), but the issue  still exists.
  
  In  newer versions of RadControls (Q1 2009 and later) we introduced jQuery animations and this influences  the opacity  of the elements, even  Anumationtype="None" is set. That is why the isuue appears every time in  newer versions of the controls.
  
• megha 07 Jun 2010
  In my project I pasted new Telerik.Web.UI.dll 2010.1.519.35 DLL and which replaced earlier Telerik.Web.UI.dll ( 2008.1.619.20)
  There are 41 files where I have used rad combobox 5 times in each page.
  I can not edit existing aspx design. I want solution which give me unique change without touching my existing aspx files.
  In bin folder there is another DLL  RadComboBox.Net2.dll (2.8.1.0)
  code is as follows:
  
  
  <%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" %>
  
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  
  <%@ Register Assembly="Telerik.Web.UI" Namespace="Telerik.Web.UI" TagPrefix="radC" %>
  <html xmlns="http://www.w3.org/1999/xhtml">
  <head runat="server">
      <title></title>
  </head>
  <body>
      <form id="form1" runat="server">
          <asp:ScriptManager ID="ScriptManager1" runat="server">
          </asp:ScriptManager>
         
          <radc:radcombobox width="135px" skin="Default2006" id="radcprice" runat="server"
              autopostback="true">
              <Items>
                  <radC:RadComboBoxItem Value="1" Text="Select"/>
                  <radC:RadComboBoxItem Value="2" Text="Lowest to Highest" Selected="true"/>
                  <radC:RadComboBoxItem Value="3" Text="Highest to Lowest" />
              </Items>
          </radc:radcombobox>
      </form>
     
  </body>
  </html>
  
  
  Please let me know how do we resolve this .