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
