Geeks With Blogs
Josh Meyer fun with .Net

     Anyone who's been working with WSS for any length of time has undoubtedly run into the infamous "ghosting" issue.  For anyone who hasn't, check out Todd Bleeker's discussion of the subject here.

Now on to the subject at hand.  Although I'm a proponent of site definitions as a method of global customization, what about page level customization?  Here's an example:  Our current customer uses a Windows application containing a Visio drawing in the Visio ActiveX drawing  control.  It basically monitors a system, displaying the current status of components.  Status changes are managed using a WSS InfoPath form library.  The Windows app runs on a large (42" or so) LCD display, so colors, font styles and sizes, etc. were chosen accordingly.  There is a second display below the first one that runs a custom view of the WSS form library, and our customer wants the styling of the form library view to match that of the windows app and also requires that the view not display any of the chrome (top nav bar, title bar, left nav…) that exists by default.


     This could all be done using FrontPage, but for reasons that should be obvious by now, we wanted to avoid any FrontPage page customizations.  Here's how I approached the problem:


  • I first created a data view web part (yes, using FrontPage) of the view I wanted, without changing any style formatting

Note:  Using FrontPage to create a data view web part (DVWP) is not the same as customizing a page with FrontPage, because the web part can be created on a temporary page, then saved as a .dwp file, and the now "unghosted" page can be thrown away.  The DVWP, can now be added to any page while still maintaining the "ghosted" state.


  • I then created the new web part page that will be displayed on the second monitor.  I added our DVWP to the page, and also a content editor web part (CEWP).  I was first introduced to the power of the CEWP at a MindSharp Developer Summit by Todd Bleeker, and I would have to say it's my favorite web part by far.  More on this in a minute…


  • Next I created a "Custom" directory in the SharePoint 60 Hive (c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Template\Layouts\1033\Custom).  This allows the Custom directory to be available from any site in the collection using /_layouts/1033/Custom/….


  • Next I created a new Cascading Style Sheet by copying and renaming OWS.CSS from the 60 Hive, and saved it to the Custom directory.


  • I modified the custom stylesheet according to the requirements
    • Page elements can be hidden by overriding the corresponding style with

.StyleToOverride{ display: none; }


  • Next I opened my new web part page and the Source Editor of the CEWP, and entered the following code:

<style> @import "/_layouts/1033/custom/NameOfCSSFile.css" </style>


     That’s it!  Now the entire web part page, including the CEWP, use a combination of the default WSS style and the Custom defined style, with the Custom defined style being applied last.  Now if I want to remove all custom styling, I just have to delete one line of code and it's back to default.  Also, I can share this stylesheet with any other pages on the virtual server using the same path.

Posted on Friday, October 7, 2005 5:53 AM WSS/MOSS , InfoPath | Back to top

Comments on this post: Overriding Style at the Page Level WITHOUT Using FrontPage

# re: Overriding Style at the Page Level WITHOUT Using FrontPage
Requesting Gravatar...
This is still one of the coolest things ever in the world of Sharepoint.
Left by solid on Oct 20, 2005 11:42 AM

Your comment:
 (will show your gravatar)

Copyright © Josh Meyer | Powered by: