FLUID-4525 UIOptions Jumpingness

[Antranig Basman]

Ok - I think I have finally got to the bottom of this. The fix is as simple as ensuring that the iframe has 
display-style of "block" - the default style of "inline" causes the iframe to be treated as inline-replaced, 
textual material within its parent, causing it to have a minimum height of one line. Adding
     display: block;
at line 26 of FatPanelUIOptions.css fixes both the jumping and vertical gap issues for me in the WordPress 
theme. I've pushed this fix to my branch "shadow" - we may well be able to revert my fixes from yesterday, 
or at least remove the explicit height manipulation code on startup.
Please give it a try,
Antranig


On 08/12/2011 09:20, Li, Cindy wrote:
> Thanks for looking into these issues, Antranig.
>
> I tried the new fixes and seems they bring us back to the previous status: the gap above the UIO menu is gone but the jumping issue is back.
>
> Cindy
>
> On 2011-12-08, at 3:41 AM, Antranig Basman wrote:
>
>> I've pushed a few fixes to my branch at https://github.com/amb26/infusion/tree/FLUID-4525 which as far as I can see resolve the two issues we saw on Johnny's FSSFive site, although their status is still rather dubious. Like cindyli, I also couldn't uncover the real cause behind the behaviour of the enclosing div for the sliding panel in some integrations to be of zero height, but in others to attain exactly one lineheight, leading to a gap appearing above the sliding panel button on first render - but I have added behaviour to FatPanel to make it go away by explicitly setting the div height to 0 as soon as is feasible.
>>
>> The jumping issue I have tackled by changing the order of various operations with sliding panel - eschewing the use of jQuery "slideUp" and "slideDown" in particular since these seek to alter the visibility of the animating element at the end of the animation - which I think causes a greater risk of jumping as the browser has to reassess the visibility of the entire iframe tree. The new strategy relies 100% on height manipulations of the iframe and its parent div in the document - as well as rescheduling the "show" operation to make sure that animation doesn't start until rendering of the iframe contents has completely finished (in fact, there is no explicit "show" operation at all any more, we simply defer to the existing "DOM height changed" pathway).
>>
>> Please test these out and see if the problems indeed seem to have gone away.
>>
>> Cheers,
>> Antranig