SharePoint Dialog Structure

I was working on our new website UI yesterday, and testing it on a site collection I had for some reason created as a Team Site. I know there are many who say this is the only correct way to do it, but I have never seen the point when the goal is a Publishing Site Collection. The publishing infrastucture works more flawlessly when the Site Collection is built on the Publishing Site template from the very beginning.

Yesterday I found one more reason to continue doing it the way I always have. A website is obviously built by using the publishing sites, publishing infrastructure, so within this test site of mine, I had activated the Publishing Infrastructure feature and created some Publishing sites to test the Page Layouts on. 

One of the things about websites and Foundation based intranet workspaces is that the latter are quite commonly scaling sites with no set width for the page content, whereas the websites and intranet publishing sites too are quite often fixed width sites. This more or less eliminates this problem I encountered yesterday, in most cases. So what was it, exactly?

To the point. When deploying the fixed width master pages to the Foundation based Site Collection, the dialog boxes, e.g. adding a new list item, acted funny, i.e. it used the fixed width of the general master page as the width for the content in the dialog box, while the box frame itself didn't seem to have any clue about the width of the contents. This problem does not exist with the scaling non-fixed width master pages. This problem also does not exist on fixed width sites in a Publishing Site Collection.

Of course I started to dig around a bit, and noticed that in a Foundation based Site Collection the dialog box is built using as many as two iFrames. And with this, if the content has a fixed width, the javascript detecting the needed frame size simply does not follow. Actually, I couldn't get it to follow completely properly (but getting a bit better result) even by changing the content width in dialogs to non-fixed, so some other publishing oriented css messes it up as well, but I didn't dig that far yesterday.

Yep, and the Publishing Site Collections? No iFrames, no problems.