Hi,
Why does the RadEditor toggle full screen button in the ajax version take SOO LONG in IE 7 while the old version was nearly instant? However, the new RadEditor's toggle button seems to be near instance in FireFox. Now if we could just do something about IE.
Thanks,
Chris
Why does the RadEditor toggle full screen button in the ajax version take SOO LONG in IE 7 while the old version was nearly instant? However, the new RadEditor's toggle button seems to be near instance in FireFox. Now if we could just do something about IE.
Thanks,
Chris
4 Answers, 1 is accepted
0
Hello Chris,
There is a short and answer and a long answer:
Short answer: Because of IE. Its javascript and rendering engine is several times slower than FireFox.
Long answer: The toggle screen mode is more complex than is usually thought. To make sure the editor "breaks free" from all its parents, the whole parent hierarchy is traversed, and for each parent several CSS settings are changed to ensure the editor does not get "stuck". These are overflow, height, tableLayout and position.
Furthermore the editor's own size is changed as well as the page is scrolled so that its top and left match the top and left of the editor.
The code is pretty much as fast as can be (as you can see in FF). For some reason, however, it takes much more time for the operation to produce the end result in IE. Unfortunately at this point there seems to be little that can be done, hopefully the coming IE8 might have a better performance.
Kind regards,
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.
There is a short and answer and a long answer:
Short answer: Because of IE. Its javascript and rendering engine is several times slower than FireFox.
Long answer: The toggle screen mode is more complex than is usually thought. To make sure the editor "breaks free" from all its parents, the whole parent hierarchy is traversed, and for each parent several CSS settings are changed to ensure the editor does not get "stuck". These are overflow, height, tableLayout and position.
Furthermore the editor's own size is changed as well as the page is scrolled so that its top and left match the top and left of the editor.
The code is pretty much as fast as can be (as you can see in FF). For some reason, however, it takes much more time for the operation to produce the end result in IE. Unfortunately at this point there seems to be little that can be done, hopefully the coming IE8 might have a better performance.
Kind regards,
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.
0
Chris
Top achievements
Rank 1
Rank 1
answered on 25 Feb 2009, 03:51 PM
So it's not just a matter of changing, say a div's css that wraps the RadEditor to be positioned on top of everything on the page (via z-index) and maximized? That works fine for my modal dialogs...I suspect you probably found problems with that if you went to all this trouble to write complicated javascript to get the same affect.
Also, IE8 Beta has been out for a while (RC1 may already be out) - have you tried testing this feature on it? Word of caution, don't install IE8 on a computer where you want to retain IE7 because it will overwrite it.
Chris
Also, IE8 Beta has been out for a while (RC1 may already be out) - have you tried testing this feature on it? Word of caution, don't install IE8 on a computer where you want to retain IE7 because it will overwrite it.
Chris
0
Hi Chris,
Here is some more information on the ToggleScreenMode implementation
When it was originally conceived a couple of years ago, there were major inconsistencies among existing browsers (IE 6, FF 1, Safari 2x) etc. A number of approaches were tried, and this one seemed to work the best and in the most "cross-browser" manner. Hence, it has stuck like that - with occasional improvements over time, but essentially the same.
Now that the situation on the browser front has changed considerably (FF3, Safari 3x, Opera 9x) perhaps it is time to re-examine the approach and try an alternative that might be as good as now, only faster. We logged your suggestion for trying the absolute positioning and once we complete the higher-priority tasks scheduled for Q1 2009, we will try to improve on the ToggleScreenMode as well.
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.
Here is some more information on the ToggleScreenMode implementation
When it was originally conceived a couple of years ago, there were major inconsistencies among existing browsers (IE 6, FF 1, Safari 2x) etc. A number of approaches were tried, and this one seemed to work the best and in the most "cross-browser" manner. Hence, it has stuck like that - with occasional improvements over time, but essentially the same.
Now that the situation on the browser front has changed considerably (FF3, Safari 3x, Opera 9x) perhaps it is time to re-examine the approach and try an alternative that might be as good as now, only faster. We logged your suggestion for trying the absolute positioning and once we complete the higher-priority tasks scheduled for Q1 2009, we will try to improve on the ToggleScreenMode as well.
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.
0
Chris
Top achievements
Rank 1
Rank 1
answered on 03 Mar 2009, 03:07 PM
Thanks for the background info. I suppose you could still target your current toggle maximize function for the older browsers then use a newer approach if you detect IE7+, FF2+, etc.
Chris
Chris