{webdogs 3.0}
site sentient since 2006Familiar with CSS sprites? Hey, there are mere-mortal, just-a-guy-doing-a-job sprites, and then there are sprites. Check out this single Google mega ( or better said, “meta”?) sprites image used at its new Music Beta site.
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:
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.
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
[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.]
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.)
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.
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>
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:
Tools > Add-ons > Stylish > Options. That opens the “Manage Styles” dialog. Click on Write./* 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?
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.
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:
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; andIn 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:
a ... body ... div, etc.) listed in alphabetical order, followed by …#auth_label ... #auth_label a ... #bottom_searchbox, etc.) listed in alphabetical order, followed by ….de select ... .de input, etc.) clustered into the following 10 categories:
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.
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!
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.
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?
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:
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.
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!
For starters, let it be known that we’re now calling it Project Grace: Pika Reloaded. We’re totally into Pika love, believe me. But the new project moniker just seems to say it better since the whole exercise is about taking all that core Pika goodness and “reloading” it with all the love goodies we can muster. So there you have it.
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:
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.
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.
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!
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:
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.
With a few more tweaks and a 100+ more entries, I have compiled a final version of the Pika 3.06 ~ CSS Matrix, with 238 entries sortable by HTML or PHP file name, markup tag; or id or class attribute.
And the point is…?
The first point was the original point, namely, to play with creating a sortable table. To coin a phrase, “mission accomplished.”
The second point was to go through the exercise of deconstructing what was done with Pika 3.06 to remove embedded styles from the application. It was fairly easy to do. With the Pika HTML templates, all it took was setting up a few basic search queries for character patterns that would lock in on id and class attributes in the structural markup. All I did was go through each of the HTML template files, do the queries, and plopped the results in the CSS Matrix table. In each instance, it only took a few minutes. Culling this same information from the PHP files was a little more demanding because my initial queries revealed how deeply and widely the Pika PHP files have so may pockets of code with embedded tags and attributes that are legacy or commented out or whatever, with no real connection to the current default Pika CSS files. So I took a different tack: I worked backward from the CSS files, searching the PHP files for any attribute referenced in the style sheets. This simplified the search to tags embedded in the PHP files with attributes with a connection to reality, i.e., ones affected by the CSS code in the danio.css and other style sheets. For purposes of the CSS Matrix, any other attributes were irrelevant. The 238 entries listed are all the ones I could find.
The third point is where I am going with this as part of LSNC’s various Pika test beds. We currently have four Pika installation:
One of the first sets of tests we will be doing with Pika 3.06 is to test out its new custom template functionality so that we understand how it works and can get comfortable with it. As part of that we will be using the CSS Matrix as one of the tools to mess with the Pika styles. It will be fun to see how hard we can push the boundaries of the presentational characteristics of Pika out of the box, only using the Pika style sheets. That’s where the CSS Matrix comes into play.
We’ll get back to you about that in a few weeks, provided the patient survives our tinkering.
I have adapted the same sorting script used in the earlier demo to mock up a functioning sortable Pika Case List table. This second demo provides a concrete example of how Brian McAllister’s tablesort script works with a few other table data types common to a Pika search-result list. In this case list demo you can see how the sorting works with a non-standard numeric value (“Case No.”), American date formats (“Opened” and “Closed”) and a non-sortable column (“Time”). Again, there was no need to touch the sorting script itself. By changing the names of class attributes in the markup, one can control how the script works.
For example, the first numeric column has been set to sort on the third sequence in the case number, rather than the first (needless to say, one can set it to sort by any of the three numerical sequences in the case number); the sorting of dates in an American format works smoothly, recognizing both one- and two-digit formats for the month and the day of month and two- or four-digit formats for the year; and the column on the far right with the clock icon illustrates how one can selectively set a column not to sort at all.
One final touch worth noting: the sorting script also recognizes custom class attributes for defining which column is actively sorted on loading the page, as well as the order of the values in that column. For example, in the case list demo the table tag has the class="sortable-onload-4-reverse attribute assigned, i.e., onload the script actively sorts the fourth column and lists the values in reverse order. Done.
(Yes, those are real names. No, they are not clients. All are family or friends of Webdogs 2.0. We count ourselves blessed as many times over.)
One of the things on our short list of Pika modifications is the goal to make all table lists sortable. The default installation includes some sortable lists but not all are, and the sorting implementation seems a touch dated. This prompted us to research the world of javascript libraries for an updated table-sort implementation, which brought us to Brian McAllister’s Unobtrusive Table Sort Script (revisited), an extremely well documented script and a breeze to implement. If you can link a script tag and know how to do basic table markup, you can do it.
To get motivated about building a sortable table demo, I wanted to at least be working on something that may have some potential use, so this weekend I built the Pika HTML Tag | CSS Matrix ~ Sortable Table Demo 01:
Since I play with CSS like some folks play Sudoku, I thought this would be a fun project enabling me to sort all the Pika 3.06 templates to see which HTML tags had id or class attributes and corresponding values assigned to them, and which I could use in turn to evaluate and tweak the Pika default style sheets. Hence, the “CSS Matrix.”
As mentioned at the bottom of the demo page, the table design styles are a direct lift from Veerle’s A CSS styled table, essentially the same design used by Brian McAllister in his table-sort-demo. (His demo illustrates how the script works with other common tabular data values, e.g., currency, dates, etc.) I especially like the ascending/descending “marker” design used as a background image in the table header elements. The script swaps out three different images to visualize effectively whether the sortable column is or is not selected and if so whether it is sorted in ascending or descending order. (I guarantee you’re going to see this design touch in LSNC’s next Pika implementation.) I only made minor changes to the CSS code to accommodate the need for a more visible hover state for links to the HTML tags, to change various font-size settings to my standard defaults, and to style a few added page elements.
“The past is but the past of a beginning.” ~ H.G. Wells
For those paying attention, the second blog ever posted at Webdogs 2.0 was about the Pika 3.06 beta. (The beta test site linked there is no longer active.) That was then. (October 2006, to be exact.) This is now. Last week Aaron officially released the full-on version of Pika 3.06.
As you can see from the accompanying imagery, Pika has discovered gradients and has undergone a modest but appealing makeover, with updated colors and page elements. The case tabs have a new, spiffy 3-D look. And the Pika home page links directly to recently updated online Pika resources at the famed PikaDocs wiki, including the Pika User Manual and Pika Admin Manual.
Going deeper, Aaron has recoded things to make it way easier for organizations to maintain control of their (inevitable) customizations. Long time Pika-savvy ITs know all too well that, for example, the page templates for the older versions of Pika are located in the /templates and /subtemplates subfolders, and with every upgrade you had to be very careful and re-code the individual customized templates (or other customized files) to add in the new Pika coding. One could not just copy the new files over the old. No way.
But with this new version, actually you can! Here’s how it works in the new Pika 3.06: Aaron has recoded Pika to exploit a new special custom folder where you can place templates, subtemplates, tab customizations, modules and configuration files. Those are yours, and all yours. With those in place, Pika 3.06 automatically checks your installation to see if you have created a customization located in that special folder. If it sees that you have, Pika uses your customized file instead of the Pika default file. Sweet.
Among other tucks and tweaks that come with the new version are a major (if not yet complete) move towards removal of embedded style elements, pushing more and more of the presentational characteristics of Pika to external CSS. Pika 3.06 also includes improved report printing, courtesy of newly exploited CSS features that permit differing display of a web page in the browser and in print. The old option for printing reports as HTML or PDF is gone. The new approach is better implemented, relying on standards-compliant CSS print style sheets, so the user can see the report displayed in a web page or in a conforming “print” style to your printer or to a PDF file format, which in practice is essentially a print format. This is a singularly great improvement for all Pika users.
And since I’m on the topic of CSS, allow me to digress a bit about my present befuddlement about text resizing in Internet Explorer. Unlike all other browsers, IE does not resize page text if it is set in pixels, which is exactly what Pika 3.06 does, and has done in its earlier versions. (The Pika default body tag is set to “font-size: 13px” in the danio.css file.) There is irony in the fact that I have hammered Aaron on this point for the longest time but now I rarely use IE having joined the Firefox cult. But hey, on principle it matters! All users should be able to resize text within their browser. Yes, IE7 has a “zoom” feature but that is not the same thing as text resizing. Yet apparently in the current version of IE7 that is exactly what Microsoft, misleadingly, calls it when you select View > Text Size. Actually, what that option in IE now does is trigger the zoom function enlarging not just the text but all the other page elements on the page. Try text resizing in IE7 (which adopts the same Ctrl++ and Ctrl+- keyboard shortcuts used by Firefox for text resizing) and then view the same page doing the same thing in Firefox. Watch in IE as your text enlarges but also your whole page structure expands off to the right and the bottom of the page. Watch in Firefox as text resizing enlarges or shrinks the text but honors the page structure. Zoom has its functions, but it is a notably less effective way to allow users to granulate the size of page text to ease readability, while maintaining the basic layout and proportions of the page structure. This is a real stinker/cheat of an implementation in IE.
Now, back to our regular programming.
I spoke to Aaron a few days ago, and he reports the pace of the Pika development cycle, with its promise of Pika 4.0, will be picking up. Pika Software used to do customizations more when the Pika install base was smaller, but as things have grown he has shifted his focus more purposefully on full-on development and now refers customizations out to those open source savants over at Kaivo.
So, where does this leave the Webdogs? We can’t wait for Pika 4.0, but in the interim we’re going to do a lot with Pika 3.06. We have already set up a test bed and will begin to migrate our heavily customized version of Pika over to pull in all the new goodies. In the process we will begin to build yet another Pika redesign to build on all we have learned from our initial two years of experience with Aaron’s code. What this means for Webdogs 2.0 is that the long nascent Pika~palooza is back on, full on. Forget Project Claire. She is soooooo 2005. Get ready for Project Grace: The Pika Love Project.
For those interested in what typography has to do with good web design and/or web standards, consider viewing Elegant Web Typography, Jeff Croft’s most excellent 130-slide presentation from last month’s Future of Web Design conference in London. (I tried but couldn’t locate an audio file for this particular presentation. Sorry about that.) Not only is this an excellent introduction to and overview of web-based approaches to typography, it is also a very good example, for the most part, of how to layout a good “slide” page. (In general, less is more on any given slide. Please.)
Jeff Croft is a prominent member of the web standardistas and a co-author of two books I can recommend: Pro CSS Techniques and Web Standards Creativity: Innovations in Web Design with XHTML, CSS and DOM Scripting.
Serendipitously, a week after our latest periodic posturing about the importance of coding to web standards, Digital Web Magazine yesterday published Garrett Dimon’s must-read list of 21 guidelines for approaching Markup as a Craft. And I quote:
Markup is the technical foundation of front-end code. In one way or another, it influences or is influenced by design, content, accessibility, CSS, DOM scripting, and more. The quality of your markup will affect the quality of related code, and even the cost of implementing or maintaining that code. … Carefully crafting your markup is like making a lucrative investment in the future of your code base. It’s easier to create and maintain back-end code when it integrates with clean and simple markup. Your CSS can be elegant. Your DOM scripting can connect seamlessly. … It’s time to treat markup as a craft, and give it the love and attention it deserves.
All 21 points of emphasis in this article are worthwhile. A few jump out to the Webdogs because of our experience re-coding an earlier version of our beloved Pika. True, our re-coding was not remotely as optimal as it could be, but we are determined it will be with our next iteration. In our prior work there were a number of functionally adequate but less than stellar coding approaches we took, including too many semantically invalid form elements. That said, with Project Claire we proved among other things that you can build a UI without relying on semantically incorrect table elements to control layout and positioning (we stripped out every last table element in Pika that was not a data table); with due care, more often than not you can remove out-dated, deprecated structual elements embedded in scripts and replace them with up-to-date code in templates, where the structural markup belongs; and you can and should dramatically improve control of the presentation of the CMS by removing all — and I really do mean all — inline style elements from scripts and templates. (True again, our CSS for Project Claire is a bloated spectacle of redundancy and underutilization of the cascade, but as we were saying, our coding was valid but not optimal.)
Given the not inconsiderable work involved in re-coding things, it is understandable why long existing websites and CMS builds are not up to current coding standards. But what is the justification for launching new designs or rebuilds without conforming to now widely adopted coding standards?
Think of it as a Tech Advent Calendar. It’s called 24 Ways “to impress your friends,” but more accurately is just 24 ways to have some fun with web design/web development widgets, bits of code for byte-sized fun every day between now and Christmas. I really loved playing with this stuff last year. It’s pretty likely you’ll pick up an idea or two you can bring to your own web-based projects this year, as well.
… and since I’m on the topic of web standards, and we all are now living in an IE7 world, let me refer you to Newly Supported CSS Selectors in IE7, a free article at Community MX by CSS czars John Gallant and Holly Bergevin. The article provides a very helpful refresher or re-orientation on the core CSS concepts of selectors and combinators, and how they yield specificity. The big news here is that IE7 now supports child combinators and adjacent-sibling combinators.
Does it matter? Yes it does. For example, here is the Google Analytics browser report for last week at Webdogs 2.0, with its targeted tech-niche audience: Our intrepid visitors overwhelmingly rely on one flavor or another of Firefox or Safari, but only about 13% drive by at the wheel of an IE:
But the web hoi polloi still overwhelmingly use IE. Here’s the same report for the LSNC main website, with IE getting 83%, Firefox 15%, and statistical crumbs to the remainder:
Feel the font love, people. Quirky serifs aside, Georgia fonts win on Web: “Georgia is an elegant, quietly idiosyncratic typeface, which is a pleasure to read on screen.” Its only real typographic web rival is Verdana. As you view Webdogs 2.0 (or LSNC.net, for that matter), what you’re reading is in either Georgia or Verdana typeface. Why? Because we’re Webdogs. We care.
Predictably, there is no end to the carping about how the newly released versions of Firefox 2.0 and Internet Explorer 7.0 compare, a head-to-head battle that editorially Firefox always seems destined to win, and justifiably so.
I share the view that Firefox is the preferable of the two dominant web browsers, and yet as good as Firefox is, it has its quirks. One of them LSNC discovered only when it converted to large numbers of staffers using Firefox after deploying Pika. The problem we encountered was getting search results tables (e.g., a list of cases) to print out correctly. The problem had nothing to do with Pika. The problem turned out to be with our custom print style sheet. The search results tables uniformly printed out as intended in IE, but in Firefox we could only get it to print the first page of the listed results; the second and subsequent pages would print out as blank pages. Yeow! Later, we discovered the problem was not just our custom print style sheet; the printing problems with Firefox also plagued other web locations as well. For example, view this sample U.S. Code page at Cornell and then use print preview in IE and then Firefox. See how the second and third pages just vanish in Firefox?
What to do? Two possible solutions:
As discussed by CSS guru Eric Meyer in When Printing Maims, it may be that your particular page design (as did our heavily redesigned Pika templates) relies on floats for positioning of the “main content” area. In your print style sheet, adding the CSS property {float:none} to the selector that corresponds to the structural element containing the affected text may solve the problem.
In our case, it actually didn’t, but a suggestion further down that same discussion thread hit the nail on the head: Add {display:table-cell} to the CSS for the affected container. For Firefox, this totally solved the problem with printing out our search results tables. And this particular CSS property is a non-issue for IE, since it doesn’t recognize that value.