Nice work. Brilliant. Johnny
On 2011-12-09, at 9:17 AM, Li, Cindy wrote: > 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
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
