Question

In the context of SharePoint, I call a dialog. SharePoint basically created a lightbox div and puts my html inside. I have no control over where it decides to display the dialog, nor of its dimensions, and not even of the CSS used for the containing page. In other words, whatever I can do must be included inside my own html/javascript/CSS.

The problem arrives because my html contains this one div that is sometimes
too high for the dialog,
which I would then naturally like to have a vertical scrollbar. I therefore define it with the CSS style of “overflow:auto”.

But what I get instead is a scrollbar over the entire dialog, while the div is contained entirely in the dialog with no scrollbar at all.

I have traced the DOM, and I believe that the source of the problem is that the lightbox div containing my dialog is also defined with “overflow:auto”. Apparently this takes precedence over the inner div, so that the vertical scrollbar is put on the containing div rather than on my inner div.

I am looking for a way to move the scrollbar from the dialog to the inner div. Please remember that I cannot change the CSS to get rid of the “overflow:auto” in the lightbox div that contains my html.

I can fix the problem by setting the height of the inner div to an absolute pixel value, but as I cannot predict in advance how much screen space is allocated to the other elements of the dialog or to the dialog itself, the visual results could be rather ugly.

Any ideas ?

Below is a simplistic example of the layout of the problem :

<div style="overflow:auto"> <!-- lightbox div -->

<!-- start of my html -->
<div style="overflow:auto !important">
<!-- high div -->
</div>
<div>
<button></button>
<button></button>
</div>
<!-- end of my html -->

</div> <!-- end of lightbox div -->

I should also mention that I am using Internet Explorer 9.

Answer 1

SharePoint has a funny way of calculating the height of the html I supply it for using inside the dialog. It probably calculates it while it is detached from the page, so that CSS positioning cannot work. Any attempt to use a clever CSS schema, such as proposed by Alexey Ivanov, therefore fails totally, with SP miscalculating the html as being extremely short. The best solution is this way butchered by SP not supplying a framework with a size for the CSS to position the elements inside.

So we are left with a javascript solution. As my html is not inserted at the topmost level of the iframe, I have no access to any body events. The only solution is then to use the onload event of an img element, as the only hookable event available, as counseled by Ann L. Unfortunately, a real image must successfully be loaded for this event to fire, so if necessary one can add a minimal 1-by-1 pixel image, which even it can be gotten out of the way with a style of “display:none”.

The onload event is to contain javascript commands that will calculate the size of the dialog, subtract the total size of all elements except our maybe-too-high div, and set the height of this div to the calculated difference.

As DOM-traversal is quite broken in Internet Explorer, jQuery can be used to “fix” it by working around the bugs. If jQuery is not available, strong-arm methods can be used, such as looping on document.getElementsByTagName('div') to locate the divs of interest.

The SP divs that contain the supplied html can be identified by their className :

• ms-dlgContent : the dialog itself
• ms-dlgFrameContainer : the inner div that contains our html as its innerHTML and has the style of “overflow:auto” that conflicts with our own.

For the later, I have not managed to find any way of overriding its style of “overflow:auto”. I finally settled for deleting its className by setting it to null. Not too big a loss, as the only style it contains is this same troublesome “overflow:auto”.

All in all, quite a lot of work, both mental and programming, just because the SP programmers lacked a big enough imagination to take CSS positioning into account.