Skip to main content

Cloud

Relative positioning of cells–Something IE does best

Positioning in CSS is very useful, especially with SharePoint sites where many of the decisions were made long ago. Of course you can move around web parts and create custom page layouts and master pages, but when it comes to moving an element that was set inside of a SharePoint control, you are usually left with one option: CSS.

Here is an example. The SharePoint Search control:

Once the control is parsed in the browser, it is displayed as one table row with four cells (actually five with the last one acting as spacing).

Let’s say that we want to move the "Advanced Search" link down and to the left so that the entire control takes up less width. We give the link a Relative Position with a negative LEFT value and a positive TOP value like this in the CSS file.

table.ms-sbtable td.ms-sblink a {
position: relative;
left: -365px;
top: 20px;
}

The result is that the anchor is moved but the table still has the same width as before. This is because relative positioning will offset the elements box by the distance that you determine but the space that it would ordinarily have occupied is preserved. This is useful in some situations. For instance if you wanted to move the link up a little and did not want the cell on the right to move over and take its place.

In this case we are trying to decrease the width of the table. In order to move the anchor and have the space it occupied not be preserved, we will need to use Absolute Positioning. In the absolute positioning model, a box is removed from the normal flow entirely and assigned a position with respect to a containing block. [CSS 2.1]

Note, a box is explicitly offset with respect to its containing block, and the containing block of an element is natively the browser window. So, let’s assume we were to only change the positioning to absolute like this in the CSS file:

table.ms-sbtable td.ms-sblink a {
position: absolute;
left: -365px;
top: 20px;
}

The anchor would be 365 pixels off the page to the left of the browser window. This is a problem. We could change the left value from negative 365 to a positive value. That would insure that the anchor is visible on the page. But we do not know where the Search control is going to be. It moves around depending on the width of the browser.

What we must do is change what the containing block of the anchor (the browser) to something that we know will move with the Search control as the page is resized. We will make the table cell that the anchor is in the containing block by giving the cell a relative position. Even though we do not intend to move the containing element using positioning, we will set it so that we can move the element inside of it out of the ordinary flow and yet still have the two elements maintain their placement relation to one another.

The cell has a class of "ms-sblink" so we add this to an alternate CSS file:

table.ms-sbtable td.ms-sblink{
position: relative;
}

Now that the containing cell of the anchor has a position of "relative," the anchor is moved down and out in relation to its original position in the cell, and the space that it was occupying is not preserved. The result is a SharePoint Search control table that takes less width.

Great. Right? No. This only works in IE. Other browsers do not support the relative positioning of cells. The W3 CSS specs leave it up to the User-Agent to decide if a cell should act as a container for absolute positioned objects. It states: "…the ‘effect of ‘position: relative’ on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined." [CSS 2.1]

It seems that the creators of Internet Explorer knew how valuable it would be use relative positioning on table cells.

Other browsers do allow you to set relative positioning on elements other than the table header, row, cell, and footer. We may have lost the battle but we will win the war. As we look for an element other than a table that we can use as the containing block for our anchor we discover that the table is in a div. However it has no ID or Class assigned to it so let’s keep looking. That div is in another div with an ID of "SRSB."

<div id="SRSB">
<div>
<table border="0" class="ms-sbtable ms-sbtable-ex">
<tr class="ms-sbrow">
<td class="ms-sbscopes ms-sbcell">...</td>
<td class="ms-sbcell">...</td>
<td class="ms-sbgo ms-sbcell">...</td>
<td class="ms-sbcell ms-sblink"><a ...>Advanced Search</a></td>
<td class="ms-sbLastcell"></td>
</tr>
</table>
</div>
</div>

This div is an element that we can style from the CSS file like this:

#SRSB{
position: relative;
}

Notice that we use the pound sign when creating styles for an element that has an ID.

Now our solution works in all browsers. But the placement of the anchor is still off because we need to position the anchor as it relates to the top left of the div that is now its containing block.

table.ms-sbtable td.ms-sblink a {
position: absolute;
left: 5px;
top: 20px;
}

Try it out.

Try adding the following styles to your alternate CSS file of any default SharePoint site.

#SRSB{
position: relative;
}

table.ms-sbtable td.ms-sblink a{
position: absolute;
top:20px;
left:5px;
}

If you are not using a alternate CSS file you can place this code into a content editor web part (with the source editor not the Rich Text Editor)

<style type="text/css">
#SRSB{
position: relative;
}

table.ms-sbtable td.ms-sblink a{
position: absolute;
top:20px;
left:5px;
}
</style>

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Seth Broweleit

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram