A common problem for beginning ASP.NET developers is relative linking to CSS files in a MasterPage file. As it turns out, this is incredibly easy as shown below. Even better is that it works in ASP.NET MVC!

1

<link rel="Stylesheet" href="<%= ResolveUrl("css/Master.css") %>" type="text/css" media="screen" />

Actually, that is quite unfair to say because CSS itself (language/syntax) is okay on its own. It is the standards body and the set of standards they decided upon that cause nightmares for millions of developers and designers each day. This should be no secret for anyone who has attempted to get a site to work 100% in each browser, that is without a single pixel off. While it certainly is possible, the hacks often required to do so have been passed down through the generations of the language.

height: 100% – in your dreams
You would think that making a div have a height of 100% would mean that it would fill whatever space it was within. Not true! It works so long as the parent div has an explicit height. Note that it doesn’t work on this page. Note that while the right div has a height of 100%, it doesn’t adjust to fill the space created by the left div. Note that if you do not have the Clear div in there, you won’t even see the wrapper’s background. In otherwords, it doesn’t grow with its own content. Good job on those standards!

To fix this we have to define some explicit heights. By giving the Wrapper div a height of 800px you will notice that not only does the height setting work all of a sudden, so does the background! View the new code here.

While this is nice and all, it sucks for anything that has fluid height. The real fix for this is to move the right column’s bottom div outside of the right column and create two more columns afterwards. But now that div is outside the height of the left column which could make for an awkward gap, especially if you have a background image that provides a border. Enter the hacks: by adding a negative margin we can move the div back up into the column above it. See the final page. Congratulations, we have now entered the realm of CSS hacks and from here on out there is no turning back.

Margins and Padding In Nested Elements
Why is it that margins and padding in nested elements always seem to affect their parent elements? Furthermore, why can’t I define an explicit width and then give it padding? Why must the padding always be changed with the width? This makes for unreadable CSS that forces you to do addition and subtraction on the fly to get the true width of the element.

This one is simple: attaching the site’s content to the top of the page. This is easy enough as demonstrated here. No real trickery is required; just set the body and html tags to have a padding and margin of zero on all sides. If you are working in ASP.NET you may need to set them for the form as well. Never-the-less the two CSS properties do as we expect them to, at least until we add some real content. Just by adding a simple h1 and p tag we have already corrupted the parent element’s placement on the page.

Why does adding elements with a top margin to a nested element change the positioning of the parent element itself? In some cases (and probably here too, I don’t have WebDev bar installed here) the entire body is moved down because of this top margin issue. Regardless of that, a child’s positioning should never affect the position of the parent except for in specific/explicit cases. An element’s margins and padding should always be relative to the container it sits in and sibling elements. But instead we have to deal with setting top margins to zero now because of the CSS standards.

XAML Rocks
Which brings me to my point – the CSS language isn’t broken, the standards we follow are. If you look at Microsoft’s implementation of similar features in XAML, you will see that the standards they use actually make sense for all of those involved. Let’s look at the first problem I mentioned: advanced column layouts with a bottom positioned element in the right column. In XAML we can use a Grid to create the two columns, but many will cry out that is too easy and "tables" shouldn’t be used for layout purposes. Instead we can use the Grid as we would use a Div in HTML. We use the HorizontalAlignment attribute to tell each Grid to "float" which creates the columns. Much to the web developer’s surprise, XAML does exactly what you tell it to do!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<Window x:Class="BottomPositionedElement.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="600">
    <Grid Background="#2D2D2D">
        <Grid Background="#DFDFDF" Width="340" Margin="10" HorizontalAlignment="Left">
            <TextBlock>
                Some content would go here and stuff.
            </TextBlock>
        </Grid>
        <Grid Background="#8F8F8F" Width="200" Margin="10" HorizontalAlignment="Right">
            <Grid Background="YellowGreen" VerticalAlignment="Bottom" Margin="10">
                <TextBlock>Hello, world! I am a bottom positioned "div"</TextBlock>
            </Grid>
        </Grid>
    </Grid>
</Window>

My point is to raise the obvious question: If Microsoft can implement its own set of XML tags and write a standard for them that makes sense and works, why can’t the HTML/CSS standards bodies? To blame this on the browser manufacturers at this point is just silliness since IE8, Chrome, and FireFox all have similar isses. That is to say that they follow the standards but what you expect is not what you get.

Designing and developing a site for every single browser available is a monumental task. Hell even getting a site to work between the top four or five browsers can be a living nightmare. I am working on some new design ideas for a site and decided to put it through its paces by testing in IE7, IE8, IE8 Compat View, FireFox 3.x, Chrome and the latest version of Safari. While working on the site’s template I noticed that each browser had its own set of quirks. In fact I found that IE8 seemed to be one of the more standard browsers in that if a problem showed up elsewhere, it usually showed up in IE8.

There are a few things I learned during this process:

1. Before you get to the fancy stuff, layout your divs with some nasty backgrounds (that are distinct!) so you know exactly where and how each one is being rendered. You can also use web developer extensions for the browsers, but I find these do not persist across page posts. For example the web developer plugin for FireFox will reset your outlining settings when you refresh the page. Having to reset this every time you change something becomes a pain. By coloring every div, every element, you get a clear picture of what is going on.
2. li:hover, as seen in the navigation here, is fixed in IE8 RTW (Release To Web)! But not in compatibility view. This is strange however since IE7 does li:hover elements just dandy.
3. Margins can suck it. Apparently when you have a div (div A) within a div (div B) and set a top margin on div A, it affects the top margin of div B. This seems retarded to me, but if you set a top and bottom padding of 1 pixel on div B, all is swell again (except in IE7). If you remove the margin and use a padding in div A, you get the desire results.
4. Extra Spaces suck too. The hardest part of developing for multiple browsers is hunting down the odd spaces that show up where you don’t think they will pop up. It could be due to how you have your paddings and margins setup on touching divs, but trust me when I say that these spaces will be the end of every web designer.
5. Standards mean nothing unless every browser follows them strictly! Why does IE8 have a compatibility view? Screw it, and screw every other browser’s quirks too. If a standards body is created and designs a set of rules for the browsers’ rendering system to follow, they should make sure they follow them exactly. That is why they are called standards right? They aren’t “guidelines you should follow to make developers’ lives easier but don’t really have to follow them because the developer doesn’t really care that much!”

A short one here. When you are going to start theming SharePoint and need to figure out exactly what styles need to be changed, the best tool you can ever get is one like the Web Developer extension for FireFox. Now I hate FireFox, especially 3.x, but I run 2.x at work for the sole purpose of the WebDev extension. Right click on the page, select “Select CSS” under the CSS menu and click away. It will automatically pull CSS styles from the included sheets that pertain to the selected element. This will save hours of time digging through core.css and the page’s source HTML. Trust me.

You may be asking “What else will he post about?” Well, I plan to go through the actual creation of a master page file for the theme from Focused Games but first I have to figure out a few things like how to redo how SharePoint outputs stuff (tables – blegh!). Yeah, I am going that far because I am sick of seeing SharePoint sites that look like SharePoint. In between here and there I will keep touching on the general tidbits of information that may help.

Here is a good blog post about theming the SharePoint top navigation. Today’s post is all about CSS, so pull out your favorite design books… and then light them on fire because they will be of no use here. You’ll want to start off by pulling and probably printing the core.css file that is provided with SharePoint. It may also be a good idea to print the source code of your new non-designed master page. Why? This will give you an idea of what HTML code SharePoint produces and what CSS classes it uses.

Once that is done, go ahead and create a new CSS file in the “Style Library” of your site. Go into site settings for the main site and override the style sheet with that file. This can be found at the bottom. Now you are good to go! Almost… more to come soon.

Here is a little of the CSS you may be employing. This applies to the “Upload Document” style pages and gets rid of the background images and borders:

1
2
3
4
5
6
7

div.ms-areaseparatorright,div.ms-areaseparatorleft,.ms-nav,td.ms-bodyareapagemargin,td.ms-pagebottommarginleft,
td.ms-pagebottommargin,td.ms-titlearealeft,div.ms-titleareaframe,td.ms-areaseparatorleft,td.ms-titleareaframe,
.ms-titlearearight .ms-areaseparatorright,td.ms-pagebottommarginright,td.ms-sitetitle,td.ms-globalTitleArea
{
	border-color: #000;
	background: transparent;
}

I am beginning to do themes (master pages) for some SharePoint sites, so here is part 1 of an infinite number of parts (because of how difficult theming SP is) of “Theming SharePoint.”

Assumptions:

• Theming will be done in several ways.
• Any advanced theming will include modifying core template pages.
• The amount of modification is directly related to the number of work arounds needed.
• This is going to suck.

Initial Steps

1. Copy default.master from main site catalog directory. Rename and open.
2. Erase everything.
3. Open default.master in new window.
4. Add each individual part, one by one to the page without any layouts.
   1. I started with the header, copy pretty much everything over.
   2. Remove all table tags and __designer: attributes.
   3. Remove all div, p, b, and style tags.

After doing this, you should have a horrible looking page with all the content on it. The important piece here is to get the content working so it is possible to figure out what place holders do what. Next post will be about layouts, the CSS hacks and more.

Update (18:25): Added more detail to the last step. Basically strip everything but the place holders and the controls inside of them.