In late December, after posting an earlier version of this post, I realized I was going about this aspect of Project Grace all wrong, so I pulled that original version, a post about “Basic CSS page layout.” There was nothing wrong with the post, but I realized I was drifting toward just repeating myself, essentially a “remastered” series of articles I wrote, quite demonstrably with less knowledge about Pika than I have now, when building Project Claire.

But there were some deeper problems and challenges for me. As I moved ahead with the challenge of doing another CSS makeover of Pika, I was forced to realize (again) that there are really, really severe limits to what one can do with the CSS “presentational” characteristics of Pika because it still labors under a near-decade of seriously dated legacy markup. (In fairness, when we looked at competing CMS options a few years back, all the other developers suffered from this same shortcoming.) While Pika Software did make a serious effort in version 3.06 to clean out embedded and inline styles, with something like a 40-50% uptick in external CSS coding (a good thing), a huge amount of inline styles remain (a bad thing). Pika still relies predominantly on “tables” to control layout and positioning of page elements, which is a good thing for backward browser compatibility and therefore brings a level of presentational predictability in production software. I totally get that. But otherwise it totally sucks.

This is a two-fisted combo that seriously prevents doing much of anything creative with Pika presentational characteristics. Why? Well, inline styles always trump the external style sheet. That’s how CSS works, so your stuck with whatever styles Pika Software embeds inline. And reliance on tables severely constricts the positioning of page elements. Basically, you’re stuck with the Pika default page layouts unless you are prepared to go in and rebuild your templates to conform to more current web standards, something we did with Project Claire, as best as we could at the time.

The other factor that triggered the change in how to approach Project Grace was a meeting Mark Sawyer and I had with some folks from East Bay Community Law Center, who soon will adopt their first CMS ever, namely, Pika 3.06. And I think it is fair to say they’re feeling overwhelmed. (Whew, way understandable to anyone who’s ever been through the process.)

It was during that meeting I got the idea to take the current version of Pika and do simply what I talk about above, i.e., quite literally rebuilding all the Pika templates and subtemplates, regrettably but of necessity still relying on the deeply embedded tables-based layout structures, while removing all the inline styles that remain in the markup. And then modifying minimally the PHP files essential to dynamically generating other specific Pika page markup, principally markup generated dynamically by pika_cms.php and pikaMisc.php. And then creating a totally custom CSS style sheet, all of which works with a default Pika installation. No changes in how Pika works out of the box. No changes in Pika default workflow. Just better, more flexible markup in the templates, some essential tweaks to a few PHP files to get other markup to display correctly, and a fresh coat of paint for the whole shebang via a custom CSS style sheet. And something one could simply upload to the /pika-custom and /css subfolders in one or two fell swoops.

The goal would be to conjure up a simple, clean, low-contrast, uncluttered design refresh. That’s the theory, anyway. So, with Aaron’s recent announcement that Pika 3.07 will be released in another week or so (and Pika 4.0 put off to later this year, at the earliest), the Project Grace approach has changed: Once version 3.07 hits the street, LSNC will set up three Pika 3.07 test beds: first, a virgin reference install; second, an “East Bay” install to build a new set of default templates with a custom CSS style sheet, as described above; and third, a long-form install where we can work on a more radical rebuild to incorporate all latest, way cool Pika Software modifications into all the existing LSNC customizations, something that may take us the better part of six months or so to complete.

What I will be doing here at Webdogs 2.0 is reporting on progress of the second and third installs. Rather than do long-form tutorials, as I have been doing, what I will do is post the rebuilt templates and the custom “East Bay” CSS to PikaDocs in the California Customizations section. These two installs will most definitely be works in progress. The files posted to Pikadocs will inevitably be added, edited, supplemented, and/or deleted depending on what’s happening as the work goes forward. Most likely, I will post select additions to the Project Grace series here to detail distinctive elements of the templates or CSS designs.

Want an early taste? Take a look at the initial set of 21 screenshots of the “East Bay” design now posted to PikaDocs.

Other posts of possible interest...

• Elaborating some on global reset and global styles
• Project Grace 03: Rebuilding the CSS from scratch
• Project Grace 02: Basic HTML and CSS deconstruction
• Project Grace launches. Really.

But I am mindful of the broader implications of using a global reset, i.e., there are any number of other web browsers or viewers that may be used with your public web content, which is why I referred to Eric Meyer’s au courant article, Reset Reloaded. My current practice for building out CSS on newer public web projects here is to use a modestly trimmed-down version of Eric Meyer’s code, consistent with those structural elements we actually would use in an XHTML 1.0 Strict build, combined with certain “Webdogs” global style defaults.

So, for the record, here are the more nuanced CSS global reset and initial global styles we currently use on all new website builds, with notations:

/*
global resets based on Eric Meyer's "Reset Reload" at
http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
 */

html, body, div, span,
h1, h2, h3, h4, h5, h6, p, pre,
a, code, em, font, img, strong, sub, sup,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
    margin: 0;
    padding: 0;
    border: 0;
    outline: 0;
    font-weight: inherit;
    font-style: inherit;
    font-size: 100%;
    font-family: inherit;
    vertical-align: baseline;
    }
/* remember to define focus styles! */
:focus {
    outline: 0;
    }
body {
    line-height: 1;
    color: black;
    background: white;
    }
ol, ul {
    list-style: none;
    }
/* tables still need 'cellspacing="0"' in the markup */
table {
    border-collapse: collapse;
    border-spacing: 0;
    }
caption, th, td {
    text-align: left;
    font-weight: normal;
    }

/*
global resets per Webdogs defaults;
font-size set per Clagnut's "How to size text using ems" at
http://clagnut.com/blog/348
*/

body {
    color: #333333; /* reduced contrast black */
    font-family: verdana, arial, sans-serif;
    font-size: 62.50%; /* resets 1.0em = 10px */
    line-height: 1.50; /* reset leading for readability */
    }
a:link,
a:visited {
    background: transparent;
    color: #333333; /* reduced contrast black */
    font-weight: bold;
    text-decoration: none;
    }
a:hover,
a:active {
    color: #0000FF; /* blue */
    }

/* prevents inherited shrinkage in Firefox per Clagnut at:
http://clagnut.com/blog/348/ */
li li,
li p,
td p {
    font-size: 1.0em
    }

/* for Firefox where page content < viewport height,
per Zoe Gillenwater's "Create Pages that Fill the Browser with CSS" at
http://www.communitymx.com/content/article.cfm?cid=BAD95
 */
html,
body {
    margin-bottom: 1px;
    min-height: 100%;
    }

Since this is the type of CSS code one is likely to use over and over, consider putting it into a separate style sheet and then use an import rule to pull it into your overall styles for the site. Just a thought.

Other posts of possible interest...

• Project Grace 03: Rebuilding the CSS from scratch
• Project Grace 02: Basic HTML and CSS deconstruction
• Project Grace launches. Really.
• Project Grace 04: “East Bay” 21 Screenshot Salute!

The first two articles in the Project Grace: Pika Reloaded series were an introduction to several common basic web design development tools, most notably the Firebug extension for Firefox. In practice Firebug has largely supplanted most of the other web design diagnostic tools I had long relied upon, such as the Web Developer Toolbar and the View Source Chart extension.

For example, in the past I often used the View Source Chart extension to generate a wonderfully useful visual display of the underlying HTML page structure. For a Pika-specific example of how View Source Chart works, take a look this visual chart of the Pika Home Page. This type of visual chart is especially helpful in building CSS code since it provides a handy-dandy visual list of all the page elements, their specific id and class attributes, and an easily understood structural hierarchy revealing where the page elements are relative to each other, i.e., which are structural parents, children or siblings. But the ease and convenience of Firebug has changed my web design work habits a lot. Now what I more often do is simply activate the inspection window in Firebug, click on the particular page element I am curious about and go from there, as needed, to diagnose what ails me about the web page design. Which is how I will proceed for the most part as I rebuild the Pika CSS from scratch for Project Grace.

In this article I will briefly explain three things:

• where the default CSS code in Pika 3.06 is located and how it is organized;
• how to edit the head tag in the default.html template to remove the default link tags that call the Pika default style sheets and substitute new ones, so you can start from scratch and rebuild the CSS from the ground up with your own custom style sheets that will work in both Firefox and Internet Explorer; and
• add the first bit of CSS to your style sheets by doing a a “global reset” so that your new CSS code will behave more predictably in both Firefox and Internet Explorer.

How the default Pika CSS code is organized

In a standard web page, one or more external style sheets in the form of CSS files are linked to the web page by using a link tag embedded in the head element of the page. Pika 3.06 accomplishes this by linking the default styles via the screen.css.php file located in the /pika/css subdirectory. View the source code for any Pika page and you’ll see it linked in the head tag at the top:

<link href="/pika/css/screen.css.php" rel="stylesheet" type="text/css" />

The screen.css.php file contains 500+ lines of CSS code. If motivated, you can view the default Pika CSS code. If you do take a quick look-see at the default Pika CSS, you’ll notice that is ordered this way:

• Basic structural markup elements (e.g., a ... body ... div, etc.) listed in alphabetical order, followed by …
• id selectors and their descendants (e.g., #auth_label ... #auth_label a ... #bottom_searchbox, etc.) listed in alphabetical order, followed by …
• class selectors and their descendants (e.g., .de select ... .de input, etc.) clustered into the following 10 categories:
  1. “size” of data entry fields
  2. “specialized” data entry fields
  3. “size” of sidebar fields
  4. “eligibility” fields
  5. “settings” fields
  6. “case list” fields
  7. “alternating table rows”
  8. “masked form” fields
  9. “calendar rows”
  10. “case notes” text format

As we step through the rebuilding of the CSS code, I am going to suggest a different approach for organizing the CSS code. But for now, let’s do some damage.

Creating a custom set of Pika style sheets

The first step I suggest for creating your own custom styles for Pika from scratch is to summarily drop-kick the screen.css.php file out of the mix entirely. To do so, edit the head tag at the top of the default.html template to substitute a new set of link tags that pull in your new styles from three core sources: a “custom” CSS file for your new default Pika styles; one or more IE conditional comments so you can create CSS code that targets only Internet Explorer (for this exercise, I will include one global IE conditional comment; you could add others as suit your needs); and a separate “print” styles sheet that controls how Pika pages print out from within your web browser.

For this stage of Project Grace, here’s what the new head tag looks like with all the new link tags added:

<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Pika: %%[page_title]%%</title>
<link rel="icon" href="%%[base_url]%%/favicon.ico" />
<link rel="shortcut icon" href="%%[base_url]%%/favicon.ico" />
<link rel="stylesheet" type="text/css" href="%%[base_url]%%/css/hub.css" />
<!--[if IE]>
<link rel="stylesheet" type="text/css" href="%%[base_url]%%/css/ie.css" />
<![endif]-->
<link rel="stylesheet" type="text/css" media="print" href="%%[base_url]%%/css/print.css" />
</head>

Since these newly linked style sheets have not even been created yet, with these changes made to the default.html template what you will see is a Pika Home page (and other pages) stark naked, i.e., a completely unstyled page.

Create the three new (albeit empty) style sheet files — custom.css, ie.css and print.css and put them into your /pika/css/ subdirectory.

Now you’re ready to dive in with your first Pika custom CSS by performing a hold-on-to-your-butt CSS “global reset.” What’s that you, say? Read on!

Creating a “global reset” for the Pika CSS

Before re-applying any real “styles” to this newly naked Pika page, I want to do a CSS “global reset.” That phrase originates with Andrew Krespanis’ 2004 article Global White Space Reset, the basic theory of which has been famously regranulated by Eric Meyer, the godfather of all things CSS, in his more recent article Reset Reloaded (May 1, 2007). You can review those articles to go deep on the theory.

In an earlier version of this article I suggested doing a blunt-force “reset” by using the asterisk universal selector to reset all margins and padding for all HTML elements to zero. That works, and it is a very common web design approach, but upon further reflection I have decided to rewrite this subsection of the article to promote using a more nuanced global reset, based on Eric Meyer’s model and one that with minor changes I actually use in practice.

The global reset proposed here is essentially the same used here (with some variations) at Webdogs 2.0, as are the added set of initial global styles to control the default appearance of the body, anchor and list item tags. I also am adding a initial global style for image tags to get rid of the border that appears by default in some browsers (including Firefox).

Here’s the whole, initial chunk of CSS code being added to the custom.css. file, with annotations highlighted in yellow:

/*
global resets based on Eric Meyer's "Reset Reload" at
http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
 */

html, body, div, span,
h1, h2, h3, h4, h5, h6, p, pre,
a, code, em, font, strong, sub, sup,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td {
    margin: 0;
    padding: 0;
    border: 0;
    outline: 0;
    font-weight: inherit;
    font-style: inherit;
    font-size: 100%;
    font-family: inherit;
    vertical-align: baseline;
    }
/* remember to define focus styles! */
:focus {
    outline: 0;
    }
body {
    line-height: 1;
    color: black;
    background: white;
    }
ol, ul {
    list-style: none;
    }
/* tables still need 'cellspacing="0"' in the markup */
table {
    border-collapse: collapse;
    border-spacing: 0;
    }
caption, th, td {
    text-align: left;
    font-weight: normal;
    }

/*
global resets per Webdogs defaults;
font-size set per Clagnut's "How to size text using ems" at
http://clagnut.com/blog/348
*/

body {
    color: #333333; /* reduced contrast black */
    font-family: verdana, arial, sans-serif;
    font-size: 62.50%; /* resets 1.0em = 10px */
    line-height: 1.50; /* reset leading for readability */
    }
a:link,
a:visited {
    background: transparent;
    color: #333333; /* reduced contrast black */
    font-weight: bold;
    text-decoration: none;
    }
a:hover,
a:active {
    color: #0000FF; /* blue */
    }

/* prevents inherited shrinkage in Firefox per Clagnut at:
http://clagnut.com/blog/348/ */
li li,
li p,
td p {
    font-size: 1.0em
    }

/* use PRN on DIVs for clearing floated elements,
per Position Is Everthing at
http://www.positioniseverything.net/easyclearing.html */
.clear-fix:after {
    content: ".";
    clear: both;
    display: block;
    height: 0;
    visibility: hidden;
    }

/* for Firefox where page content < viewport height,
per Zoe Gillenwater's "Create Pages that Fill the Browser with CSS" at
http://www.communitymx.com/content/article.cfm?cid=BAD95
 */
html,
body {
    margin-bottom: 1px;
    min-height: 100%;
    }

With this CSS code added, the Pika Home Page still looks pretty naked but now has a few visually distinct characteristics wrought by the new CSS, although the basic positioning or layout of the page elements remains the same. Let’s break it down.

Explaining the first chunk of the Project Grace CSS code

The global reset has already been explained, above. Here’s a brief explanation of how the other new CSS code affects the Project Grace styles at this stage, starting with the initial presentational characteristics for the body element:

body {
    background: #FFFFFF;
    color: #333333;
    font-family: verdana, arial, sans-serif;
    font-size: 62.50%;
    line-height: 1.50;
    }

The body element is reset this way so that the background is white (#FFFFFF), the color of text is set to a lower contrast black (#333333) to enhance readability, and the basic font-family style is declared (verdana, etc.). The font-size is set to 62.5% to make it easier down the road to set alternate font sizes for other page elements that inherit this value from the body element. (For those who want a preview of the explanation for resetting the font-size this way, take a look at Richard Rutter’s highly influential article How to size text using ems. And for even more on this topic, you may want to read Richard Rutter’s more recent article published at A List Apart in which he updates his take on other approaches to assure cross-browser consistency in how text size displays. Here, I’m going to go with what I know until I can digest his latest musings on this subject.)

The line-height value is set to 1.50 to make the text, again, more readable. (Typographers refer to this as leading or line spacing). If you’re wondering what’s up with the “unitless” value for line-height, I refer you to Eric Meyer for the explanation. Me, I just do what Eric Meyer tells me to do. You would be wise to do so also.

Here is how the anchor tags are styled at this early step in Project Grace:

a:link,
a:visited {
    background: transparent;
    color: #333333;
    font-weight: bold;
    text-decoration: none;
    }
a:hover,
a:active {
    color: #0000FF;
    }

The anchor or “link” tags are set exactly as they are here at Webdogs 2.0. The declared values for the CSS properties override any browser defaults for displaying linked text by establishing their default color as the same used in the body tag, but in bold so that they stand out against a transparent background (assuring that the background of any other page element shows through), without any text-decoration to get rid of the “underline” displayed by default for anchor tags in all browsers, and a “hover” state that changes the linked text to blue (#0000FF).

Why do it this way? In my judgement it is a mixture of both design and readability issues, the thought being that removing text-decoration makes actual reading of page text with links easier. We have been doing this for years at both LSNC.net and, of course, here at Webdogs 2.0 without any complaints or apparent confusion by users. None. Experience tells us it works and is actually more user friendly. (Needless to say, others would beg to differ.)

Because list item tags are the semantically correct way to build not only actual lists of things on web pages but also itemized horizontal and vertical elements, such as horizontal navigation and sidebar menus, the default for ordered and unordered list items is reset to not display any list-style, such as a bullet or disc:

ul, ol {
    list-style: none;
    }

To get rid of the blue border that appears by default around image tags in some browsers, you do so by globally nukin’ it with a none value:

img {
    border: none;
    }

Finally, one common problem associated with different browsers is how they deal (or do not deal) with inheritance of font-size from some parent elements to some embedded child elements. This is a problem of inherited shrinkage triggered by the cascade effect of CSS that occurs inconsistently among browsers. Anyone who has had to tweak font-size to address inconsistencies in the text size of a sublist of item children embedded within a parent list knows of which I speak. Aaaaargh! To deal with that problem not only with list items but also paragraphs that are the children of parent list items and table data cells, the following CSS code is used:

 /* prevents inherited shrinkage */

li li,
li p,
td p {
    font-size: 1.0em
    }

Alrighty, now! True, the Pika Home Page doesn’t look like much at this early stage of CSS tweakery. But a solid “reset” foundation is in place as we stage for more visible changes to come. Reason enough to return for Project Grace 04, wouldn’t you say?

The Whole Enchilada: Project Grace: Pika Reloaded

Other posts of possible interest...

• Elaborating some on global reset and global styles
• Project Grace 02: Basic HTML and CSS deconstruction
• Project Grace launches. Really.
• Project Grace 04: “East Bay” 21 Screenshot Salute!

The first sacrificial lamb in support of Project Grace is, predictably, the Pika Home Page. Out of the box here is what that page looks like:

Understanding the underlying structure of the Home Page

Let’s do some basic deconstruction. Using the Web Developer Toolbar, select CSS > Disable Styles > All Styles. Now the Pika Home Page displays stripped of all its custom CSS presentational characteristics. What you see is how your browser by default displays the page’s HTML structural markup in the same order as the markup appears in the “flow” of the underlying web page:

Looking at this page “naked,” even without looking at the actual markup behind the page display, those familiar with basic web page design will notice that the underlying structure of the page relies on tables, rather than CSS, to control the basic layout of the page. The three apparent columns in the middle (“Frequent Tasks,” “Message Board” and “Learn to Use Pika”) are dead give-aways. Again using the Web Developer Toolbar, to confirm this observation select Outline > Outline Tables > Tables, revealing that the page uses a table at the top for the “header” area, below which is a second table for the “middle-content” area:

To see the table cells that control the three columns in that middle-content area, select Outline > Outline Tables > Table Cells:

Since this stage of Project Grace is an attempt at a benign CSS makeover of the default Pika 3.06 presentational design, I will refrain from my usual rant about the misuse of tables to control page layout this way. At the very least it is not optimal. It’s OK and it works and, admittedly, it assures backward compatibility with now generations-old web browsers. But with the advent of increasingly CSS-standards compliant browsers, including IE7 (much improved) and Firefox 2.0 (way better), such design approaches are increasingly harder to defend. But I digress.

The final structural piece is the page “footer” at the bottom. To see what that’s all about, let me show you three ways to Sunday using three different tools to figure out that bit of markup.

First, make sure you have refreshed the Pika Home Page to get rid of the any earlier selections you made using the Web Developer Toolbar and you can see the default Pika page design again. Good to go? Now select CSS > View Style Information. Then scroll down to the bottom of the page where the “footer” is located and hover — but don’t click — your mouse (which changes into a cross-hair) over that area so that it is highlighted with a thin red border:

If you look up at the Web Developer Toolbar, it has opened a new information box immediately below the toolbar itself, revealing the underlying structural hierarchy for the highlighted page element, including the name of any id or class attributes:

(I will explain below what else happens when you click on the page element using this feature.)

Second, try using the XRAY bookmarklet. Click on it and then click on the footer area at the bottom of the page. (You may need to experiment with where you click to get results for the entire footer element, rather than other elements embedded within it.) The XRAY box displays basic information about that page element: It’s a div with an id attribute named “footer” and the inheritance hierarchy is html > body > div, all essential and useful information for working with CSS:

Third, let’s give Firebug a shot at this. Activate Firebug and in the Inspection window pane select “HTML” and then “Inspect.” Hover your mouse over the footer area to assure you have selected the whole footer area (you will see the blue border change so you can see which area is active within the Firebug inspection window), and then click the area to select it:

In the left pane you will see the “footer” div highlighted, as well as the structural hierarchy of that page element revealed, i.e., html > body > div.

Locating the CSS code

Here are a few ways to figure out where the CSS code is for any Pika page:

Be sure to close out Firebug and refresh your browser window. You should be back to the default Pika Home Page design. Using the Web Developer Toolbar, select CSS > View CSS. This triggers a new page listing all embedded CSS styles followed by the file location and contents of all external CSS styles affecting the presentational characteristics of the page. (As far as I can tell, this feature in the Web Developer Toolbar does not reveal inline CSS styles.)

When you invoke this feature, you’ll see that all the basic CSS code is located in the Pika CSS subdirectory at /pika/css/screen.css.php. Conveniently, the CSS file location is linked so you can open up the CSS code into a separate web page for review. For locating the CSS code specific to a particular page element, select CSS > View Style Information and then click on a page element. For example, if you click on the footer element discussed above, you will see the CSS code illustrated to the left.

Another way to go is to use Firebug to locate the CSS file location and the CSS code that relates to any selected page element. I am not going to repeat so much how that works, detailed here in the prior article. Suffice it to say that if you invoke Firebug and from the inspection window select HTML and Inspect, and then click anywhere on the page, you will see in the right pane the corresponding CSS code and where the file is located containing the code, illustrated here to the right and highlighted in yellow. The CSS file location is clickable, so if you want to get the whole CSS enchilada, not just the code for a particular element, go ahead and click it and Firebug opens up the whole CSS file in the Firebug window. Nice.

The effort here has been to suggest several different ways to deconstruct Pika pages to give you the basic information you need to restyle its pages elements. On balance, I prefer using Firebug for both the HTML and CSS excavation processes described above. But that’s me. There is more than one route to the mountain top and you now know where several of those paths are to your innner HTML and CSS geek.

You’re oriented. You’ve got a handle on the basic structural markup of a Pika page. You know where the CSS code is located. You know how to zone in on the CSS code for any particular page element using various web developer tools to extract that information. Time now to do some Pika CSS style rebuilding, the whole point of this first stage of Project Grace. Onward to Project Grace 03: Rebuilding the CSS from scratch!

The Whole Enchilada: Project Grace: Pika Reloaded

Other posts of possible interest...

• Elaborating some on global reset and global styles
• Project Grace 03: Rebuilding the CSS from scratch
• Project Grace launches. Really.
• Pika 3.06 ~ CSS Matrix: Once more, with feeling

And before we launch directly into rebuilding the styles for Pika 3.06, I thought to offer an overview of a few web development tools that are extremely helpful and fairly easy to use for figuring out what is going on with a given web page’s structural markup and the CSS code controlling its styles. To that purpose, I discuss here four particularly useful tools for HTML and CSS diagnostics available for use within the Firefox browser:

• Firebug
• MRI bookmarklet
• XRAY bookmarklet
• Web Developer Toolbar

Firebug

There is no question that the Firebug browser extension for Firefox is the web developer tool I will rely on most for Stage One of Project Grace. The name Firebug is true to its purpose: It is a remarkable and easy-to-use web page debugging tool you can invoke with a few mouse clicks directly from within your Firefox browser window to easily and visually deconstruct any web page. At the same time you get immediate access to the underlying HTML, CSS and JavaScript code so you can better understand how the page is built and what the underlying HTML, CSS and JavaScript code are doing (or not doing) when the page loads. It is not the first web page debugging tool to hit the web developer world. But is by far the first to make debugging HTML, CSS and JavaScript code in a given web page this easy to do, and in a way that makes the tool authentically easy to use even for non-professional web designers. You know. Like most of us.

My intention here is not to reinvent the tutorial wheel. If you are new to Firebug, it is easy enough to find a basic introduction to Firebug; any number of longer-form Firebug tutorials; even a long-form “Welcome to Firebug 1.0″ video by its creator Joe Hewitt. Get your Firebug orientation, as you need.

Rather, my goal here is more modest, just to get you up and running and in the swim with Firebug to assure you can follow along as its use is illustrated in the Project Grace articles to come. So, for Firebug newbies, here is one way to get your Firebug on:

First, be sure to install Firebug in your Firefox browser. After installing it, completely close out and then restart your Firefox browser (as you would with any newly added Firefox extension). You need to “enable” Firebug when you first use it. To do so, click on the green circular icon with the white check mark located in the lower right-hand corner of your browser, on the far right of the status bar, as illustrated. This triggers a dialog window inviting you to enable Firebug. Do so.

You’re good to go. You should now see the Firebug “inspection” window. Click on the “Inspect” tab and watch the magic, as you hover your mouse over parts of the web page displayed in the window above the Firebug inspection window. As you hover over any element on the web page, Firebug highlights the element with a blue border in the web page above, while highlighting the corresponding HTML structural markup in the Firebug window below. On the right side of the Firebug inspection window, you will also see a separate window detailing the CSS “Style” code and the spatial “Layout” affecting the display of that same element. Here’s an example using Webdogs 2.0 of what is displayed if you hover your mouse over the Webdogs 2.0 logo at the top of the page:

Give it try here at Webdogs 2.0. Open the Firebug inspection window and hover over the Webdogs 2.0 logo image, as illustrated above. Click on the logo image. Here’s what you’ll see on the left side of the Firebug inspection window, with the markup for the Webdogs 2.0 logo image element conveniently highlighted in blue:

You can immediately see in the left pane of the Firebug inspection window where that page element is located in the flow of page HTML markup, plus its corresponding attributes.

On the right side of the Firebug inspection window, you can also see all the CSS code affecting the presentation or display of the Webdogs 2.0 logo:

The CSS information provided by Firebug is nutrient dense, to the max: You can see immediately all the CSS selectors (e.g., #banner img); the corresponding properties for each selector (e.g., float:left; and so on) affecting the dispay of the page element; and the location of that particular bit of CSS code (e.g., style.css at line 101). But wait … there’s more! Scroll down and you will see examples of other bits of CSS code that are inherited from other parts of the cascade (e.g., the styles affecting the display of the anchor tags that makes the image a clickable link), as well as other inherited style elements that have been trumped by other, more specific parts of the CSS code (e.g., the color values affecting anchor tags elsewhere in the page design). If that were all Firebug did, that would be plenty. But it does tons more things you’ll discover as you play with it.

MRI and XRAY bookmarklets

Sometimes using Firebug is akin to using a shotgun when a fly swatter would do the job just fine, thank you very much. In that spirit, allow me to suggest you try the XRAY, a handy bookmarklet that enables you to quickly see how the box model is affecting the display of any page element. Again, to illustrate using Webdogs 2.0, click on the XRAY bookmarklet, which triggers a smoke-colored “Welcome to XRAY” window. Click on the Webdogs 2.0 logo image and you get a chock-fulla display of information about the spatial layout of that particular page element:

Not only is this a great way with a single click to get a lock on the basic dimensions (height, width, margins and padding) of a page element and its positional characteristics (e.g., the element is a “float”), it is the quickest way I know to determine whether an id or class attribute has been added to the element, and what is the inheritance heirarchy affecting the element — all useful information for locating or establishing related CSS coding in the style sheet.

The MRI bookmarklet does something similar but different: Click on the MRI bookmarklet and then enter a selector into the dialog box and it will find any page element that uses that same selector. It also works in reverse: You can see the page element on the page but want to know what selectors it uses. No problema. Click on the MRI bookmarklet and then click on the page element and the dialog box displays a list of suggested selectors affecting the display plus the structural markup heiracrchy. Other tools are better at this sort of thing or do it differently, e.g., Firebug (described above) and View Source Chart extensions. But the MRI bookmarklet is a nice quickie way to get this basic information, in a pinch.

Web Developer Toolbar

The Web Developer Toolbar is famously described as the Swiss Army Knife of web development tools. It has some 150+ functions and so it can seem overwhelming. If you are new to it you may find it helpful to read the Web Developer Toolbar Overview.

Over the last year or so Firebug has largely supplanted the Web Developer Toolbar as the “diagnostic” tool of choice for many because the former makes it easier to get to the source of and diagnose HTML, CSS and JavaScript code on a given page. But beyond the formidible, more user friendly “debugging” advantages of Firebug, the Web Developer Toolbar does a whole lot more things.

For Project Grace, here is a little used and little understood tool in the Web Developer Toolbar I use all the time: “Display Topographic Information.” You can find it about half way down the list of options under “Information.” I use the “Topographic Information” display primarily to get a “pseudo-grid” display of all the elements displayed on the page. Some designers use a background grid to evaluate the relative positioning of elements. I prefer to just use the topographic information display. With it, I can more readily see how page elements are positioned relative to each other, whether the elements display evenly (or not), and way more easily so than looking at the regular page itself, especially in a design like Webdogs 2.0 that relies on a lot of open, unbordered page elements and does not rely on rules or lines to orient the eye to the spatial relationship of those elements.

To illustrate my point, take another look at the home page of Webdogs 2.0. Regardless of how you feel about the overall design, the page elements look basically well-ordered, evenly spaced, no? Well, maybe. Maybe not. Using the Web Developer Toolbar, select “Display Topographic Information” and view the same page:

Ah! Get it? This “topogrpahic” layout of all the page elements actually makes it easier to see if the positioning of elements is consistent with the overall intended layout design. I get the advantage of a grid-like view of the page but with added topographic detail. And it helps me see whether a page element is too big or “pushing” or “obstructing” other elements, something that can be very hard to do, or simply impossible, by just deconstructing the CSS code in the abstract context of a style sheet.

OK people, now let’s get some real work done. Onward and upward to Project Grace 02: Basic HTML and CSS deconstruction!

The Whole Enchilada: Project Grace: Pika Reloaded

Other posts of possible interest...

• Elaborating some on global reset and global styles
• Project Grace 03: Rebuilding the CSS from scratch
• Project Grace 02: Basic HTML and CSS deconstruction
• Project Grace launches. Really.

Talk is cheap. Last June with Pika 3.06: Reloaded I talked up about Project Grace: The Pika Love Project, followed it up with a few initial experiments with Pika 3.06 table sorting, but then work on our next in-house iteration of Pika got stalled some. But Pika Software has given us a good kick in the butt to move forward again, with its recent release of the 2008 LSC CSR Module and the updated public demo of its latest Pika iteration that includes the new CSR module. (Want to try the demo? Login using “guest20″ for both the username and password. Enjoy!)

As we move ahead there may be more “stages” to LSNC’s next round of work on Pika but I can describe at least two of them here and now. Stage One of Project Grace should unfold fairly quickly over the next few months. It will be a modest series of lab tests to see how far we can push the default Pika 3.06 page layouts, page-element positionings and other presentational characteristics by working Pika’s newly implemented cascading style sheet (CSS) controls. Stage Two will go way deeper as we build a revamped and updated in-house version that incorporates all our customizations while exploiting the functional changes made by Pika Software in its latest version.

But back to Stage One and the new Pika cascading style sheets: What? You didn’t know that Pika Software had quietly changed how cascading styles operate in version 3.06? Neither did we until we started tinkering with them. Not to worry, the earlier-version danio.css style sheet and others are all still there in the default /css subdirectory and available for legacy Pika installations that need to fall back on the earlier presentation of page elements (as opposed to their structural markup) generated by the old CSS files and other styles embedded in earlier versions of HTML page templates and PHP code. You’re still covered, people! What Pika Software has done, and correctly in our view, is move more and more of the presentational characteristics of the application to external style sheets. In this latest iteration that translates into PHP coding that relies on the _screen.css.php file to handle all the basic style elements in this newest version. Where is the _screen.css.php file? It’s right there in the /css subdirectory with all the legacy CSS files.

With that clarification in hand, as we move through Stage One of Project Grace I will for the most part refer to the CSS-specific code lines in the _screen.css.php file to demonstrate how changes made there in the CSS coding can be used to add, remove, toggle and modify various presentational characteristics of Pika 3.06. The goal of Stage One is simply to learn where and how the current Pika 3.06 style characteristics reside and can be changed. I will not be changing any of the structural markup or page templates at this stage. I do reserve the creative prerogative to tweak a few lines of PHP code elsewhere within Pika should I discover it must be done to control the presentation where Pika Software has embedded a particular element’s style inline. Other than that, I will make every effort to avoid it.

Also, I will use this Stage One exercise to demonstrate a handful of Firefox-centric web development tools that may be helpful to others who are game to tool around and tweak their Pika styles, if not other things. One of my favorite sites, the How-to Geek has a post describing a slew of worthwhile Firefox web development tools. Here is a smaller, more limited collection of Firefox add-ons (including a few not mentioned in the How-to Geek article) and a few web development bookmarklets I will likely refer to or demonstrate in this series of articles:

• Firebug
• Web Developer Toolbar
• MeasureIt
• View Source Chart
• FireFTP
• MRI bookmarklet
• XRAY bookmarklet

You can do what we’ve done: Set up a test-bed default installation of Pika 3.06 that you can live with blowing up if it comes to that. Make sure you know where the Pika CSS subdirectory is and have FTP access so you can download and upload your file changes. Load up all the Firefox add-ons you need. Keep your favorite HMTL and CSS resource at hand for ready reference. And then keep your mouse up and your head down and let’s see how this all turns out.

“Project Grace: The Pika Love Project … A post a week. It’s all we ask.”

See you next week for the first chapter.

Other posts of possible interest...

• Elaborating some on global reset and global styles
• Project Grace 03: Rebuilding the CSS from scratch
• Project Grace 02: Basic HTML and CSS deconstruction
• Project Grace 04: “East Bay” 21 Screenshot Salute!