Fixed width SharePoint master page creates problem for Web Part Adder/Update Panel

The problem

A very common request with custom SharePoint branding is to convert the master page and CSS to a centered, fixed width design.  For instructions on how to do this, check out my Creating a centered fixed width design in SharePoint 2010 blog post.  A lot of designs like to use “960px” for the width value.  Unfortunately this creates a problem for the SharePoint Web Part Adder/Update Panel (the WebPartAdderUpdatePanel control found in the SharePoint master page).  

A 960 pixel fixed width SharePoint master page isn’t wide enough for the panel. Depending on which browser you are using, the bottom buttons (Add and Cancel) will be hidden or partially cut off when the panel is active.  Here is a screenshot of what happens in IE:

Display issue with web part panel and fixed width design in IE

I got mixed results in Firefox. Sometimes the buttons are completely obscured while other times the buttons displayed just fine. Go figure.

If we adjust the fixed width to 1018 pixels, the buttons appear again:

Fixed display issue with web part panel and fixed width design in IE

So “1018px” (or larger) is the magic width value but changing your site design width to this size may not be acceptable. Luckily there is a quick CSS fix you can do.

The fix

The culprit behind this problem is an inline style set for a DIV element that wraps the web part description. Below is a screenshot showing the description area and the corresponding code.

Cause of display issue with web part panel and fixed width design

The DIV also uses a class, so that can be used in a new style statement that overrides the width of the DIV element. Since the width is set using an inline style, !important has to be included with the new value.

/* Reset the width of the wrapper for the web part description text in Web Part Adder/Update Panel */
.ms-wpadder-descriptionArea {
	width: 265px  !important;  /* !important used to override OOTB inline SharePoint style */
}

That is the end of the CSS fix. Simple and easy.

If you want a bit more CSS nerdiness… I would typically set the width value to “auto” but in this case it created an empty space on initial Web Part Panel load between the panel and the page content. I actually kind of liked how it looked, but once you use the panel and it collapses and then you go to use the panel again while in the same edit session, the space does not appear again. Because of this I opted to set the width to a unit of measurement. If you go larger than 265px it will create a horizontal scroll and break up the panel in an uneven way.