Adam Howitt's Blog - CSS

Back from the Dead with Eclipse

Wed, 29 Oct 2008 16:50:48 -0400

This Halloween inspired post explains how to bring a file back from the dead if you've ever looked at it in eclipse.

I have been playing with blueprintcss and pulled down source this morning. It's genius to a developer with my *ahem* design skills, so I was thrilled to get it installed and running. But I was having trouble with one of their examples.

The idea is that the page is divided into 24 columns so you can give a div a class of "span-24" and voila, you have a 24 column div. You can create subdivs so that if your container is 12 columns you should be able to have subdivs marked span-8 and span-4 - gettit? 8+4=12. But it didn't. Somehow I was seeing funky layout wrapping.

Turns out I had the bleeding edge broken version but since I knew it was a github repo file, I could try out Git for the first time to pull down the fix (fixed minutes after I downloaded apparently). I installed Msysgit and then went to my blueprint directory. Tried a git pull from the command line within the repo directory but it said my local repo wasn't a repo. Grabbed the git cheat sheet and decided to do a "git init" and "git add ." Looking good.

git pull git://github.com/joshuaclayton/blueprint-css.git

Seems to have grabbed latest... Switch to eclipse and refresh project. Crap! My extensive client blueprint example vanishes before my eyes.

Enter the Dragon

At this point I usually stare at the screen but since time is against me I recreate my lay_blueprint.cfm file and just as I right click for some reason I notice the "replace with" eclipse context menu item is there. Hmm. I had clearly edited the file earlier today in Eclipse. Could it be... Holy Stomping Mummys Batman - back from the dead. My empty lay_blueprint.cfm fills with the lost code as my eyes fill with tears of joy. Yay Eclipse!

A Time to Post

Thu, 02 Feb 2006 10:46:27 -0400

Anyone who has been a regular reader may have noticed that I haven't been positng a great deal lately. The cause for the lag has been a 3 month project to rewrite a web application for my local park district to handle registrations four times a year when traffic surges from 2000 visitors per day to 2000 visitors per minute.

The application launches this afternoon and has brought in several challenging new topics: AJAX (including advanced DOM scripting, browser considerations, state management and interaction modelling), Clustering JRun across multiple instances and multiple servers, Load testing, Project Management and scalable application architecture.

After today there will be a two week delay before the madness begins for the Spring registration on February 20th. During this time I will be posting about each of the topics above to describe what happened, what I learned and what resources I found to help guide the application design. You may also find a guest post from Design Jeff to describe how he tackled the new challenge of designing an application for AJAX.

The first post will point you at the finished application to dig around and see what it looks like. Wish me luck!

CSS and Italics / Emphasis tags

Fri, 27 May 2005 17:45:16 -0400

I just spent an hour looking thru stylesheets and HTML switching between IE6 and Firefox looking for the cause of my layout woes. The two browsers were rendering the same piece of content very differently. A div was wrapping below the sub-navigation in IE6 but displaying fine in Firefox.

Pure coincidence had one of my coworkers walk past my cube to the window by my desk while I was in the middle of my search and he saw it immediately. On a previous project they had tracked down a formatting problem. Essentially, the presence of some HTML where text surrounded by an emphasis tag wraps onto a new line, IE increases the width of the containing box by 1 or 2 pixels but firefox *correctly* lets the errant text lean outside of it's container.

The fix for me was to reduce the width of the parent div containing the errant text by 2 pixels to allow it some breathing room in IE. I scanned all the remaining layouts and it all looks fine. Crazy stuff though.

Google Done Good!

Thu, 07 Apr 2005 20:14:29 -0400

For my last post about the site redesign, Google Ads showed a link to a product page for Visibone. In case you haven't seen it, they provide a simple CSS cheatsheet. I think I'm going to order one.

A Time for Change

Thu, 07 Apr 2005 15:42:53 -0400

Here are the "cliff notes" of the design changes this blog received last week in Jeff's own words. The old design is still available for those of you who preferred it. Personally I love the new design since it

prints out really well
doesn't kick out the formatting if I include a large code sample
provides more whitespace
looks darn good!

That said, over to you Jeff

Why the redesign?

Other than Adam being a friend of mine, I actually read his blog fairly often as I find a lot of the posts to be helpful or insightful. I've subscribed to the main RSS feed and find myself clicking through to the site more often than not. There are a few reasons I wanted to redesign his blog. First, if you've ever had the pleasure of knowing Adam you'd know straight away that the old blog design did not reflect his personality in any way (except for the fact that he lives in code and not in design and that was stiflingly apparent). He's professional, thorough and anal (in the good way, like me) and the old blog just looked kind of hobbled together. Second, it was impossible to scan. You couldn't distinguish between the different posts because there was no real visual distinction between them (and no, a plain old <hr> does not make a visual distinction). And because. like I said, Adam is thorough - his posts tend to lean on the longer side (especially lately) which made his main page pretty long which made the scanability of it degrade even more. Lastly, I just got tired of looking at it - which was most likely due to the three points I just made.

What was the reasoning behind the changes?

So the biggest thing that bothered me about his old blog was that it was a big ol' table-based layout which basically means your data and presentation are all jumbled together. I personally think it is wicked cool to be able to view the site unstyled (or "in the browser's default style" as Joe Clark would say) and have it look like a normal document structure, with headings and lists and all that fun stuff. (Yes, this is still a work in progress, so please don't get on me about the sidebar links not being in unordered lists, I'm getting there.) While some could argue that table-based layouts are "easier" I would argue that it's not what they were intended for. I could also argue that once you get comfortable in a CSS-P world, table-based layouts become very limiting. It's also wicked cool to be able to change the styles (layout included) without having to change a lick of the underlying HTML.

Some of the techniques employed

The easiest thing to do is to view the source and look at the different stylesheets. There's a lot of talk about how best to structure your stylesheets - I say use whatever works for you. What works for me is this: I typically use one main stylesheet (basestyles.css) that I import into the different, media-specific sheets. This base file contains the very basics, nothing position or layout related. I use two basic media-related stylesheets (screen.css and print.css -- Adam already had "style.css" so I opted to not rename his) in which I import said basestyles.css and then the custom styles for each media. As for my approach on screen and print, I typically focus primarily on the screen version - this is the web after all - and then duplicate it and being removing/editing it down for the print version. This is what works for me, and my process has morphed a few times already, so like I said - do what works for you.

The feedback (so far)

One of the most interesting things (to me at least) happened when Adam make the big switch from the old design to the new design. The first two (non-Adam) comments that came through were about the "big-ass" skyline image as I fondly refer to it. One was about it being an "ugly gif" now and the other was about liking the warmer colors of the old image. While both of these comments are perfectly valid they're also perfectly subjective. My guess is because the old gigantic image was so gigantic it was a fairly gigantic part of the the old design which made it the easiest thing to actually notice when looking at the new design. If nothing else, I can chalk it up to "interesting."

New Site Design

Wed, 30 Mar 2005 15:52:04 -0400

In the next couple of days you will see a post from a co-writer called Jeff (formerly known as the MacHead). He refused to participate without some graphical intervention and he has redesigned the site with real design principles.

He is going to explain some aspects of the rework in depth so look for some top CSS tips! The old version is still visible. Questions? Comments?

Popup alternative

Thu, 17 Mar 2005 14:27:55 -0400

I want to share a little trick Jeff and I have employed for a new client in this world of banned popups. A popup used to mean a dialog for the user to present important information without them navigating off a specific page and allow them to return to what they were doing. Without this useful tool the user experience gets broken up so with my javascript magic and Jeff's CSS skills we put together this code snippet.

There is an example on this page of the technique so you can see if you even like the approach. The search box used to take up valuable screen space so I removed it and used this technique to move it to a link under the recent posts section as "Search Archives". Click the link and you see a yellow popup form.

Assuming you thought the search box looked good I'll procede with the tutorial. First you need to create a div for the information you would ordinarily show in a popup:

<div id="whyWeAsk" class="popperHid">
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Phasellus suscipit mauris ut nunc. Phasellus volutpat quam a nisl. Etiam ante. Nunc odio lacus, fringilla nec, lacinia sit amet, cursus sed, lectus. Cras urna felis, gravida egestas, convallis vel, viverra nec, diam. Morbi consequat, tellus nec consectetuer rutrum, lectus diam pulvinar metus, sit amet sodales pede nisl ut nulla. Cras pretium lectus vitae mauris. Morbi lorem. Mauris pretium placerat tellus. Proin in metus. Pellentesque nec orci. Nunc velit mi, pharetra eget, suscipit non, suscipit id, sem. Nunc sit amet nulla a dolor pharetra hendrerit. Class aptent taciti sociosqu ad litora torquent.
<div id="closebutton"><input type="button" value="close this message" onClick="showWhy();"></div>
</div>

Without any other modifications this should display inline wherever you placed it on your page. Next we want to style the content to look pretty and also to hide onload so we add two styles for the "popper" itself and then style the buttons too. Either add the following styles to your site.css file or use the in page style tag:

Refresh your page and the popper becomes invisible since we have set the display property to "none". The alternate style we defined uses "display:block" and there is some other wizardry to position the popper in the middle of your page regardless of browser width.

Finally we add the following JavaScript function we mentioned in the initial popper div block and an href tag which, when clicked will call the toggling JavaScript function.

Put it all together and you end up with a handy tool to give a user context sensitive help on the page without navigating away from their current page.

My theory on Google and CSS ignorance

Tue, 18 Jan 2005 12:57:59 -0400

I am currently conducting an experiment to prove whether the use of CSS unordered list elements to display your page navigation prevents the discovery of the pages it refers to.

I launched two sites a month ago: one was the cflunch.com site which has regular href tags to refer to the other pages in the site; the other site was Pittman Guitar Repair which has no inline hrefs on the front page with unordered lists being used with hrefs as the list items to provide site navigation and sub-navigation.

Since launch, Google has happily discovered the front page of each site but for the guitar site, it has stopped indexing at the front page, like it doesn't recognize the hrefs embedded in the unordered list. The CFLunch site has been fully indexed by Google during the same period so I have a clear benchmark.

Here is the list in question:

<ul id="navtext">
<li><a href="index.cfm?mode=entry&entry=100C098D-9E1D-2003-099BBC48283D5826">HOME</a></li>
<li><a href="index.cfm?mode=entry&entry=0FF1DA5D-029D-BE39-CCB5D59ED056BAE2">ABOUT US</a></li>
<li><a href="index.cfm?mode=entry&entry=BEAE0EAD-D610-A6A8-65B5137E3A88990B">PHOTO GALLERY</a></li>
<li><a href="index.cfm?mode=entry&entry=0FF7E695-B3B8-C5B4-46DFD11113F433AB">TESTIMONIALS</a></li>
<li><a href="index.cfm?mode=entry&entry=0FF9695D-95BD-6065-DA4B9670F449E7A2">REPAIR TIPS</a></li>
<li><a href="index.cfm?mode=entry&entry=F2482C7E-07BC-2494-5D2E849583584719">CONTACT US</a></li>
<li> </li>
</ul>

Two days ago I decided to switch from the use of the unordered list of hrefs on the guitar site and am now eagerly awaiting the return of Google.

Here is the new format:

<div id="newNav">
<a href="index.cfm?mode=entry&entry=100C098D-9E1D-2003-099BBC48283D5826"> HOME</a><br>
<a href="index.cfm?mode=entry&entry=0FF1DA5D-029D-BE39-CCB5D59ED056BAE2"> ABOUT US</a><br>
<a href="index.cfm?mode=entry&entry=BEAE0EAD-D610-A6A8-65B5137E3A88990B"> PHOTO GALLERY</a><br>
<a href="index.cfm?mode=entry&entry=0FF7E695-B3B8-C5B4-46DFD11113F433AB"> TESTIMONIALS</a><br>
<a href="index.cfm?mode=entry&entry=0FF9695D-95BD-6065-DA4B9670F449E7A2"> REPAIR TIPS</a><br>
<a href="index.cfm?mode=entry&entry=F2482C7E-07BC-2494-5D2E849583584719"> CONTACT US</a><br>
</div>

To check the progress, take a peak at this Google Search and compare it to this Google Search.

We have examples of the unordered list being used successfully elsewhere here at Duo Consulting but I believe that the spiders are finding regular inline hrefs to make their way through the site. I'll write a follow up when I have some evidence either way.

Yahoo! Does CSS

Thu, 30 Sep 2004 18:34:05 -0400

Yahoo! has a CSS front page in Beta mode. Thanks to Jeff from work for the link to WhiteSpace where they dig deep into the high and low points of the redesign. One of the most interesting points for me in the article comes from the comments where Rimantas explains precisely when it is appropriate to include an external css (and presumably js) file versus including it inline. I didn't realise that it is as simple as the size of the css or js chunk. Simply put: over 500 bytes including whitespace put it in a separate file else include it on the page. Why? 500 bytes is all that is required for a request to determine from the header if the page has changed. If your CSS/JS is larger than that you save {filesize_in_bytes-500} bytes per request thru this mechanism. To verify that this is the case I was looking around and found an excellent reference on page caching with HTTP requests by Mark Nottingham. I scanned through the RFC2616 to try to get to the bottom of the max HTTP header size but couldn't find it anwhere. If anyone could provide a reference for me that would be great.