You either get it or you don’t. And if you do, you gotta get it:

Related to an earlier post today, we have also updated our annotated GSA open-source-CSS list of class and id selectors generated in GSA search results markup when using the Google Code open source GSA XHTML stylesheet. This CSS list is a bit better organized than our earlier version and includes about a half dozen additions. It is organized into the three basic portions of a GSA search result page: the form and navigation elements at the top; the search results themselves; and the portions of the page below the search results.

Hope this as helpful to others as we have found it to be. And please do comment if we have missed anything.

Recently we described how we built our GSA XSLT stylesheet to give us external CSS control over our search result page. A key element of that build was to rely on the open-source Google Code GSA XHTML Stylesheet, which is both way more web standards compliant and also makes it way easier to modify the XSLT so that you can generate search results without any embedded or inline styles.

The CSS styling or presentational characteristics of a search result page are, of course personal and particular to the designer who codes the CSS. But to make that process at least a touch easier, we’ve created a GSA open-source-CSS list of class and id selectors based on attributes generated in GSA search results markup when specifically using the open-source Google Code GSA XHTML Stylesheet. (This list of selectors will not work with the default GSA XSLT stylesheet.)

What we’ve done is carefully comb through the search result page markup, list all the CLASS and ID attributes in their order of page flow, annotated each with a description and then put them into a reusable CSS stylesheet that can be adapted for use new GSA frontends, as you will. Here’s an example:

Fairly straightforward stuff, but how many times over do you want to “view source” in your browser or invoke Firebug to recall the particular selector and attribute for, say, the definition list markup used in GSA search results? Seriously, unless you did it about 10 minutes ago, can you recall what the dd p.st span.rc a.f selector refers to on the search result page? We didn’t think so.

Here’s the full GSA open source CSS selector stylesheet.

Hope this helpful for those using the open source GSA stylesheet.

One of the more confounding challenges for those new to the Google Search Appliance (GSA) — at least for the XSLT-inexperienced such as ourselves — is figuring out how to build a search-results page such that one has 100% external stylesheet control. To be sure, the GSA includes a very handy “page layout helper” that provides interactive dialogs for creating a custom GSA “frontend” output page and/or search result page. One can use the page layout helper to incorporate your own custom header and footer markup, as well as add or exclude or modify a limited set of default GSA output page elements. Essentially, what the GSA native page layout helper does is provide a simple way to customize the underlying XSLT stylesheet without having to code directly in XSLT.

And as far as it goes, the GSA page layout helper is pretty handy. But what it is not so handy at is providing a way, without coding the XSLT directly, to give you complete, 100% external CSS control of how the search results display. True, you can add an external stylesheet link to the header markup you pop into the editor, but you are still stuck with all the native, embedded and inline styles that the GSA, by default, adds to the search results themselves. As those familiar with the order of importance in the cascade know well, inline styles trump embedded styles which in turn trump external styles. What’s a CSS coder who is not XSLT-savvy to do in this situation?

Here’s what we’ve done, in six (mostly) easy steps:

1. Build a design mockup of your search results page

The first thing we did is build a static XHTML page, with conventionally linked external CSS stylesheets, so that we had in-hand the markup we would fold in later to the GSA XSLT stylesheet. How you do this is entirely up to you. Here is a screenshot of our search-result page design. In this design, all the page elements at the top with a black background and to the right in the side-bar are what we will later add to the XSLT as part of the so-called “header,” described below. The markup that comprises the simple, light-gray footer at the very bottom will go into the “footer” section of the same XSLT. The “lorem ipsum” section of the markup in this mockup is just a placeholder, to show where the GSA search results will eventually appear.

2. “Process” your header and footer XHTML through the GSA page layout helper

This is akin to the “preparation” stage of cooking a recipe. What you need to do at this step is use the GSA page layout editor to convert the XHTML “header” and “footer” markup you created in the prior step, into a format that will play nice with the custom version of your GSA XSLT stylesheet described below.

To do that, login to your GSA admin panel, select “Serving” and then create a new GSA frontend. Click on the “Edit” link for the new frontend and then select the “Output Format” tab to display the Page Layout Helper. Click on “Global Attributes” and paste into the “Header” field all the XHTML code from the very top of your design mockup page (starting with the DOCTYPE) down to where the “header” markup ends. Do the same with your “footer” XHTML to the very end of the page markup (including the closing “body” and “html” tags) by pasting it into the “Footer” field. Click the “Save Page Layout Code” button, which prompts the GSA Page Layout Helper to process your markup and add it to the raw XSLT code.

You need to put your newly processed “header” and “footer” code to the side temporarily, for a later stage in this recipe. To do that, click on the “Edit underlying XSLT code” and then copy the raw XSLT code into your code editor of choice. Search for the line of code that begins and you’ll see that your header markup has been converted for use in the XSLT stylesheet. Copy everything between the opening and closing “my_page_header” template tags. Ditto, for the code between the “my_page_footer” template tags. Set these two code excerpts aside for a few minutes while you work on the next few steps. (Don’t worry about the default GSA XSLT stylesheet you just created, since it is going to be replaced, as described below.)

[Update: See the comments below, about the importance of assuring the header and footer XHTML "processed" via the GSA page layout helper are enclosed in each case by xsl:text tags.]

3. Download the Google Code open-source version of the GSA XSLT stylesheet

Download the open-source Google Code GSA XHTML Stylesheet. The advantage of this open-source XSLT stylesheet is that it offers a web-standards compliant version that generates well-formed, valid markup, something that natively generated Google pages are infamous for not doing. This open-source version of the GSA XSLT also makes it easier to modify the XSLT so that you can generate search results without any embedded or inline styles, and therefore subject completely to an external stylesheet. (A tip-of-the hat here to our GSA consultant, Michael Cizmar and his trusty sidekick Igor Taran for giving us the heads-up on this XSLT option.)

4. Edit the open source GSA XSLT stylesheet to turn off embedded and inline styles

Only two simple sets of edits are required to give you the external CSS style controls you want. The first is to edit the open source GSA XSLT stylesheet at line 67 to turn off embedded styles, by turning on external CSS styles; and at line 68 to provide a pointer to the specific directory (but not the CSS stylesheet itself) where your external CSS stylesheet resides.

Without modification, these two lines look like this:

<xsl:variable name="style_include">0</xsl:variable>
<xsl:variable name="style_include_prefix"></xsl:variable>

Modified for this example, the same two lines would look something like this, with the “style_include” set to true and the “style_include_prefix” set to the path of the external CSS stylesheet:

<xsl:variable name="style_include">1</xsl:variable>
<xsl:variable name="style_include_prefix">https://yourdomain.com/css/</xsl:variable>

The second edit is an optional edit. Sort of. At line 507 you’ll see this reference:

<link href="{$style_include_prefix}search.css" rel="stylesheet" type="text/css" media="screen,print"/>

Line 507 refers to the specific external CSS “screen” stylesheet that line 68 points toward. Actually, you can simply use that same “search.css” name for your external stylesheet, or change it to another name. It’s your call.

5. Edit the open source GSA XSLT stylesheet to add your custom “header” and “footer” template markup

Remember the processed XHTML “header” and “footer” template code you set aside, above? Here’s where you use it. In the same open-source GSA XSLT stylesheet, go to line 244 and add your processed “header” XHTML code and at line 248 add your processed “footer” XHTML code. The former goes between the “my_page_header” template tags:

<xsl:template name="my_page_header">
    <!-- add your processed xhtml here -->
</xsl:template>

And the latter goes between the “my_page_footer” template tags:

<xsl:template name="my_page_footer">
  <!-- add your processed xhtml here - -->
</xsl:template>

6. Substitute your edited version of the same XSLT stylesheet for the default GSA XSLT stylesheet

Now go back to the Page Layout Helper. If the XSLT code is not open for your custom frontend, click the “Edit underlying XSLT code” link, paste your edited version of the open source GSA XSLT stylesheet into the editor and then click the “Save XSLT Code” button to save your changes.

You should be good to go!

Now you can go to your external CSS stylesheet and change how any and all elements of your search results display, without any interference from GSA native embedded or inline styles.

It worked for us. After using {display:none} in the external CSS stylesheet to selectively hide some of the page elements in the search results page, and then tweaking the styles to get the results to display the way we wanted, we ended up with a very nice, customized look to our search results.

With the forthcoming, improved CSS-standards compliance in Internet Explorer 8 (still in beta), you’ll be seeing a lot of CSS articles like this: Everything You Know About CSS Is Wrong. The point being, that while using non-semantic table “markup” is bad for layout and positioning of non-tabular page elements, using CSS-based table “display” or presentational characteristics is semantically agnostic and a good thing. With IE8 now on board, all major browsers will support table display properties in CSS. TIAG!

This is a repost of an item I added this morning to the PikaDocs wiki. And it has to do with a very unexpected problem we encountered with the recent Pika 3.06 iteration, which implements code changes that unintentionally strip out IE conditional comments from the Pika default.html template. Needless to say, IE conditional comments are a widely adopted, all-but-standardized way to apply IE-only CSS code to control the design or display of web pages. And LSNC has long relied on custom IE-specific CSS code for its Pika redesign. What were CSS hacks like us to do about this dilemma?

Well, sure enough, those PHP-code ninjas over at Pika Software (Matt, to be specific) had the answer:

Open the pl.php file located in the your Pika subdirectory at /app/lib/pl.php. Carefully comment out lines 2055 and 2056 by preceding them with double-forward slashes so that it looks like this:

// $str = str_replace("<!--[", $tpl_prefix, $str);
// $str = str_replace("]-->", $tpl_suffix, $str);

Save the changes and upload the pl.php file to replace it. Now your IE conditional comments code will play nice with Pika 3.06.

With our organizational switch over to Gmail 2.0, we have been working on practical, advocate-friendly solutions that work with the updated Gmail 2.0 interface. The initial solutions a few days ago had to do with using Better Gmail 2.0 to give our users mailto functionality that works with our Google Apps, plus nifty new file-type icons and other goodies that come with that add-on package. Done.

The second part of the plan is to exploit the power and flexibility of the Stylish Firefox extension to perform a few modest cosmetic tweaks, while also offering users some options about what appears and does not appear in the new Gmail interface.

Here are the targets of our coding madness today — all real-world examples as of this afternoon from my Google Apps Gmail account — displayed here and familiar to all who are familiar with the default Gmail 2.0 interface, from top to bottom: the two search buttons, one for your Gmail and the other for a general Google search; the Labels menu with its new “color-code/edit-label” boxes to the right of (and partially obscuring) each label; and the indispensible Inbox, illustrated below, with a default design that makes it touch harder than it needs to be to read the labels in the message row:

So you’re asking yourself, “Yeah, I love Gmail. But do I have to live with all this blah design and extraneous stuff I don’t really want?” No, my friend, you do not.

The solution for today’s tech challenge is the Stylish add-on for Firefox. The short version is that Stylish enables you to easily change how things look in your Firefox web browser by simply invoking a new set of CSS rules that control the “presentation” or visual design of what you see, including web applications like Gmail. And there are truckloads of Stylish code bits already available for Gmail 2.0.

But it is even better than just loading someone else’s Stylish code. What you can easily do is cherry-pick a design idea or two from any of the many code samples already available and build your own custom Stylish code set. With a nod to ideas and code lifted shamelessly from Gmail: Inbox with new style and GMail Cleaner, plus a few original ideas for changing the look of Gmail labels in the Inbox itself (to make them easier to scan and more readable) and removing the “color-code/edit-label boxes” (so that they no longer obscure the already-too-narrow Labels menu), here’s how I did my own personal, quite modest makeover of the Gmail interface:

• Install Stylish (OK, you already knew that.)
• In Firefox go to Tools > Add-ons > Stylish > Options. That opens the “Manage Styles” dialog. Click on Write.
• Give your style a memorable name by typing it into the “Description” field. (“I Love Webdogs 2.0″ has a nice ring to it, but it’s your call.)
• Cut-and-paste (or download) the code below, put it into the large edit field below the “Insert” button and then click “Save.”

/*
Stylish code based in part on code and ideas from
"Gmail: Inbox with new style"

http://userstyles.org/styles/678

and "GMail Cleaner"

http://userstyles.org/styles/4118

 */

@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("mail.google.com")
{

/* remove web search button */
button[id="1fbh"] {display:none !important;}

/* create hover "row" effect for message lists */
table.N2mZ7b tr:hover,
table.tlc tr.rr:hover { background-color:#FFEB86 !important; }
table.N2mZ7b tr.rfza3e:hover,
table.tlc tr.ur:hover { background-color:#CDF39F !important; }

/* restyle how Labels display in message lists */
span.s75Nkf b { background-color:transparent !important; border-color:#C0C0C0 !important; }

/* remove "color-code/edit-label" boxes */
div.qn0D4e b b { display:none !important; }
td.BFvfre { display:none !important; }

}

What does this get you?

• You now have only one “Search Mail” button. The “Search Web” button is gone.
• When you hover your mouse over a message, the whole message row is now highlighted. Can you say, “Easier to scan and click”?
• The Label names still have a low-contrast appearance but the font and border style are easier to scan, plus the backgrounds of the labels are transparent. Can you say, “Easier to read”?
• The “color-code/edit-labels” boxes are gone, revealing more of the Labels menu. Can you say, “Well, OK, maybe I like that, maybe I don’t. I’ll get back to you.”

Don’t like something? Just remove or edit the offending CSS code. But you get the idea: Play with other folk’s Stylish code by installing any number of Gmail styles to get some useful ideas of what you like and then what you really want. Then cut-and-paste and recode and add code as suits you and create your own master Stylish code set.

To coin a phrase, “It’s all good.”

A few days back I illustrated use of a blunt-force global reset as part of the most recent step in Project Grace. I relied on this purposefully blunt approach to make the perhaps overly dramatic point that resetting all margins and padding for all structural elements significantly simplifies the process of building out one’s CSS for use in most all browsers. And the blunt approach is especially effective for something like a closed, secure Pika installation because it is highly unlikely your actual users (not necessarily your resident IT geekmeisters) rely on any browser other than Firefox or Internet Explorer. We certainly don’t here at LSNC.

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.

Where we’re going with the Pika CSS

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

Consider this article “basic orientation.” The focus here is to detail how to get a handle on the basic structural design of a Pika page and where the cascading style sheet (CSS) code resides within the current version 3.06 of Pika. I will rely on some of the web developer tools described in Project Grace 01: Get your Firebug on to demonstrate how to do that.

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