Genius, Antranig. It works like a charm. Both jumping and gap issues are resolved.
Thanks! Cindy On 2011-12-09, at 2:31 AM, Antranig Basman wrote: > 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 _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
