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:
- “size” of data entry fields
- “specialized” data entry fields
- “size” of sidebar fields
- “eligibility” fields
- “settings” fields
- “case list” fields
- “alternating table rows”
- “masked form” fields
- “calendar rows”
- “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?
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 
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, 
First, be sure to 
The CSS information provided by Firebug is nutrient dense, to the max: You can see immediately all the 
