The evil seduction of working with CSS comes in the form of its ease of use—in theory. The problems start when you drift into complexity. I find it a psychological game where you are constantly tempted to trap yourself in something complicated (usually because Microsoft Internet Explorer continues its decades-long tradition of not supporting something correctly). You can look up and find hours have gone by because the layout fails to show the expected results.

The way to get out of this physiological trap is to find a way to strip out the complexity down to a known state. Many of these known states (from my CSS work) are preserved in my Studio. My latest specimens mark a big change in my block layout strategy. Before support for display: inline-block was widely available, my strategy depended on using the float property.

Using float on one block (usually an image) next to a larger static flow (like a paragraph) is still very attractive to me. But floating multiple blocks can be frustrating. This is where display: inline-block comes to the rescue. But this new tool in my chest is not perfect. In “CSS display: inline-block: why it rocks, and why it sucks,” Robert Nyman writes:

I hope so far that I have managed to get you to realize the potential and simplicity of this approach. However, there’s one giant drawback, that might or might not apply to your use case. That is, since the elements become rendered inline, white-space in your HTML code will affect the rendering.

I literally spent hours (maybe two or more) struggling with this white-space issue. According to a German donkey on StackOverflow.com, the official way out is use white-space-collapse: discard. But, typically, this property is not supported on most browsers. So a hack (typical, again) was suggested—use HTML comments:

<p><!--
  --><img src="." alt="" /><!--
  --><img src="." alt="" /><!--
  --><img src="." alt="" /><!--
  --><img src="." alt="" /><!--
--></p>

I haven’t tried this in Visual Studio for fear of needing to tweak my code formatting settings.

Another very subtle problem I had was accidentally nesting an inline-block display within an inline-block display. I am no CSS “ninja” so I see no reason why I need to do this. It took a significant amount of time to strip this complexity away and get back to a known state. I wasted time trying to convince myself that Firefox’s implementation of inline-block did not support siblings with different margins. My Studio sample proved me ridiculous. What was really going on was the unwanted nesting.

It seems cute and commemorative to preserve the test results from many of the whack-ass mechanized tests developers are sometimes required to take in order to engage with cattle-call-oriented recruiting companies.

There are people, friends/ex-coworkers/family (mostly connected to me on Facebook), who still are likely to assume that I’m unemployed—and this Blog skimmed over is not going to help that misconception. What is very comedic/tragic is to have a friend finally realize that I’ve been working for about six months only to become unemployed upon their realization.

Here’s my CSS test:


Bryan Wilhite, CSS Test Results

Here’s my HTML test:


Bryan Wilhite,

And, finally, my JavaScript test:


Bryan Wilhite,

Now the organization(s) that “asked” me to waste hours of my time taking these tests have a great idea of who they are representing. It turns out that my current employment has nothing to do with taking these tests. Yeah, right. So it might be possible to say that this was a complete waste of my time. However:

  • I did not think it was possible to write a serious CSS test until I found myself taken by surprise completing one.
  • I have learned about the quality, patterns and practices of selected recruiting agencies in the Southern California area.
  • In “defense” of the organizations that had me taking these tests, I am almost certain that at least one them was not a “real” IT recruiting outfit—one was more of general office staffing shop—that’s just how tough the job market has been and is like to continue to be.

Related Links

Buy this book at Amazon.com! My first exercise is translating the “biggest box” CSS strategy into WPF. For seasoned Expression designers this effort must be “crazy”—because XAML can do so much more than XHTML. So, the first thing is to get my “biggest box” to be exactly 1024×600 (my WSVGA standard). Just make the Window.Height="600" and Window.Width="1024", right? Well, what happens is that, by default, WPF will ‘share’ OS “chrome” with your Window dimensions. This means that the child element of Window (usually Grid or StackPanel) will have an ‘unknown’ width and height (this is not unknown, actually, because we have FrameworkElement.ActualWidth and FrameworkElement.ActualHeight to consult).

So what I’m saying (because I am too lazy to provide this Blog post with screenshots) is that my “biggest box” element for WPF is the first child element of Window. This means that my WPF must ‘push’ window “chrome” (all that Aero Glass) out of the space reserved for the “biggest box.” As usual, WPF provides for this with Window.SizeToContent="WidthAndHeight".

The next level beyond this is the question, “Does the Window need to be resizable?” When the answer is “no” then just set ResizeMode="NoResize" (my preference: ResizeMode="CanMinimize"). When the answer is “yes” then you have quite an elegant solution to grasp. I can only hope the hope of the captive that I’ll find it one day… By the way, before I reminded myself about the ResizeMode="NoResize" property and setting I wrote this for Application.OnStartup:

client.Loaded += new RoutedEventHandler(
(s, args) =>
{
    if(s is Client)
    {
        var c = (Client)s;
        c.MaxHeight = c.MinHeight = c.ActualHeight;
        c.MaxWidth = c.MinWidth = c.ActualWidth;
    }
});
                  

I was tempted for a spell to let the vertical height of the WPF be variable (like in a Web browser). Soon came some over-engineering ideas instead of design ideas. The first design principle in this context: a Web browser Document is not an application Window. It follows that a WPF Window should not recognize the existence of, say, ‘infinite’ vertical scroll. There are child WPF layout elements (wrapped with ScrollViewer) that can be used in various scenarios that facilitate scrolling. There are many valuable design ideas from the Web world that are valuable and they have to be recognized and coherently integrated—not confused. More on this later…