Extensible CSS Interface I: The Foundation

~ 28 February 2008 ~

This series is sponsored by Authentic Jobs, a freelance and full-time job board for web professionals.

This is the first article in the four-part series, “The Highly Extensible CSS Interface”. Markup and images for this article:

Part 1 - Foundation

Throughout the duration of this series, we’ll be speaking extensively about markup — XHTML, CSS, and a little scripting. Marking up a website is akin to speaking Spanish. There’s more than one way say something, and there’s certainly more than one way to code something. (¿Puerco, cochino, cual es?)

As you plumb through my code, I’m hopeful you’ll see things that you might code differently or even improve upon. Or put more plainly, I expect you to call me out on things that deserve refinement or just plain suck. After all, we collectively better ourselves as a community by exchanging ideas and opinions for approaches to problem solving, and markup practices are certainly no exception. Fair enough?

Meaningful, Lightweight

When drafting markup, the factors I consider most important are that it be as 1) meaningful and as 2) lightweight as possible.

When we say “meaningful” we mean the HTML elements and selector names we choose appropriately represent the content in such a way that if we were to experience the web with all styling removed, the hierarchy and structure of the content would still make sense. Long gone are the days of spacer gifs and repeated br elements (with which some of you reading this may not even have experience), replaced with elements which logically, or semantically, represent the content:

  • An ordered list of top-selling items (ol)
  • The principal heading on a page (h1)
  • A quotation from a happy customer (blockquote and cite)

This approach requires that we remove presentational information from our thinking, a concept described comprehensively by Andy Clarke in his remarkable book, Transcending CSS. I still vividly recall my early experiences with CSS as we coded a rather large-scale web application, thinking we were cleverly creating a series of presentational class names that allowed us to mark up content with elegant clarity such as this:

<p class="arial red 10">

…only to endure a painful day of reckoning when the application required a redesign, whose 500 templates were to become anything but red Arial 10px type. I can has do-over?

When we say “lightweight” we mean marking up our content with the fewest parts possible for all things markup — elements, attributes, and values for HTML; selectors, properties, and values for CSS. For example,

<a href=""><span class="icon">Map</span></a>

is minimized as

<a href="" class="icon">Map</a>

Also,

border-width: 1px; border-style: solid; border-color: #000;

becomes

border: 1px solid #000;

You’ll see numerous examples of meaningful and lightweight markup throughout the series, few of which I’ll pause to explicitly explain. So take time on your own to make note of these. (And again, call me out when you see things that can be more meaningful and lightweight.)

Finally, because the theme of this series is extensibility — designing and coding in such a way that the interface is as adaptable as possible — the beauty of a meaningful approach is that it inherently helps set the stage for creating an extensible interface.

Let’s examine the demo example by diving into some of the foundational code.

reset.css

When I first began coding CSS-styled sites several years ago, it was common to declare a few “global” styles at the top of the master style sheet: body, a img, h1,h2,h3,h4,h5,h6 etc. What was done back then as a means of overriding the default styles of any given browser eventually evolved into today’s practice of using a “reset” style sheet, typically named reset.css.

As stated by the team at Yahoo, a reset style sheet “removes and neutralizes the inconsistent default styling of HTML elements, creating a level playing field across A-grade browsers….” If CSS frameworks such as Yahoo Grids or Blueprint are your thing, each of these come equipped with a reset style sheet built in. Alternatively, you can roll your own or use one written by others in the community.

I personally prefer Eric Meyer’s Reset CSS, and this is the reset style sheet used in the demo for the series. (Note: The demo CSS was written before Eric’s January 2008 version of Reset CSS and therefore uses the May 2007 version. I’ve not gone back to update the CSS to adopt his latest version. Notes about the subtle differences can be found here.)

I use a single style sheet, master.css, to “import” any number of style sheets for a site. I declare the reset style sheet first, thereby allowing any style sheets that come after to override the reset styles as needed:

@import url("reset.css");
@import url("screen.css");
@import ...

All styles for screen display are then listed in screen.css.

Resolution Dependence

Herein begins one of the first components of extensibility: An interface that adapts to different display sizes (or browser widths). Perhaps the easiest way to accomplish this is to create a fully fluid layout (width: 100%;), which can accommodate virtually any display or browser width. However, fluid layouts create wide, illegible line lengths on larger displays, among many other issues.

However, to reap the extensibility benefits of a fluid layout while accounting for issues such as line length, we need only to set limits for the maximum and minimum width of our layout. I first demonstrated this technique in the fictitious Tuscany Luxury Resorts layout created for CSS Mastery. Expand and contract your browser’s width, and watch how the layout expands and contracts but stops at 740px and 1200px. This is accomplished using the max-width and min-width properties.

Because IE7 wasn’t publicly available when this site was created more than two years ago, and because IE6 ignores the max-width and min-width properties, the markup required a nasty hack to target IE and force it to replicate max/min-width using a JavaScript extension.

Welcome to 2008. Although IE7 market share isn’t dominant enough to write off IE6 entirely just yet, we can at least begin to explore interfaces that leverage the many CSS2 and CSS3 properties now supported by IE7. And of course, these newly supported properties include max-width and min-width — no need for nasty JS hacks.

We’ll talk more about resolution dependence in Part II, but for now we’ll add a few lines of markup and a couple scripts to start the process. To do so, we’ll use Cameron Adams’s excellent Resolution Dependent Layout technique. First, we reference two scripts in the HTML <head>:

<script type="text/javascript" src="scripts/event_listeners.js"></script>
<script type="text/javascript" src="scripts/resolution.js"></script>

Second, we add an alternate style sheet which the above scripts will import as the browser width expands and contracts beyond 1200px and 750px, respectively:

<link rel="alternate stylesheet" href="css/1024.css" type="text/css" title="1024 x 768" />

Notice that this style sheet is added to the <head> rather than being referenced by master.css.

Also take note that you can do the max/min-width thing without the need for Cameron Adams’s scripts. However, we’ll leverage his technique extensively to do some pretty sweet tricks with the content and navigation elements in Part II Parts II & III. But for that, you’ll have to wait another week. Peace out, yo.

 

67  Comments

Veer Veer: Visual Elements for Creatives.
Stock photography, type, and killer tees. Genuinely recommended by Authentic Boredom.

1   Dan Mall ~ 28 February 2008

Hey Cameron,

Definitely looking forward to the rest of this series!

A quick question for you: in your code, you have a comment about originally having the user info as an unordered list, but had to change it because of float problems.

Could you talk about some of those problems?


2   Matthew Pennell ~ 28 February 2008

Things requiring refinement, calling you out thereupon:

1. According to Yahoo!’s research on speed improvements, SCRIPT elements should be moved to the end of the document, not imported in the HEAD.

2. If you’re going to create multiple stylesheets (and include them in series in a master.css file), it might be worth considering creating a build process to stitch all your stylesheets together; either when you make changes live (i.e. run them through a script to create a single master.css file), or using PHP or similar on the server.

Looking forward to the rest of the series. :)


3   Matthew Pennell ~ 28 February 2008

On further reading, I see Cam’s scripts need to be in the head, so ignore that (although the general principle still stands).

I’d be interested in hearing your reasoning behind choosing a Transitional DOCTYPE (and also why XHTML over HTML).


4   brandon ~ 28 February 2008

I’m seeing some unusual wrapping in the User links when I shrink my browser. Would it be overkill to use the white-space nowrap style?

#user a {
white-space: nowrap;
}


5   Jesse Gardner ~ 28 February 2008

I was thinking this very thing today: “Why do I keep recreating the foundation for every new site I begin?”

Looking forward to this!

(Just as an FYI, autocomplete.css is MIA.)


6   Jesse Gardner ~ 28 February 2008

I’m also curious… no h1 or h2?


7   Dougie ~ 28 February 2008

Hi Cameron,

About the float problem on the <div id=”user”> section - if you switch the order of the “Log Out”, “Your Account” and “Logged in as” links in a <ul> you can simply float the list-items to the right.

HTML:
<ul id="user">
<li><a href="" onclick="eraseCookie('foo')">Log out</a></li>
<li><a href="#asdf">Your Account</a> | </li>
<li>Logged in as <strong>cameronmoll</strong> | </li>
</ul>


CSS:
#user li
{
float:right;
}

Worked for me in FF.

Dougie.


8   Ed Knittel ~ 28 February 2008

Cameron, can you offer a reason why you decided not to include the following in your CSS?

#user p{white-space:nowrap;}

Since you are setting a min-width we do not have to worry about smaller browser windows (such as the iPhone) so seeing the Your Account wrap breaks what I believe should be a solid line of links. And if you didn’t want the whole p to be on a single line I think that at least adding #user p a{white-space:nowrap;} would be in order.

Eager to hear your thoughts.


9   Ed Knittel ~ 28 February 2008

@Brandon - I had my window open for awhile (when there was only 1 comment) so I missed you statement.

As a note: when I added the white-space:nowrap I noticed that an issue with the padding is introduced which causes unnecessary horizontal scrolling. Given just a few more minutes it could be resolved.


10   Andrew Strachan ~ 28 February 2008

Cameron - I’m also curious about the missing H1 when

would have provided the same result?


11   Ed Knittel ~ 28 February 2008

Also, if you’re including the JS for resizing in IE 6 I fail to see why you have not written the rest of the example to work in IE 6?

The header (especially with the PNG logo) is definitely broken in IE 6.


12   Matt Wilcox ~ 28 February 2008

Well that’s the first time I’ve seen the Resolution Dependant Styleswitcher mentioned in years. Reminds me of the last site I used it in: http://shop.wwf.org.uk (go easy on the markup, it’s a good year and a half old now)

Looks like the series is going to be pretty interesting Cameron, can’t wait for part two! :)


13   Matt Wilcox ~ 28 February 2008

(Oh, and if you were to look at the CSS and see I’m not using @import to streamline the filesizes as you suggest, there’s a good reason. It used to until this month, but IE6 crashes now where it didn’t before: http://mattwilcox.net/archive/entry/id/963/ )


14   Colin ~ 28 February 2008

“According to Yahoo!’s research on speed improvements, SCRIPT elements should be moved to the end of the document, not imported in the HEAD.”

Unfortunately, that’s just not always possible. Consider a CMS where users can embed flash movies and video, and you want to use SWFObject. Short of doing some voodoo with the CMS, the core SWFObject object is going to need to be readily available at any time in the document.


15   Cameron Moll ~ 28 February 2008

It’s good to see many of you are taking my “call me out” request seriously. Let me see if I can address some of the comments so far.

in your code, you have a comment about originally having the user info as an unordered list, but had to change it because of float problems.

Honestly, I don’t recall at the moment, and looking at the code again isn’t helping me recollect. I believe it has to do with issue Dougie mentions. I’ll have to take another look at that.

it might be worth considering creating a build process to stitch all your stylesheets together;

Matthew, if I’m not mistaken, you offer this suggestion as a means of improving speed and minimizing trips to the server? If so, I agree.

I’d be interested in hearing your reasoning behind choosing a Transitional DOCTYPE (and also why XHTML over HTML).

This is a good one to call me out on, as admittedly I’ve not given much thought to this. XHTML Transitional has long been the doctype I’ve used. Part of it is laziness in switching to something else, but part of it’s that I haven’t heard (or been ignorant to) a convincing argument to switch to something else, other than “it’s the right thing to do.” (BTW, more about Transitional vs. Strict vs. HTML 4.01 here.)

(Just as an FYI, autocomplete.css is MIA.)

Yes, that’ll be included in the next download.

I’m also curious… no h1 or h2?

Hang in there, we’ll include one soon enough. (Or are you asking why I didn’t use for the logo or “Widget Community”?)

About the float problem on the section - if you switch the order of the “Log Out”, “Your Account” and “Logged in as” links in a ul you can simply float the list-items to the right.

Yes, I’ve done that trick before. Problem is if it’s the main navigation (Home, Products, Contact, etc) it reverses the order for unsighted users — Home link is last, Contact is first. In this instance the ordering would probably be fine for unsighted users, but I elected not to.

Cameron, can you offer a reason why you decided not to include the following in your CSS? #user p{white-space:nowrap;}

Yes, and it has to do with sacrificing just a little aesthetic integrity for the sake of unknown content. Although it’s a fictitious app, we can assume the crumb trail beneath “Widget Community” could grow significantly longer than what’s show here. By keeping #user a percentage width and allowing it to wrap, we save room for that entire section at the top. Same goes for when the #user section is translated to another language — the text could be significantly longer. Remember, we’re going for extensibility here, not perfect aesthetic integrity.

Also, if you’re including the JS for resizing in IE 6 I fail to see why you have not written the rest of the example to work in IE 6?

I’ll provide a disclaimer in the next article but I’ll provide one here too: This demo will work only in IE7 and above. I want us to explore newly supported selectors and such without inhibiting ourselves with IE6. You all are smart enough to make concessions for IE6 on your own as your audiences and projects demand.


16   Jake ~ 28 February 2008

Wow… Lot’s of unexpected criticism. Correct me if I’m wrong but this is Part 1 and seems to cover a little more than the basics. Why can’t everyone just admit that by the time we’ve read the complete series, we’ll have learned a thing or two and be pleased.

I do look forward to the rest of the series. When I first looked into CSS I wasn’t sure where to begin. I went to the bookstore and out of all the css books, I purchased yours “CSS MASTERY”. I still reference it. Thanks.


17   Rafael ~ 28 February 2008

By the way, in Spanish it’s “cual”, not “qual”.


18   Mike Girouard ~ 28 February 2008

“Unfortunately, that’s just not always possible. Consider a CMS where users can embed flash movies and video, and you want to use SWFObject. Short of doing some voodoo with the CMS, the core SWFObject object is going to need to be readily available at any time in the document.”

Quite true — but that assumes that you only base your code off of the examples they provide. Writing a SWFObjectManager class to automatically load a series of SWFs as soon as the target containers become available would be trivial with any modern library (YUI, jQuery, etc).

Speaking of JavaScript, I always make it a point to namespace all JavaScript functions to prevent potential conflicts… Think about how other potential libraries include their own ‘addEventListener’ or ‘checkBrowserWidth’ method.

var foundation = {
‘addLoadListener’ : function () {…}
};


19   Cameron Moll ~ 28 February 2008

By the way, in Spanish it’s “cual”, not “qual”.

Oh my, is my Spanish that rusty? Thanks for the catch.


20   Jeremy ~ 28 February 2008

Cameron:

Is reference stylesheets using the <link> tag superior to the <style> tag? In my standard starting structure I reference my stylesheets as so:

<style>
@import url(css/screen.css) screen;
@import url(css/print.css) print;
</style>

And if there is no major difference, and I continue to do so but want to use the resolution dependent layout, would I need to switch.

This is a great article and I am looking forward to more.


21   Ryan ~ 28 February 2008

Great article, very interesting read. What’s the benefits of using a master style sheet?

Thanks


22   Ty Hatch ~ 28 February 2008

Having played with YUI CSS and used Eric’s reset, I think they both have their place. (Personally, I’ve found that Eric’s reset is nice if I’m planning on not focusing on using a rigid grid, which is something that Yahoo and Blueprint offer.)

Would you mind enlightening us why you prefer Eric’s reset over Yahoo’s?


23   Michael Locke ~ 28 February 2008

Ha ha…

Cameron, you should have left out the “call me out” part. Nice start to the series, I’ve picked up a few tips already. Thanks!


24   tyBTS ~ 28 February 2008

@jeremy I don’t think Cameron is talking about the link tag, his stylesheet calls are in the master.css page. Having them there and one change to the master.css call changes the styles sitewide, if it is a sitewide stylesheet. Very clean.


25   Jeff L ~ 28 February 2008

Cameron,

In reference to your response about Transitional vs Strict doctype - Transitional was introduced as a doctype to be used on existing websites, while the site was transitioning to a Strict doctype. Transitional allows for presentational elements etc, while Strict does not.

No new website should start out with a transitional doctype - it should start with Strict (either HTML or XHTML, that’s a whole different conversation).

Interesting in seeing where this series goes…


26   Jeff L ~ 28 February 2008

Sorry, just noticed the link you posted to 24ways - so you’re obviously familiar w/ the differences. Time to switch, then. :-)

Also, surprised no one called you out on your use of an inline event handler…hoping that in the real app this would be added dynamically for those with JS enabled and there would be a server side fallback for logging out.


27   Thomas ~ 28 February 2008

“By keeping #user a percentage width and allowing it to wrap, we save room for that entire section at the top.”

I’ve often run into that issue and prefer to make the content wrap just as you’ve done with one exception. By adding a SPAN around the “Logged in as Cameron Moll” you could put:

#user p span, #user p a {white-space:nowrap}

A bit more code, true, but that way at least the individual elements wouldn’t wrap but the overall content still would maintaining both the structural integrity you’re looking for and upping the legibility a bit.

Just a thought.


28   Jeremy ~ 28 February 2008

@tyBTS:

Cameron uses the link tag in his HTML to call the master.css file, whereas I use the @import statements wrapped by a style tag in the html.

I am curious if a: one is better (either asthetically, structurally, or with load time in mind), and b: if I call my stylesheets using the @import can I still use the link tag to call an alternate stylesheet if I apply the “Resolution Dependant Layout” described here.

Thank you!


29   Aaron Barker ~ 28 February 2008

Per the whole doctype discussion…

I don’t buy into the strict doctype yet. It usually takes a perfect world to go strict in my mind. Since some of us live in a world of CMS’s we don’t have that perfect world quite yet.

Loosing the ability to put a simple “display:none” in a document just isn’t worth it for me. Instead you have to make things more complicated in other ways of doing these super-simple page level things in an external stylesheet, JS or whatever.

In addition, to use any XHTML doctype you should also technically be serving the file up as XML, but IE6 just plain blows up, and there are other issues as well. On a recent project, the development environment was serving pages up as the proper application/xhtml+xml mime type and it was causing issues with a jQuery plugin. Can list the issues out if desired, but here are some links that discuss them
Link 1, Link 2, Link 3

In the end I think you need to make the best decision for your organization. If you have complete control over everything and have the time to dot the I’s and cross the T’s then more power to you. For the rest of us who live with constraints of company systems, don’t want the extra hassle, etc. I don’t think it’s THAT bad to go with a doctype that points us in the right direction until everything else (browsers, CMS’ etc) catch up.


30   andrew ~ 28 February 2008

are we basing this on blueprint? to assist with the vertical grid/typography?


31   John Faulds ~ 28 February 2008

With regards the two sets of links at the top of the page (left and right): I’d argue that they should be both be unordered lists.

Also, maybe it’s just personal preference, but if I’m setting a max-width on a layout, I set it in ems so that the layout can expand in width as the text size increases so your main content line-length will always be in proportion to the text size.


32   Cameron Moll ~ 28 February 2008

Is reference stylesheets using the tag superior to the tag?

I honestly don’t know, actually. Anyone care to enlighten us?

Having played with YUI CSS and used Eric’s reset, I think they both have their place…. Would you mind enlightening us why you prefer Eric’s reset over Yahoo’s?

You’re right that both have their place, Ty. “Prefer” was probably the wrong word, actually. More like “more suitable” for this demo since neither Yahoo Grids nor Blueprint is being used.

What’s the benefits of using a master style sheet?

The simplicity of having only one link rel in any html file and then being able to reference as many style sheets as necessary in master.css. Of course, one could add probably multiple link rels dynamically. As for trips to the server and such, I don’t personally know which is better.

Transitional was introduced as a doctype to be used on existing websites, while the site was transitioning to a Strict doctype.

Thanks for the clear explanation, Jeff.

Also, surprised no one called you out on your use of an inline event handler…hoping that in the real app this would be added dynamically for those with JS enabled and there would be a server side fallback for logging out.

Yes. The inline event handler was easier for the purposes of this demo.

Are we basing this on blueprint?

No. (As an aside, Blueprint doesn’t allow for fluid layouts as far as I’m aware.)


33   Jay Jones ~ 28 February 2008

Cameron,

Regarding the #user links, there is a simple way to accommodate the floated li’s within the ul without resorting to reversing the order of the navigation.

Give the ul#user a position of absolute, and a “right” value of “0px”. By not supplying a “top” value, it retains its vertical position in the document flow, and nicely positions it to the right. You can then float all your links to the left, and they’ll behave just grand.

Also, I would use a border-right on the li’s and class the last one “last”, removing the border for it rather than using a character entity that screen readers would read out loud, not making sense to the user.


#user {
color:#888888;
font-size:0.87em;
overflow:hidden;
padding-right:20px;
position:absolute;
right:0px;
text-align:right;
width:28%;
}
#user li {
border-right:1px solid #CCCCCC;
float:left;
}
#user li.last {
border-right:medium none;
}


The html would look like this…

<ul id="user">
<li>Logged in as <strong>cameronmoll</strong></li>
<li><a href="#asdf">Your Account</a></li>
<li class="last"><a onclick="eraseCookie(‘foo’)" href="">Log out</a></li>
</ul>

Great series so far. Thanks so much for providing your expertise to the rest of us.


34   Jay Jones ~ 28 February 2008

Hmmm… don’t know where the “medium” came from in my above example css. I should have taken advantage of the preview feature in the comments to catch it before posting! :)


35   Brendan Falkowski ~ 28 February 2008

Looking forward to the rest of the series. Always nice to see a thought process rather than a specific technique.


36   Matthew Pennell ~ 29 February 2008

@Aaron Barker:

Loosing the ability to put a simple “display:none” in a document just isn’t worth it for me. Instead you have to make things more complicated in other ways of doing these super-simple page level things in an external stylesheet, JS or whatever.

You can use Strict and still use inline style attributes; what it doesn’t allow you to do is use presentational elements like u or inline behavioural attributes such as target.


37   Teddy Zetterlund ~ 29 February 2008

I’m very likely to come back to this article when I’ve had time to go through the code. But for now, just a quickie; Jay Jones suggestion can be further approved by instead of adding a border-right, add a border-left and use :first-child on the first LI to remove the border on that one. (Since we’re only concentrating on modern browsers at this moment.)


38   Zach ~ 29 February 2008

Cameron,
I think this is a great idea, if anything it will open up people to others styles and ideas. I am a huge fan of making sites degrade and still be understood.

So for example, the #logo I would do something like:

<h1 id=”logo”>
<a href=”#”>
<span>Widget Industries</span></a>
</h1>

#logo {
height: 33px;
width: 208px;
display: block;
background: url(‘img/logo-bw.gif’) no-repat;
}

#logo a {
height: 33px;
width: 208px;
display: block;
}

#logo a span {
display: none;
}

Maybe this is improper, and would love to know, but this seems like it makes more sense than a nasty img tag.

Zach.
SLC, UT.


39   Pneumatiky ~ 29 February 2008

Really interesting article


40   Aaron Barker ~ 29 February 2008

@ Matthew Pennell

You can use Strict and still use inline style attributes; what it doesn’t allow you to do is use presentational elements like u or inline behavioural attributes such as target.

I stand corrected. I’m not sure where I got in my head that you can’t use style or other simple event based attributes (onclick, etc) in the strict doctype, as I couldn’t find mention of that belief anywhere. Maybe I got it confused with all the arguments for simple separation of structure, style and functionality.

Thank you for the correction.


41   Daniel Hillesheim ~ 29 February 2008

Cameron,
As always, you create a lot of ‘buzz,’ though I’m not sure it’s the ‘buzz’ you expected on this one. I’ll be patient and call you out once your series is finished, no sooner.

I’ve always enjoyed reading your blog and have for a couple years, but this is my first post! So, now you’re in a lot of trouble…I tried to restrain myself, but can’t.

Great series so far, looking forward to the rest!


42   Benjamin Alijagić ~ 29 February 2008

Hello, Cameron!
Thanks for writing this extensible css interface series, hope you will show us more and more css/xhtml tips and tricks. I think You are my life ideal. I’m 15 year old and I really wanna be great web designer. Thank You very much. Visit my site, http://benjamin.izhr.com .


43   Joe Mako ~ 29 February 2008

Just a minor note - when the width of the browser window is made narrow, content in the div id=”user” line-breaks at odd points. My initial thought is to add a non-breaking space character, but there may be a better solution.


44   kirkaracha ~ 29 February 2008

One reason to use link for the style sheets instead of @import inside the style tags is to avoid a Flash of Unstyled Content in Internet Explorer. IE gets confused if you don’t have either a link or a script tag in the head.


45   Michael Critz ~ 29 February 2008

I’m bookmarking this. Keep up the awesome!


46   Cameron Moll ~ 01 March 2008

So for example, the #logo I would do something like:


<h1 id=”logo”>

So, I’ve used that technique as well, more often than not. In fact, you can see my portfolio page is coded that way.

However, for this demo I’ve opted to not use this technique and instead use one by Dan Cederholm, partly to favor the content with the h1 rather than the logo, partly to have a print-friendly logo.


47   Jonathan Aquino ~ 01 March 2008

I’ve read the following rule of thumb in a couple of places: CSS includes at the top, JavaScript includes at the bottom (before the closing body tag). Pages display faster if the JavaScript is loaded last.


48   thomas ~ 01 March 2008

regarding H1:

I always save that for content. The logo is imporant to sighted users, and even then as relates to the brand not the content of a page.

If it were a book the H1 would correspond more to the title of a chapter not the publishing company or the author.


49   Dean Landolt ~ 03 March 2008

As an aside, Blueprint doesn’t allow for fluid layouts as far as I’m aware.

Not yet at least, Cameron — perhaps you may want to have a look at this though. It’s in the works…


50   Evan Meagher ~ 03 March 2008

From the looks of this first article, your CSS series might well join Transcending CSS on the must-read list for web designers. I Look forward to parts 2 through 4!


51   Aaron Barker ~ 03 March 2008

@ Dean Landolt

yet at least, Cameron — perhaps you may want to have a look at this though. It’s in the works…

Was there a “this” that you were referring to?


52   Thomas ~ 04 March 2008

Since you asked to be called out: :-)

”..we mean marking up our content with the least number of parts possible.”

That should be “the fewest parts possible.” Since you’re talking about countable nouns (parts), not uncountable ones (like “fun” or “water, for example).

Also, your writing’s best when you’re speaking naturally and informally. Can you avoid using obscure legal-sounding words like “Herein”?


53   Cameron Moll ~ 04 March 2008

Good call on both items, Thomas.


54   spigot ~ 04 March 2008

The parties agree that heretofore this (designer) rendered code ignoramously, and will thus forth adhere to strict doctypes and extensible foundations.


55   jinesh ~ 05 March 2008

cameron, i might be jumping the gun here but in the next two parts, could you also talk about debugging steps/tools you use to tackle rendering issues while writing the markup and css…


56   david ~ 05 March 2008

Looking forward to part 2.

Though none of my sites had any real issues with the IE6 to IE7 move, I’d love to hear your ideas on keeping things kosher with the move toward IE8. I sometimes to take on older sites for management…who knows what I’ll run across.


57   Ralph Lombreglia ~ 11 March 2008

First paragraph: “There’s more than one way [insert ‘to’] say something…


58   Obieg Dokumentow ~ 12 March 2008

Thanks, nice portal should have a nice look along with functionality.


59   Web design Liverpool ~ 17 March 2008

Some good points here, look forward to the rest of the series.


60   NICCAI ~ 02 April 2008

Great idea for a series, and great start (I haven’t read the other parts yet).

With that said, I’m going to second a previous user’s comments by mentioning stiching of css and reduction of script tags. Performance is such a huge issue when you start working in very large, javascript intensive applications that starting this series on an extensible interface with a number of script and css resets is a bit risky. I really think you need to consider how you will limit http requests. Too many, and your application will be dead in the water.

That said, stitching also highlights other considerations in structuring your css for maintainability and extensibility. For instance, what about skinning? Also, it is ideal to use css shorthand, but you need to be aware of limitations that can occur when having color and backgrounds chunked out. And, what happens when these are stiched together? Skinning is a major part of extensible interfaces, so I think it needs careful consideration.

Lastly, there are other considerations if you take the conditional comments approach.


61   Vazlav ~ 02 April 2008

Hey, Cameron.
Thank you for amazing articles! I want to ask your permission for translating this series to russian language. Is it possible? Of course i will place a link to original text.

WBR


62   John ~ 03 April 2008

Hi
This is great. I am a complete css n00b…I am trying to add another div on the left side in the top panel (where it says widget industries)…however every time it is coming under neath the top. I have something like this
#content {
padding: 8px 16px 10px;
margin: 8px 10px 0 0;
}






test test test


63   Colin ~ 08 April 2008

Great post Cameron. I hadn’t seen Eric Mayer’s new CSS reset either so currently downloading that for my own use too!

Cheers,

Colin


64   Wins Lion ~ 03 May 2008

Oh! Great job!
Very interesting and helpful post.
I add your interesting blog in my iGoogle page!


65   oyunlar 1 ~ 05 May 2008

Hey, Cameron.
Thank you for amazing articles! I want to ask your permission for translating this series to russian language. Is it possible? Of course i will place a link to original text.


66   oyunyeri ~ 05 May 2008

Great post Cameron. I hadn’t seen Eric Mayer’s new CSS reset either so currently downloading that for my own use too!

Cheers,

Colin


67   juegos de cocina ~ 05 May 2008

Thanks, nice portal should have a nice look along with functionality.




About

Authentic Boredom is the platitudinous web home of Cameron Moll, designer, author, and speaker. More…


Jobs
Come in, we're hiring

Full-time and freelance job opportunities. Post a job...

...view all jobs »


Recently

A selection of fine reading, available for a limited time only: