SharePoint Users Group > SharePoint Blogs > Kyle's SharePoint Karate

Kyle's SharePoint Karate

Design Minute: Custom Page Content Styles 
  • Currently rated 4/5

Trying to standardize header and section title styles in SharePoint content is difficult, especially if your content authors are not CSS- or HTML-savvy.  When creating heading styles, many authors will use the font size and color controls to create inline CSS within the content.  This is a designer's nightmare, because it eliminates the ability to create a consistent theme across all pages, and it disallows a site-wide change to content style.

The best way to circumvent these issues is to create your own set of standard header and section styles that are easily available to your content authors directly within the content editor.  These styles appear in the seldom-used "Styles" menu within the content editor toolbar.  By default, you'll notice this menu is populated with three header styles that are just about everything but useful.  We'll be replacing these three default styles with our own set of custom styles.  The first step is to open an attached CSS file (usually your default CSS file) that is available on all pages throughout your site.  In this CSS file, you'll want to add the following code:

.ms-rteCustom-MyCustomStyle1 { color: #ff0000; }
.ms-rteCustom-MyCustomStyle2 { color: #00ff00; }
.ms-rteCustom-MyCustomStyle3 { color: #0000ff; }

Once you've added this code, your custom styles now appear in the "Styles" menu on the content editor toolbar:

Custom Editor Styles

You can add as many styles as you'd like, and you can change all sorts of CSS properties, such as font weight, size, color, padding, margins, etc.  It is important to note that all custom "Styles" menu styles must begin with .ms-rteCustom-.  If your style does not begin with this text, it will not appear in the menu.

All About Tabless Column Design 
  • Currently rated 5/5

There are a number of ways to create vertical columns in your XHTML design without using the <table> tag and the horrendous amount of HTML that always seems to accompany it. Each method listed here is superior in various situations, so choose a good fit for your particular design.

But…why?

Why do we go through all the trouble of creating tableless designs? In short, the answer is performance. At times, it may feel easier to simply drop in a table tag and quickly split your design into columns, but that’s not always the best option. Tables create a large amount of extraneous HTML that can make your pages slower for visitors to download. While it may not seem like a huge difference at first, when designing a template for a very large site, the difference can be astounding.

CSS that is defined in externally linked files is cached on client computers, meaning that anything you put in your external CSS files is downloaded only once. Once that CSS file is downloaded, it is quickly loaded on subsequent page visits, which is faster for your visitor and easier on your web server.

Why is this important? Stay with me, we’re getting there!

Generally, the content in your site changes as visitors browse from page to page, but the overall design remains the same. It is much easier (and faster) to store this persistent design information in cached files, such as images and CSS.

In a tableless column design, almost all design information is stored in cached CSS files. A design that uses tables, on the other hand, often includes some of this information directly in the HTML, forcing users to download the HTML on every page in the site. Whenever possible, site design should be done in CSS rather than in HTML; for this reason, tableless designs are the modern preferred standard in web design.

Floating Columns

The float attribute in CSS is very powerful. So powerful, in fact, that many people seem to shy away from using it. Don’t be afraid! A bad float can ruin any good design, but using them when appropriate will alleviate your HTML-table woes.

The HTML:

<div class="columns">
    <div class="left">
        <p><strong>This is left-hand content.</strong></p>
        <p>Lorem ipsum dolor sit amet.</p>
    </div>
    <div class="right">
        <p><strong>This is right-hand content.</strong></p>
        <p>Lorem ipsum dolor sit amet.</p>
    </div>
    <div class="bottom"></div>
</div>

The CSS:

.left { width: 60%; float: left; padding: 0 2% 0 0; }
.right { width: 35%; float: left; padding: 0 0 0 2%; }
.bottom { clear: both; }

The Result:

Advantages:
Fluid width - allows for dynamic width (resizing)
Fluid height - matches the height of the tallest column, allowing for fully dynamic height of all columns

Disadvantages:
Floating - if you are using fixed-width columns, and if the content in a column is too wide, your columns will word-wrap within your design and stack on top of each other
Variable column height - background colors or images applied to columns will not match in height

Absolute Columns

In many cases, the floating column design does the trick quite amiably. If, however, for some reason you find yourself in a situation where you are using a fixed-width design, and you really can’t control the width of content in your site, floating columns can become a nightmare. There’s nothing worse than seeing your left-hand column disappear from your layout, only to be re-positioned at the bottom of your page! If that’s the case, you may consider using the absolutely-positioned column design.

The HTML:

<div class="columns">
    <div class="left">
        <p><strong>This is left-hand content.</strong></p>
        <p>Lorem ipsum dolor sit amet.</p>
    </div>
    <div class="right">
        <p><strong>This is right-hand content.</strong></p>
        <p>Lorem ipsum dolor sit amet.</p>
    </div>
</div>

The CSS:

.columns { position: relative; }
.left { width: 60%; margin: 0 35% 0 0; padding: 0 2% 0 0; }
.right { position: absolute; top: 0; right: 0; width: 35%; padding: 0 0 0 2%; }

The Result:

Advantages:
Fluid width - allows for dynamic width (resizing)
No floating - consistent even when content is too wide to display

Disadvantages:
Minimum height - the absolutely-positioned column must always be shorter in height than the fluid column(s), else it will display on top of design elements below
Variable column height - background colors or images applied to columns will not match in height

Concerning “variable column height.”

I would like to point out that “variable column height” is listed as a disadvantage of each method. The main disadvantage in using tableless CSS column designs is that when you have two elements side-by-side, they won’t necessarily match in height. If your design requires two shaded columns to match in height, this tableless approach may not be your best option. In general, it’s best to create designs that don’t require this type of approach from the get-go. Many people try to compensate for this lack of height-matching by using repeating background images that make it appear as if the columns match in height, but I have never been a fan of adding images to do something that HTML and CSS could handle otherwise.

When all else fails…

The only time I use a table in HTML is to (1) display tabular data or (2) when I absolutely need to have two height-matching elements display side-by-side in a design. Some fanatical CSS enthusiasts would argue that this is a lame approach, but in some cases designers need to act on simple pragmatism.

If you’re in a situation where you need to use a table, please do not use extraneous HTML. The “cellpadding” and “cellspacing” attributes are not needed! You can do everything with CSS. It goes something like this:

The HTML:

<table class="columns">
    <tr>
        <td class="left">
            <p><strong>This is left-hand content.</strong></p>
            <p>Lorem ipsum dolor sit amet.</p>
        </td>
        <td class="right">
            <p><strong>This is right-hand content.</strong></p>
            <p>Lorem ipsum dolor sit amet.</p>
        </td>
    </tr>
</table>

The CSS:

.columns { width: 100%; border-collapse: collapse; }
.left { width: 60%; padding: 0; vertical-align: top; }
.right { width: 40%; padding: 0; vertical-align: top; }

The Result:

It may still be a table, but it’s a minimal table if I ever saw one.

Good luck, and happy styling.

 

Syndicated from KyleSchaeffer.com.

CSS Font-Size: em vs. px vs. pt vs. percent 

One of the most confusing aspects of CSS styling is the application of the font-size attribute for text scaling.  In CSS, you’re given four different units by which you can measure the size of text as it’s displayed in the web browser.  Which of these four units is best suited for the web?  It’s a question that’s spawned a diverse variety of debate and criticism.  Finding a definitive answer can be difficult, most likely because the question, itself, is so difficult to answer.

Meet the Units

  1. “Ems” (em):  The “em” is a scalable unit that is used in web document media.  An em is equal to the current font-size, for instance, if the font-size of the document is 12pt, 1em is equal to 12pt.  Ems are scalable in nature, so 2em would equal 24pt, .5em would equal 6pt, etc.  Ems are becoming increasingly popular in web documents due to scalability and their mobile-device-friendly nature.
  2. Pixels (px):  Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen).  One pixel is equal to one dot on the computer screen (the smallest division of your screen’s resolution).  Many web designers use pixel units in web documents in order to produce a pixel-perfect representation of their site as it is rendered in the browser.  One problem with the pixel unit is that it does not scale upward for visually-impaired readers or downward to fit mobile devices.
  3. Points (pt):  Points are traditionally used in print media (anything that is to be printed on paper, etc.).  One point is equal to 1/72 of an inch.  Points are much like pixels, in that they are fixed-size units and cannot scale in size.
  4. Percent (%):  The percent unit is much like the “em” unit, save for a few fundamental differences.  First and foremost, the current font-size is equal to 100% (i.e. 12pt = 100%).  While using the percent unit, your text remains fully scalable for mobile devices and for accessibility.

So, What’s the Difference?

It’s easy to understand the difference between font-size units when you see them in action.  Generally, 1em = 12pt = 16px = 100%.  When using these font-sizes, let’s see what happens when you increase the base font size (using the body CSS selector) from 100% to 120%.

Font-sizes as they increase from 100% to 120%.

Font-sizes as they increase from 100% to 120%.

As you can see, both the em and percent units get larger as the base font-size increases, but pixels and points do not.  It can be easy to set an absolute size for your text, but it’s much easier on your visitors to use scalable text that can display on any device or any machine.  For this reason, the em and percent units are preferred for web document text.

Em vs. Percent

We’ve decided that point and pixel units are not necessarily best suited for web documents, which leaves us with the em and percent units.  In theory, both the em and the percent units are identical, but in application, they actually have a few minor differences that are important to consider.

In the example above, we used the percent unit as our base font-size (on the body tag).  If you change your base font-size from percent to ems (i.e. body { font-size: 1em; }), you probably won’t notice a difference.  Let’s see what happens when “1em” is our body font-size, and when the client alters the “Text Size” setting of their browser (this is available in some browsers, such as Internet Explorer).

Font-size as the client changes the text size in their browser.

Font-size as the client changes the text size in their browser.

When the client’s browser text size is set to “medium,” there is no difference between ems and percent.  When the setting is altered, however, the difference is quite large.  On the “Smallest” setting, ems are much smaller than percent, and when on the “Largest” setting, it’s quite the opposite, with ems displaying much larger than percent.  While some could argue that the em units are scaling as they are truly intended, in practical application, the em text scales too abruptly, with the smallest text becoming hardly legible on some client machines.

The Verdict

In theory, the em unit is the new and upcoming standard for font sizes on the web, but in practice, the percent unit seems to provide a more consistent and accessible display for users.  When client settings have changed, percent text scales at a reasonable rate, allowing designers to preserve readability, accessibility, and visual design.

The winner:  percent (%).

 

Syndicated from KyleSchaeffer.com.

Content Query Web Parts: Move the "RSS Feed" Link 

A lot of people have asked me how to move the "RSS Feed" link on a content query web part.  To be honest, it's not really something that's very easily configurable right out of the box.  That can be frustrating to a lot of people, so I dug a little deeper to see exactly how this link works, and it turns out that it's not entirely too difficult to nudge that little orange icon elsewhere on the page.

Configure the CQWP

The first step is an easy one.  You need to configure your content query web part to display an RSS link at the bottom of the rollup.  Just edit the web part properties and check the box labeled "Enable feed for this web part."

Enable feed for this web part

Now you should see the "RSS Feed" link at the bottom of your content query web part output.  Easy!

In this tutorial, I'm going to move the feed link into the title area of the web part, so also make sure that your web part's chrome is set to "Default" or "Title and Border."

Moving the Feed Link

The content query web part's output (including the RSS feed link) is controlled almost entirely by XSL style sheets.  These style sheets can be found in SharePoint Designer.  Just open your site with Designer and navigate to the "/Style Library/XSL Style Sheets" folder.

Note: changing these XSL files will affect every CQWP in your entire site collection!  If you need to modify only one web part at a time, please read this post before continuing.

Open the ContentQueryMain.xsl file and look for the following code:

<xsl:if test="$FeedEnabled = 'True'">
    <div class="cqfeed">
        <xsl:variable name="FeedUrl1" select="concat($SiteUrl,$FeedPageUrl,'xsl=1&amp;web=',$WebUrl,'&amp;page=',$PageId,'&amp;wp=',$WebPartId)" />
        <a href="{cmswrt:RegisterFeedUrl( $FeedUrl1, 'application/rss+xml')}"><img src="\_layouts\images\rss.gif" border="0" alt="{cmswrt:GetPublishingResource('CbqRssAlt')}"/></a>
    </div>
</xsl:if>

This is your RSS feed link!  If you look up above this code, you'll see that it's rendering after the "cbqwp" table, which is the main body of the CQWP.  You can simply cut this entire <xsl:if> statement and move it above the main CQWP table, like so:

<xsl:if test="$FeedEnabled = 'True'">
    <div class="cqfeed">
        <xsl:variable name="FeedUrl1" select="concat($SiteUrl,$FeedPageUrl,'xsl=1&amp;web=',$WebUrl,'&amp;page=',$PageId,'&amp;wp=',$WebPartId)" />
        <a href="{cmswrt:RegisterFeedUrl( $FeedUrl1, 'application/rss+xml')}"><img src="\_layouts\images\rss.gif" border="0" alt="{cmswrt:GetPublishingResource('CbqRssAlt')}"/></a>
    </div>
</xsl:if>
<table id="cbqwp" cellspacing="0" cellpadding="0" class="cbq-layout-main">
    <tr>
        <xsl:choose>
            <xsl:when test="$IsEmpty">
                 <xsl:call-template name="OuterTemplate.Empty" >
                     <xsl:with-param name="EditMode" select="$cbq_iseditmode" />
                 </xsl:call-template>
            </xsl:when>
            <xsl:otherwise>
                 <xsl:call-template name="OuterTemplate.Body">
                     <xsl:with-param name="Rows" select="$Rows" />
                     <xsl:with-param name="FirstRow" select="1" />
                     <xsl:with-param name="LastRow" select="$RowCount" />
                </xsl:call-template>
            </xsl:otherwise>
        </xsl:choose>
    </tr>
</table>

If you save your changes, you'll notice that the RSS feed link is now above your content query web part results.

CSS Changes

We've moved our RSS feed link, but it's still taking up too much space in our web part, so we'll need to do a little CSS magic to make it look even better.

In an external CSS style sheet, add the following CSS code:

/* cqwp feeds */
.cqfeed { margin: -16px 0 0 0 !important; position: relative; top: -15px; }
.cqfeed img { vertical-align: middle; padding-right: 2px; }
.cqfeed a { text-decoration: none; color: #888888 !important; font-weight: bold; }

This moves your feed link up into the title bar of your web part (you may have to play around with the pixel amounts depending on the text size of your design), and it also reduces the amount of space that the feed link is taking up, allowing your results to be flush with the bottom of the web part title bar.

Moving the RSS Feed Link

This styling is designed for anonymous users (it looks a little funky if you have the web part edit menus visible), so you might want to move it to the left quite a bit if you're working on a design where many users will have edit page permissions.

Further Customizations

You can further customize the appearance of this link by adding your own RSS feed icon image and text.  In the XSL you'll notice the <a> tag contains the following code:

<img src="\_layouts\images\rss.gif" border="0" alt="{cmswrt:GetPublishingResource('CbqRssAlt')}"/>

Just change the image source to point to an icon image of your own making.  If you want to display text after the RSS icon, simply type some text after the image tag.  For example:

<a href="{cmswrt:RegisterFeedUrl( $FeedUrl1, 'application/rss+xml')}"><img src="/path/to/my/sweet/rss_icon.gif" border="0" alt="{cmswrt:GetPublishingResource('CbqRssAlt')}"/>&nbsp;RSS</a>
Karate Corners 

I've seen a lot of different ways to create round corners and boxes in web sites, and quite frankly I haven't exactly fallen in love with any of them.  A lot of the methods that I've seen use either (1) a table structure which I try to avoid at all costs, (2) too many nested DIV tags, (3) complex CSS, or (4) too many different images that have to be loaded all at once.

I took the best of the best and came up with a very simple way to create totally scalable boxes with round corners.  I've tested this on Internet Explorer 7, Mozilla FireFox 2.0, and Safari 3.1.

The Code:

HTML:
<div class="cornerBox">
    <div class="corner TL"></div>
    <div class="corner TR"></div>
    <div class="corner BL"></div>
    <div class="corner BR"></div>
    <div class="cornerBoxInner">
        <p>Lorem ipsum dolor sit amet.</p>
    </div>
</div>
CSS:
.cornerBox { position: relative; background: #cfcfcf; width: 100%; }
.corner { position: absolute; width: 10px; height: 10px; background: url('corners.gif') no-repeat; font-size: 0em; }
.cornerBoxInner { padding: 10px; }
.TL { top: 0; left: 0; background-position: 0 0; }
.TR { top: 0; right: 0; background-position: -10px 0; }
.BL { bottom: 0; left: 0; background-position: 0 -10px; }
.BR { bottom: 0; right: 0; background-position: -10px -10px; }

The HTML code is relatively simple.  You have an outer DIV tag with four "corner" DIVs inside of it.  Each of these corner DIVs are positioned with CSS so that they always appear at each corner of the outer DIV box.

UPDATE: This wasn't working quite right in IE6, so I added the "font-size: 0em;" attribute to the corner class and the "width: 100%;" attribute to the cornerBox class, which seemed to clear it up.

The Image:

Corners Image

Only one image is used for this box.  In my example, I created a 20x20 circle, which is comprised of four 10x10 corners.  By shifting the background image around, you can eliminate the need to download four separate GIF files on each of your boxes.

The Result:

Click here to see the HTML demo.

Karate Corners!  Click on the image above to see the HTML demo.  Happy styling!

Advanced Web Part Design, Part 2 

If you haven't read Advanced Web Part Design, Part 1, please do, because it's a good place to start if you're looking to get more visual flare out of your web parts.

I've been working on some upcoming changes to the SUG, and I created something that I thought was kind of cool, so I figured I'd share it here.  It's always fun to give your web parts some "zing," because web parts are really what SharePoint is all about.

The scenario:  Let's say that you have a page design where you want web parts in a specific area of the page to differ in appearance from web parts in other areas of the page.  This is actually fairly easy to accomplish.  Here's what it looks like:

Dynamic Web Part Styling

I'm not doing any fancy coding or JavaScript, this is all CSS.  We're going to do the same thing that we did in Part 1 of this tutorial, but we're going to do it twice!

  1. In SharePoint Designer, open the page layout that contains the web part zones you wish to modify; add the following HTML to this page layout:
    <div class="webPartZoneLeft">
        <WebPartPages:WebPartZone id="leftZone" runat="server" title="Left Zone"><ZoneTemplate></ZoneTemplate></WebPartPages:WebPartZone>
    </div>
    
    <div class="webPartZoneRight">
        <WebPartPages:WebPartZone id="rightZone" runat="server" title="Right Zone"><ZoneTemplate></ZoneTemplate></WebPartPages:WebPartZone>
    </div>
  2. If your web part design uses any background images, upload them to your server.
  3. In an attached CSS style sheet, add the following CSS:
    .ms-WPTitle a { color: #ffffff; }
    .ms-WPHeader td { padding-right: 0 !important; }
    .ms-HoverCellInActive a, .ms-HoverCellActiveDark a { color: #ffffff; font-size: .85em; }
    .webPartZoneLeft .ms-WPTitle { color: #ffffff; background: #8a8a8a url('/relative/path/zoneLeftBackgroundImage.gif') top left  no-repeat; padding: 3px 0 3px 10px; font-size: 1em; }
    .webPartZoneLeft .ms-WPHeader div.ms-HoverCellInActive, .contentLeft .ms-WPHeader div.ms-HoverCellActiveDark { background: #8a8a8a url('/relative/path/zoneLeftBackgroundImage.gif') top right no-repeat; height: 22px; margin: 0; border-style: none; }
    .webPartZoneLeft .ms-WPBorder { border-color: #bababa; background: #f0f0f0; padding: 7px; }
    .webPartZoneLeft .ms-partline { background: #bababa; }
    .webPartZoneRight .ms-WPTitle { color: #ffffff; background: #445775 url('/relative/path/zoneRightBackgroundImage.gif') top left  no-repeat; padding: 3px 0 3px 10px; font-size: 1em; }
    .webPartZoneRight .ms-WPHeader div.ms-HoverCellInActive, .contentRight .ms-WPHeader div.ms-HoverCellActiveDark { background: #445775 url('/relative/path/zoneRightBackgroundImage.gif') top right no-repeat; height: 22px; margin: 0; border-style: none; }
    .webPartZoneRight .ms-WPBorder { border-color: #8b9ebb; background: #f0f0f4; padding: 7px; }
    .webPartZoneRight .ms-partline { background: #8b9ebb; }
  4. Make sure your image paths and class names match the ones that you created in previous steps!

This is really simple HTML and CSS, but the effect it has on page design is tremendous. I've taken the same process used to apply a design to all web parts in the site, but I've applied the CSS to only a specific portion of the page.

SharePoint RSS Feeds UNHINGED 

In this post, I'm going to break open SharePoint RSS feeds and look at how we can customize them to look just the way we'd like.  Words for the wary:  this is not an easy task, but I'm goign to do my best to make it a little easier for you!  This involves changes to HTML, web parts, XSL, and even the web.config file on your SharePoint server.

First of all, how do you get an RSS feed?  This is the easy part.  Create a content query web part that rolls up all the information that you'd like to include in your RSS feed.  This can be a hidden web part or it can be on a hidden page if you don't want people to see the web part, itself.  The important thing is that the web part should exist somewhere where it won't get moved or deleted.  On your web part, just check the box labeled "Enable feed for this web part."

Enable RSS Feeds

Save your changes, and then you'll notice that at the very bottom of your web part, you now have a little RSS icon.  Click on this icon to view your RSS feed.

RSS Feed Icon

You can copy the URL for this page and reference anywhere in your site.  This is how you can make an RSS link that appears in a location other than at the bottom of your content rollups.  Very handy.

We now have a working feed, and it is very cool.  So cool, in fact, that you might even want to customize the output of this RSS feed.  Right now, it has the item title, the created date, and the item description (if it has one).  What if we want more?  What if we want to output some custom information instead of the item description, or perhaps even a preview of the item body content?  Welcome to "the hard part."

If you look at your feed URL, it consists of a few different distinct query string variables.  It might look something like this:

http://www.yoursite.com/_layouts/feed.aspx?xsl=1&web=%2Frelative%2Fpath&page=1222333a-5667-8bc9-d0e1-2b436acc974f&wp=12abcd34-e10a-4b62-a028-39e1ac0b7e07

  • The first query string variable, xsl refers to which XSL style sheet this feed should use
  • web refers to the relative path to the feed's web
  • page is the GUID of the page on which your web part is placed
  • wp is the GUID of the web part that contains the RSS feed data

The "feed.aspx" page basically compiles these variables, finds your web part, and then generates a feed based on all of the above information.

The feed output is controlled entirely by an XSL stylesheet called Rss.xsl.  You'll find this file by opening SharePoint Designer and navigating to the /Style Library/XSL Style Sheets folder.  You could just open up this file and start making changes, but that affects every single RSS feed in your entire site.  That's not desirable in most situations, so let's go ahead and make a new RSS XSL style sheet.  Create a copy of Rss.xsl and give it a new name (I'm calling mine SweetRss.xsl).

In your new XSL file, you can use <xsl:value-of select="@InternalFieldName"/> to output different information in your feed.  Word of warning:  not all fields are available by default.  You'll have to customize your content query web part in order to make any custom fields available to use in your RSS feed.  To learn more about customizing your content query web part's output, view this post by Heather Solomon.

I know this is a long and arduous task, but stay with me, we're almost done!  Now that we have our custom XSL file, we have to reference it in the RSS feed URL.  If you look at your RSS feed URL, you'll notice a little snippet that says "xsl=1".  This is actually referring to the old XSL file (Rss.xsl).  What does "1" have to do with "Rss.xsl," you ask?  Well I'll show you!

Log on to your SharePoint server and open your web application's web.config file, located here:  C:\Inetpub\wwwroot\wss\VirtualDirectories\##\web.config, where "##" is the port number of your SharePoint site (usually 80).

Please back up your web.config before making any changes!  If you tool up this file, your entire site will go crazy and break.

Near the bottom of this file, you'll see a section called <appSettings>.  In this section of the web.config file, you will see a key called "FeedXsl1."  Copy this entire key and paste it directly below on the next line.  Your new key will look something like this (change your file name to match):

<add key="FeedXsl2" value="/Style Library/Xsl Style Sheets/MyCustomRss.xsl" />

Once you've made this change to your web.config file, just change "xsl=1" to "xsl=2" in your feed URL.  Your feed is now displayed using the new XSL file!  Sweet!

There's no easy way to customize the content query web part to automatically generate the "xsl=2" link when it renders it's little RSS icon, but it can be done.  This link is actually set as a variable called "FeedUrl1" in the "ContentQueryMain.xsl" file, which (if changed) will update all content query web parts in your entire site.  Check out my other blog post on how to use a custom ContentQueryMain.xsl file with your content query web part.

SharePoint Design Seminar 
  • Currently rated 4.5/5

Coming up on May 14, I'll be instructing at a SharePoint design seminar in the Washington D.C. area.  For those of you who saw my presentation at the SharePoint Conference in Baltimore, you'll be familiar with the topic that we're going to cover: Uncompromising SharePoint Design.

The seminar will be a three-hour deep dive into all things related to SharePoint design.  We'll talk about master page configuration, style sheet inheritance, multimedia integration, DHTML, and the untapped power of content query web parts.

If you're interested, check out the training site at SusQtech.com:

http://www.susqtech.com/training

SharePoint Conference: Minimal Master and Core CSS 
  • Currently rated 5/5

Those of you who attended the SharePoint Conference in Baltimore saw my demo on the "better" SharePoint design process.  I promised to share my minimal template code, so here it is:

The Minimal Master and Core.css:  Download this code and use it as a template to create new SharePoint sites.

Note that you must override the default core.css file in order for this to work properly.  The best way to do this is to programmatically override the "SharePoint:CssLink" control, but if you need a quick fix, you can simply customize the "core.css" file for each site in your site collection.  Do this using the "Manage Styles" task pane in SharePoint Designer.  Just double-click on any style that begins with ".ms" and then replace the entire contents of core.css with the contents of CoreCss.txt.

Manage Styles Task Pane

The Demo Site Code:  This master page and CSS file make up the blue-themed demo that you saw me build at the end of my presentation.  Again, you must override the default core.css file using the method shown above in order for this to work correctly!

Happy styling!

Design Minute: SharePoint Calendar Width 
  • Currently rated 5/5

When you're creating a SharePoint design, the calendar web part can be very annoying.  Any time you add a calendar web part to a page, suddenly your fixed-width design is utterly destroyed by the overwhelmingly large width of the calendar web part.  Why does it need so much space?  Even if you don't have any content in your calendar, it still seems to manage to crush your hopes and dreams.  It's mean like that.

I have dealt with this for a long time until finally I delved into the depths of the SharePoint calendar to figure out just why it takes up so much space.  You will be surprised as to what I've found...

There is one (and only one) reason that the calendar takes up so much space.  There is an image that appears at the top of every calendar in SharePoint.  This image is not visible.  It is a blank and transparent image that seems to exist for no other reason than to fix the width of the calendar at a hefty 742 pixels wide.  You can find it here:

Calendar Web Part Hierarchy

I know what you're thinking; "That's crazy, Kyle."  I know, and yes, it is crazy.  There is, however, a remedy for your calendar web part woes.  In your master page or an attached style sheet, add the following line of CSS code:

.ms-calheader img { width: auto; }

You will be surprised at how astonishingly thin the calendar web part can actually be after you make this change.  I've seen it as small as 200-300 pixels wide without any content.  I hope that this tidbit of style sheet goodness will alleviate your SharePoint design frustrations!

1 - 10 Next
Kyle Schaeffer