Why isn't my HTML table taking up the whole window when I set width and height to 100%?

I seems like every time I start back with webpages from WinForms or services, I want to create a simple table that takes up the entire page, so I do something like this:
<table style="height: 100%; width: 100%;background-color: Gray">
<tr>
<td>foo&</td>
</tr>
</table>

I would expect my entire browser window to now show up with a gray background due to the table I added filling the entire window. What I actually see is a gray square in the upper-left portion of the browser which is grey, with my "foo" text displayed.

It seems that this "problem" is actually the expected behaviour with the above snippet. The rendered HTML is sitting within a HTML and BODY tag that we have yet to address, so it's filling 100% of the BODY width/height.

Here is one way to correct this issue - create a stylesheet and add the following declaration:
html, body
{
margin: 0;
padding: 0;
height: 100%;
width: 100%;
border: none;
}

When you apply this stylesheet to your page and refresh in your browser you should now see a gray background over your entire browser window.

The Unproductive Programmer

As a consultant in the IT World, I never know what I'm kind of client environment I'm going to end up in. I'm not talking about the politics and interpersonal aspects you find in the workplace, but rather the technological ecosystem. What kinds of computers will this client provide? What do the development/test/production systems look like? Do we have a test/stage environment? The list goes on.

In my current company, we generally take what the client provides, and my current client has provided some rather dusty, old machines for us. My machine has 512MB RAM and a 2.8 GHz P4 processor. Doesn't sound too bad until you consider that in a normal workday, I'll have VisualStudio2003 with ReSharper, Outlook (outbreak as my colleague Neal Ford likes to call it), and a VMWare instance of WinXP which I use for changes to the legacy VB6 system they have here.

The combination of VMWare and VS2003 proves quite deadly at 512MB RAM. I'm lucky if I can get both of these apps to stay open at the same time. Usually, if I have VS2003 open and try to open VMWare, as VMWare is launching, it will just disappear (watching my system resources, the available physical RAM dips to about 2MB!).

I suspect that in a given 8 hour workday, I spend at minimum, 10% of my time waiting for my computer to do something, and more likely, around 20% of the time waiting.

So, how much is this "cost saving" hardware really costing my client? Let's say I'm billing $60/hour (since this makes the math easy) -

Optimistic Lost Productivity:
$60/hour * (8 hours * 10% lost productivity) = $48/day in "lost" time

Wow, that can really add up over the course of a 6 month client engagement -
130 days * $48/day = $6,240 in lost productivity time over the course of the 6 months

A more modern machine like a nicely spec'd out Dell Precision 490 that I configured to a decent level of performance, and included 2 17" monitors, would be about $3000 to purchase, or maybe more cost effectively, lease at say, $120/month. Suffice to say; moving a team of 5 developers from "old tech" so something along these lines should decrease the lost productivity exponentially.

I guess I don't know what forces are at play that would "save" all this money by keeping all these out-dated computers around and have people spending countless hours waiting for their machines to catch-up.

Ah CollapseAll, one my favorite macros for Visual Studio, and one I'm surprised every developer doesn't have hot-keyed or at least a custom tool-bar button created for.

If you've ever worked in a decently scoped project for some length of time, you've probably experienced a point in time where your project/file structure in the Solution Explorer grows past the bounds of your screen. If you're fortunate enough to have ReSharper and to have vast knowledge of your codebase, this isn't that big of an issue - just hit one of the various keyboard shortcuts (Ctrl+F12, Ctrl+E, Ctrl+N, etc) and locate that file.

For those of us in the "unfortunate" bucket, we probably rely a bit more on the Solution Explorer. We have to go scrolling around and collapsing various projects until we narrow in on the project/files we're looking for. Not a big deal when you have project or two, but becomes a major P.I.T.A. when you've got 20 projects of various sizes in various states of expanded state.

A solution for this is the handy CollapseAll macro that someone came up with long ago (not sure who gets credit for this, but thanks!).

(See Chris' blog for some full details on adding the macro)

One thing I'll add, is that I generally like to add a new button that I stick over the Solution Explorer. To go about this, do the following:

1. In VisualStudio, select View/Toolbars/Customize
2. Create a new group - call it "MyMacros" and hit "OK" - a new button group will appear next to the toolbars dialog
3. In the Customize Toolbars dialog, select the "Commands" tab. Under "Categories" select "Macros" and now in the "Commands" listbox, locate your macro and drag that list-item to the floating button group
4. If you right-click the button, you can rename it to something a bit more concise, like "CollapseAll", you can also select an icon, etc for the button
5. Drag the button-group to the toolbar somewhere handy, like over the Solution Explorer.
   

We've been using Visual Studio 2005 Professional on my current project, along with Resharper 2.0. This combination has been the cause of countless issues along the way. One machine has been subjected to every build of Resharper 2.0 since 213.

Each build seems to have its good and bad points, but all come up short. My biggest gripe is that Alt+Enter functionality is missing. Well, that's not exactly true. One or two of our machines, at various stages, have managed to get Alt+Enter functionality.

I'm eagerly awaiting the build of Resharper 2.0 that gives me back the environment enhancements I've come to rely upon in Visual Studio 2003.

Update
Turns out that the issues we were having were due to a bad Ghost Image for our Windows XP machines. Once we went through the process of reloading software from DVDs, all was well in ReSharper land.