Craig Bolon
Top achievements
Rank 1
Rank 1
Craig Bolon
asked on 21 Aug 2007, 08:03 PM
August 21, 2007
Dear Telerik Support --
We have been using ComboBox 2.2 but needed to upgrade in order to get OffsetY as introduced at 2.5. The upgrade cost us about US$ 720 at standard billing rates.
All because at Some Point, Some One decided to make the boxes 11 pixels narrower and the dropdown panels 11 pixels wider. We had to visit each and every instance of a ComboBox, of which there are many, make the necessary changes to restore our software, then retest each possible use.
In English we have several choice words for Some One, as I am sure you must in Bulgarian -- none of them at all polite and most of them unprintable in a family newspaper.
-- Craig Bolon
Brookline, MA, USA
Dear Telerik Support --
We have been using ComboBox 2.2 but needed to upgrade in order to get OffsetY as introduced at 2.5. The upgrade cost us about US$ 720 at standard billing rates.
All because at Some Point, Some One decided to make the boxes 11 pixels narrower and the dropdown panels 11 pixels wider. We had to visit each and every instance of a ComboBox, of which there are many, make the necessary changes to restore our software, then retest each possible use.
In English we have several choice words for Some One, as I am sure you must in Bulgarian -- none of them at all polite and most of them unprintable in a family newspaper.
-- Craig Bolon
Brookline, MA, USA
1 Answer, 1 is accepted
0
Hi Craig Bolon,
First of all I want to apologize for the hard time you have had with RadComboBox. I know that from your point of view we have messed up but let me try to justify that change.
RadComboBox should now be with right size. They used to be 11px wider than needed (since the width was applied at the input element and the image width was not taken into account). I don't need to mention that lots of customers complained about that - for example you set the width to 100px but you end up with 111px because of the image.
RadComboBox indeed has a rendering issue which comes up from the limitation of the HTML standard and browsers.
RadComboBox should behave as inline element (as the HTML <select> tag does). However according to the W3C specification inline elements don't have size - setting their width will just do nothing. The only exception from this rule are input elements such as the input and texarea tags. Unfortunately, RadComboBox must render an input and an image. Setting the width of the outer DIV just does not work because it is with inline display (to mimic the dropdownlist behavior). Of course there is a new display "inline-block" which is exactly what we need. Unfortunately it is not widely supported in modern browsers - Internet Explorer supports it only for tags with "natural" inline display (e.g. SPANs) whilst FireFox doesn't support it all (there is something called display: -moz-inline-block which however is very buggy and works unpredictably). This leaves us no choice but to apply the width to the input element rendered by the combobox and then subtract the width of the image by using JavaScript. This works well in most cases but in others (when the combobox is inside a table tag for example) there is a noticeable flicker. In Internet Explorer html elements rendered inside tables don't have their size properly calculated until the page is loaded. Hence the flicker.
We are currently trying to resolve that issue by inventing a completely new rendering. I really hope we will tackle this issue soon.
Regards,
Atanas Korchev,
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center
First of all I want to apologize for the hard time you have had with RadComboBox. I know that from your point of view we have messed up but let me try to justify that change.
RadComboBox should now be with right size. They used to be 11px wider than needed (since the width was applied at the input element and the image width was not taken into account). I don't need to mention that lots of customers complained about that - for example you set the width to 100px but you end up with 111px because of the image.
RadComboBox indeed has a rendering issue which comes up from the limitation of the HTML standard and browsers.
RadComboBox should behave as inline element (as the HTML <select> tag does). However according to the W3C specification inline elements don't have size - setting their width will just do nothing. The only exception from this rule are input elements such as the input and texarea tags. Unfortunately, RadComboBox must render an input and an image. Setting the width of the outer DIV just does not work because it is with inline display (to mimic the dropdownlist behavior). Of course there is a new display "inline-block" which is exactly what we need. Unfortunately it is not widely supported in modern browsers - Internet Explorer supports it only for tags with "natural" inline display (e.g. SPANs) whilst FireFox doesn't support it all (there is something called display: -moz-inline-block which however is very buggy and works unpredictably). This leaves us no choice but to apply the width to the input element rendered by the combobox and then subtract the width of the image by using JavaScript. This works well in most cases but in others (when the combobox is inside a table tag for example) there is a noticeable flicker. In Internet Explorer html elements rendered inside tables don't have their size properly calculated until the page is loaded. Hence the flicker.
We are currently trying to resolve that issue by inventing a completely new rendering. I really hope we will tackle this issue soon.
Regards,
Atanas Korchev,
the Telerik team
Instantly find answers to your questions at the new Telerik Support Center