Frequently, I have people ask me how to alter various elements of a Windows SharePoint Services (WSS) Web Part Page. To do this, you must first understand just a little about the HTML DOM (Document Object Model) rendered in the browser when you request a page from WSS. Fortunately, Microsoft (via ghosted direct-mode pages) has decorated the HTML elements on the default.aspx Web Part Page in a predictable and useful way. HTML tags often include "handles" (my word for element attributes like ID, Name, and Class) that you can use to gain access to and manipulate the DOM. One way to discover the handles available on a page is to view the HTML source of the current page (choose Source from the View menu in Internet Explorer). I frequently resort to this approach, but I am very familiar with HTML and the structure of a page. For a simpler approach, the Content Editor Web Part (CEWP) can lend some additional assistance.
My Style Under Cursor Web Part defines a table and populates it with values derived from attributes of the DOM element under the cursor. I'm sure that I wasn't the first, but I introduced the concept of viewing attributes of the element currently under the cursor using JavaScript in a browser in the FrontPage chapter (search for the section called “Changing Styles“) that I wrote for the SharePoint Resource Kit. Today there are some third party tools that can do this for any Web page (for instance, Firefox has a plug-in for viewing this kind of information) but I've extended the idea to include class parentage and improved the presentation and delivery for use within a CEWP. I'll save the technical details used in this Web Part for a future post so either import my StyleUnderCursor.DWP onto the home page of a WSS Team Site or paste the following code into the property builder behind the Source Editor... button of a CEWP you manually added to the page:
<script language="JavaScript">
function elementInfo()
{
//Output CSS Class Hierarchy
var currElement = window.event.srcElement;
var classTree = "";
var n = 50;
//Show first n characters of tagName in TAG cell
if(currElement.tagName != null)
{
ststag.innerText = "<" + currElement.tagName + ">";
if(ststag.innerText.length > n)
ststag.innerText = ststag.innerText.substring(1,n) + "...";
}
else
ststag.innerText = "";
//Show first n characters of id in ID cell
if(currElement.id != null)
{
stsid.innerText = currElement.id;
if(stsid.innerText.length > n)
stsid.innerText = stsid.innerText.substring(0,n) + "...";
}
else
stsid.innerText = "";
//Show first n characters of name in NAME cell
if(currElement.name != null)
{
stsname.innerText = currElement.name;
if(stsname.innerText.length > n)
stsname.innerText =
stsname.innerText.substring(0,n) + "...";
}
else
stsname.innerText = "";
//Show entire class parentage in the CLASS cell
if(currElement != null)
{
do
{
if(currElement.className != null &&
currElement.className != "")
{
if(classTree != "")
classTree = currElement.className + "\n" + classTree;
else
classTree = currElement.className;
}
currElement = currElement.parentElement;
} while (currElement != null);
stsclass.innerText = classTree;
}
else
{
stsclass.innerText = "";
}
}
//Run code on all mouse over events
window.document.body.onmouseover = elementInfo;
</script>
<table border="1" width="100%" height="220">
<tr>
<td valign="top">
<a href="http://www.mindsharpblogs.com/Todd"
target="_blank" Title="Todd's Blog">
<img src="/_layouts/images/pagelogo.gif"
border="0"></img></a>
</td>
<td valign="top" width="100%">
<table>
<tr>
<td>TAG:</td>
<td id="ststag" width="100%"></td>
</tr>
<tr>
<td>ID:</td>
<td id="stsid"></td>
</tr>
<tr>
<td>NAME:</td>
<td id="stsname"></td>
</tr>
<tr>
<td valign="top">CLASS:</td>
<td id="stsclass"></td>
</tr>
</table>
</td>
</tr>
</table>
As you move your mouse over the page you should see details about the element under the cursor. Put your mouse over the Search textbox for an interesting set of information.

This is telling you that the element (Search textbox) under the cursor is an INPUT tag, it has a tag ID=idSearchString, it has a tag NAME=SearchString, and it is modified by the following four classes in this order: ms-main CSS class (on the TABLE that controls positioning of all elements on the page), then ms-titleareaframe CSS class (on three block elements namely a TD, a DIV, and a TABLE that contain the search form), then ms-searchform CSS class (on two more TDs), and finally ms-searchbox CSS class (on the INPUT element that defines the textbox itself). These CSS classes are initially defined in the 60 hive, farm-level 60\TEMPLATE\LAYOUTS\1033\STYLES\OWS.CSS file. I've listed the default theme definitions of these styles below:
.ms-main
{
}
.ms-titlearea
{
font-family: verdana;
font-size: 9pt;
}
TD.ms-titleareaframe
{
color: black;
}
Div.ms-titleareaframe
{
border-top: 3px solid #ffd275;
}
.ms-searchform
{
background-color: #FFDF8C;
font-family: verdana;
font-size: 8pt;
}
.ms-searchbox
{
background-color: #FFFFFF;
font-family: verdana;
font-size: 8pt;
}
Notice that the ms-main CSS class is initially empty. In fact, not every tag will have a element ID or an element NAME defined either. But most HTML elements on a WSS page have at least one CSS class attributed. Every CSS class that effects an element is listed in the Style Under Cursor CEWP from the first CSS class applied to the element to the last CSS class applied. If multiple attributions are made, they are reflected in the list. Since CSS classes cascade, the display characteristics defined at every level are used but the last definition of redundant characteristics are the ones used. For instance, background-color is defined in both ms-searchform and ms-searchbox but since ms-searchbox is the last CSS class attributed to the INPUT element the color #FFFFFF will be used. All definitions for the containing block elements CSS classes will be overridden by the definition in ms-searchbox.
Altering the last CSS class attributed will have the most precise effect while altering one of the container CSS classes will typically have a more wide-sweeping effect. For instance, altering the ms-main CSS class would effect the entire page unless an altered characteristic were overridden by a CSS class later in the page.
I rarely want to modify the Web Server based, farm-level OWS.CSS file in the 60 hive. Microsoft owns this file. So, key to this Web Part, if the same CSS class is defined more than once on a page, the last class defined will be used. Since these classes are initially defined in the OWS.CSS at the farm-level, if you created a redundant ms-searchbox CSS class later on the HTML page, the later characteristics would be used. For instance, if you placed the following code in the Style Over Cursor CEWP, above the JavaScript in this example, the Search textbox's background color would change to cyan:

Why? Because the last ms-searchbox CSS class defined on the page is in the CEWP. The farm-level CSS class is defined in the HEAD of the HTML. More on this when I describe how to Hide the Quick Launch in the next post.
<Todd />