Lesson One: Only be Specific When You Need to Be.

There is a hesitation to fully utilize the cascade. Many people who have worked in CSS for a long time tend to utilize very powerful pseudo-selectors to target specific elements. This is all well and good but it also creates a dangerous habit. We become uncomfortable writing rules that are not highly specific.

This has been a hard lesson learned many times over. My preference has always been to be accurate. I’d write CSS rules that were really detailed and specific. But this is bad. Specific rules paint you into a corner and make reuse very difficult. Instead, use the most general rule you can to get the job done and only write rules that are more specific when the situation presents itself. See the example below:

Now it’s true that the second rule would apply to every paragraph tag on the site. But at first this is fine. Imagine how simple it is to add more specific rules later. As projects grow and styles become inherently more complex by necessity, the situations where we need to become more specific will naturally present themselves. If we are generic from the start we can take advantage of the cascade and overwrite rules with more specific rules when we need to.

To see how bad it can get take a look at these two examples (the third set of rules is an example of adding additional style info with a more specific selector):

This seems like a fundamental lesson in CSS. We can write styles that apply to many objects and the more specific rules will take precedence. Most people who write CSS know this. What’s not usually brought up is the fact that it’s much safer to avoid the complexity created by writing more specific CSS. There are two laws I would propose in regards to specificity in CSS:

• The complexity of your stylesheet is directly correlated to how specific your selectors are.
• Refactoring CSS selectors to be less specific is exponentially more difficult than simply adding specific rules as situations arise.

Lesson Two: You Must Start Somewhere.

Whether you work alone or on a team you need to have a starting point in your stylesheet. A starting point is a generic set of rules that defines how we expect our environment to behave. This is generally important when working in CSS but infinitely more important when working on a CSS document with multiple contributors. Everyone needs to be on the same page and having a baseline foundation for our stylesheet is the best trick we have in our arsenal for achieving exactly this.

My starting point is Eric Meyer’s Reset CSS. Unfortunately for your own productivity, it seems that using a reset stylesheet is a controversial subject. Some experienced with CSS consider these tools to be unnecessary or just plain bad. But the truth is that we all use them in one form or another. The real problem with reset stylesheets is that they were named “reset”. They are not resets but rather they serve as our baselines, our foundations, our intentions for how we want our environment to behave.

The reality is if we don’t use CSS resets we implement them in a much more difficult manner. We repeat ourselves where we have to throughout the document in order to achieve a standard desired behavior. The best example are margins. Every web browser platform has it’s own default styles for margins on different elements. There is no way in hell any of us can memorize the variations of these defaults in our minds let alone compensate for them without taking a serious productivity hit.

If you don’t define your starting point then you inherent every browser’s own pre-defined starting point. This leads to a much more hostile environment for our work to be deployed. We’re giving up control of our environment. It’s much less predictable. It’s actually very very scary.

That’s not to say reset CSS files are the holy grail to writing good CSS. Far from it. They can be a pain if you don’t tailor them. For example, many people don’t like certain settings used in some reset CSS files. A common example is that the ’strong’ element is no longer bold. But that’s because the reset is distributed as a pure example. It’s up to you and your team to change this reset file for your own purposes. If you want strong to be bold adjust the reset. Ultimately, you will develop your own reset.css (though really I think we should call it base.css) over time. The key lessons here are:

• Base stylesheets grant CSS authors control over their environment.
• Base styles are key to creating a shared set of assumptions or expectations amongst multiple contributors.
• Base styles do not guarantee cross browser compatibility but rather buy us and our team members predictable outcomes.

Lesson Three: Rely on Specificity Over Order.

A basic principle in CSS is that if you write two equally specific rules the latter takes precedence. In other words, order matters in your CSS. But this is dangerous. Order only matters if you let it matter – by writing rules with selectors of equal specificity.

As stylesheets grow in size they become more cumbersome to manage. To remain productive in our files we break them down into sections. Or we separate our rules into entirely separate files.

A reliance on the order our code makes it very brittle or fragile. When we need to incorporate a strategy for organizing our code we can easily disrupt the original order the rules appeared in. This is significant because as I stated earlier it’s more manageable to write selectors that are less specific and more general. That does not mean you should incorporate the principle of order as a technique for maintaining a stylesheet with generic rules. If you have two rules of equal specificity that conflict with each other then you need to make one of them more specific in the interest of writing a stylesheet that is flexible enough to be reorganized in a structural framework.

Additionally, most of the occurrences in our stylesheets that provide situations where we have rules which overrule each other due to their order of appearance tend to deal with duplicate selectors. These cases are ideal scenarios where our CSS could potentially be refactored.

The key take aways from this point are:

• Stylesheets that have a strong reliance on order of appearance are inherently more brittle and more susceptible to problems when we attempt to restructure or reorganize our documents.
• Rules that are overwritten due to their order of appearance typically could or should be refactored.

Lesson Four: Be Clear and Expressive.

You need to be clear on what you expect. You need to be clear on how things should be done and handled in your document. How do you do that in CSS? Simply with commenting. We can provide ample amounts of documentation in our CSS files simply by commenting. We can use comments to:

• Define best practices.
• Denote organizational sections.
• Provide references for resources.

There are two problems here. The first is that not enough people utilize comments in their stylesheets. The second is that many authors don’t see the need to. Yes the latter is probably the reason for the former.

Let’s look into why we might not think commenting or documenting our expectations and best practices in the document may be worthwhile. The first reason is that comments make our CSS file larger in file size. Yes – this is certainly true but we can easily use YUI compressor or write simple scripts to automate the process of minifying and removing comments from our production code.

The second reason might be that you’re the only author touching the stylesheet. This is incredibly short sighted. Always always (always!) plan on someone else touching your stylesheet at some point in time. Chances are you are not the only one who will be working on the project for eternity. In other words – count on the fact that someone else will eventually be writing code in your stylesheet as well. You may as well make it clear to them as to how they should do it to maintain a consistent stylesheet. Otherwise you may find yourself cleaning up a big mess later when you’re called back to work on a broken site!

Being expressive is easier said than done though. How do you go about declaring how you expect things to be done? I personally embed my best practices in a short set of directions complete with an example in a comment at the top of all of my stylesheet files. The snippet looks like this:

The point here is you can utilize comments to make things very clear in a simple elegant fashion. Just document your CSS as you should be documenting all of your code. Textmate users can benefit from a CSS commenting bundle I put together a few years ago to quickly document and section apart their stylesheets. What you need to remember regarding expressiveness in your CSS is the following:

• Utilize comments to define how CSS should be formatted and written for other authors.
• Always count on the fact that someone other than you will probably work in this document at some point in time.
• Utilize comments to organize your code into sections. Comments can effectively become a navigation system within your CSS document.

I’ve explained in depth how to get it setup on your blog/website. Encouraged commentary will work in wordpress, textpattern, moveable type, typo, mephisto, drupal, expression engine, etc.. There is no plugin required. You just have to make some minor changes to the HTML markup in your theme or template files. To get started:

• Grab the source code from github.
• View the Wiki for detailed directions.

• Download the Flash Player Debugger version.
• Create an alias in your profile to tail the flashlog.

Creating an Alias Command

Once you install the debug player, any movie you open in your browser will output it’s trace commands to a flashlog.txt file. This is normally located in the Library directory for your user. So we’re going to make an alias to open it quickly in terminal. If you’re not familiar with alias commands think of them as shortcuts in terminal.

Let’s get straight to the meat of it. First we have to find our flashlog. By default the flashlog is stored here:
/Users/[your system username]/Library/Preferences/Macromedia/Flash Player/Logs/flashlog.txt'

If for whatever reason you aren’t getting a flashlog you may need to look into taking some simple modifications to your mm.cfg file.’ Otherwise you should be ready to make your alias command.

We want to put our alias command in our shell profile so that the shortcut will be available for us automatically when we open up terminal. To do this launch a new terminal window and type:
nano ~/.bash_profile

Nano works like a regular text editor, so simply paste the alias command below any existing statements in the document, be sure to replace your system username with your actual user name:
alias fl='tail -F /Users/[your system username]/Library/Preferences/Macromedia/Flash\ Player/Logs/flashlog.txt'

Now that you’ve done that hit ctrl-o to save the changes you’ve just made to the file and ctrl-x to exit nano. Now close the terminal window and open a new terminal. Type ‘fl’ and press enter. You can now see the live output as any instance of the player writes output to the flashlog. If you want to stop viewing output just hit ctrl-c while you’re in the terminal window to close the stream.

What the presenter initially did was build out a traditional presenter class to extend the model and provide two methods to find possible status and priority objects from the database. This requires the author to delegate class methods from the model that the Presenter class could use. It also requires us to wrap any instance variable of the child object in the presenter class before we pass it to the view.

class StoryPresenter

  def initialize(story)
    @story = story
  end

  delegate  :id, :class, :errors, :to_param, :new_record?,
            :to => :@story

  def possible_statuses
    @statuses = Status.find(:all).map{ |s| [s.name, s.id] }.unshift []
  end

  def possible_priorities
    @priorities = Priority.find(:all).map{ |e| [e.name, e.id] }.unshift []
  end

  def method_missing(name, *args)
    @story.send name, *args
  end

end

And then the implementation in the controller looks something like this:

def create
  story = @project.stories.build(params[:story])
  respond_to do |format|
    format.js do
      @story = StoryPresenter.new story
      render :action => "stories/new" unless story.save
    end
  end
end

A member in the audience suggested that instead of treating the presenter as a traditional presenter object we simply write it as a module. Then we no longer would have to delegate the methods from the model and instead of wrapping any instance variable of the child class we could just extend it. The argument for this is clear. It’s less code, and it’s more flexible.

module StoryPresenter

  def possible_statuses
    @statuses = Status.find(:all).map{ |s| [s.name, s.id] }.unshift []
  end

  def possible_priorities
    @priorities = Priority.find(:all).map{ |e| [e.name, e.id] }.unshift []
  end

end

And then the implementation in the controller looks something like this:

def create
  @story = @project.stories.build(params[:story])
  respond_to do |format|
    format.js do
      @story.extend StoryPresenter
      render :action => "stories/new" unless @story.save
    end
  end
end

However, the arguments against using a presenter as a mixin are more philosophical. If we’re using the presenter pattern we should encapsulate only what we need the view to use explicitly to prevent logic leaking into the view or the controller by other authors. By treating the Presenter object as a class and explicitly delegating the model methods we do just that. To utilize further methods of the model we would need to return to the presenter object and extend it there as opposed to just sliding extraneous logic into our controller or view.

In my presentation I briefly explained the concept of syndication via RSS and Atom – then touched on a high level overview of what a CMS system is used for. This was mainly to acknowledge the fact that not that many people are keen on the how or why of RSS. After demystifying the essential technologies involved, I focused on what blogging is really about. You can check out my slides below or view it in fullscreen.

• Disclaimer: You can click through them to proceed, but you can’t step back. This is due to a shortcoming in Keynote’s export to flash functionality. I wrote a viewer tool to load the .swf file created by keynote to preload it, but I could not interact with the movie itself as it’s an older format of SWF.

Use the Minimum Necessary to Communicate Meaning

Unfortunately, life is not so simple for the HTML author. Technology binds us to complications that create an environment that is less precise, less absolute, than merely writing a sentence. But if you can put the pressures we face from design implementation and browser support aside to focus on the basic semantic meaning; you will find that the aforementioned complexity is quite easy to deal with by incorporating small tweaks to your HTML. Here are two primary points in regards to the over complexity of HTML when thinking in terms of implementation as opposed to meaning.

• Writing HTML based purely on semantic meaning results in much clearer and flexible HTML that is easier to style and maintain.
• Complications during implementation are best tackled by adding superfluous markup to correct a problem as it arises rather than preemptively.

Only Add Superfluous Markup After Challenges Arise

Here is an example. Let’s say we have a body of content containing two unsorted lists with four items a piece. Now let’s say we want the unsorted lists in this body of content be styled differently from the general rules we have already applied. If we wanted the absolute most flexibility, we could have preemptively given each list item (<li>) it’s own class. That would be a total of eight elements with additional markup. We could reduce this to only two elements by simply applying a class to the unsorted lists (<ul>) and leaving the list items bare. Or, provided the body of content is encapsulated in it’s own HTML element to semantically describe the associations between the content elements, we could give the containing object a class or ID. Let’s say this body of content is the secondary content on the page. We could give the encapsulating div a class, thus reducing the amount of marked up elements from eight to one.

Only Use Containing Elements to Construct Associations

It’s far to easy and common to find html documents that have nearly every individual element wrapped in it’s own division (<div>) but this is a terrible breakdown in semantics. These excessive containers create meaningless layers of information that add no semantic value to the document. Elements certainly need to be packaged into other containing elements but only when they need to be associated to each other.

• There should never be a time when a lone element is enclosed in it’s own containing element.
• If an element is alone in a container – it should be strong enough to stand on it’s own and the containing element should be eliminated.

Take this blog as an example. This post contains many headings, paragraphs, and unsorted lists. It makes sense to enclose the content of this entry into it’s own division to symbolize that all of these various elements are part of a larger body of content. A single heading, paragraph, or bullet point in this post could not stand on it’s own to communicate the message of this article. Think about that when trying to make sense of when you should or should not apply a containing element. In other words, when writing a long novel you would not put every single sentence on it’s own page. Wrapping every single paragraph, image, and list of your content into a <div> is not so different.

Don’t Think Like a Designer

Table based layouts are the greatest hack of all time. When CSS was young and poorly implemented complex layouts could only be achieved by putting all of our HTML into table elements, and layers of nested table elements to follow. But this totally contradicted the point of HTML. The goal of HTML is to provide a clear, well described document. If you have a list of sections that you’re reader might be interested in browsing to then those links should be described as just that, a list. A transcribed dialogue communicated by different people should use a definition list tag. Most importantly, if we have a form with fields we need labels. What better element to use than a label tag?

All of this sounds remarkably straightforward but if you’re not thinking like a definer and instead are thinking like a designer then you’ve gotten you’re approach to HTML all wrong. Dead wrong. Worry about the design later. Right now the focus is entirely on the content. How is this content best segmented? How is it best described?

Preview Your Work as Basic HTML

When writing HTML don’t get tempted to start writing any of the CSS yet. Especially any inline-styles. There are few times you should say never, but use of inline-styles is something you should never do. As you write your HTML preview it in your browser as only HTML. No CSS. Just HTML. This will help you visualize how your document is viewed naturally by machines and is a true testament to the portability of your document. Without CSS you’re document should be well laid out and presented as if it were an outline or a basic one column word doc. Line lengths, columns, other layout crap – worry about all of that presentation later. Just keep your focus on making that plain text document as clear and legible as possible. Here are some tips for previewing pages:

• If you have an existing site use firefox and get firebug or the web developer toolbar to disable your stylesheets.
• Run the W3C validator on your page and be sure to check the ‘Show Outline’ option to ensure the hierarchy of your content makes sense.

Names Things What They Are – Not What They Look Like

Let me introduce you to your new hypothetical friend Joe. We call him Joe because that’s Joe. His name isn’t Brown-haired-middle-aged-guy. What if Joe died his hair green? Would his name still make sense? People don’t often legally change their names, but they do change their appearance quite often. So does your HTML, yet a lot of us still use that poor approach to naming items in our HTML markup. Make sure you name your content for what it is – not where it goes, or how it looks. If you have a sidebar don’t name that div with an ID of ’sidebar’! That data might be presented visually as a sidebar but that’s not what the div actually is. What’s inside of that div? A list of related messages? Maybe that div shouldn’t be a div at all. Maybe it should be an unsorted or ordered list with an id of ‘related-messages’.

Break the Connection – Make the Separation in Your Mind

The key thing to walk away with here is to break your thinking that HTML is the markup that makes your site design. That is all done entirely external from the HTML in your CSS code. When you’re assigning class names, ID’s, or choosing what HTML element to use to describe something just remember. This should be about what it means, not what it looks like.

Finding the @usernames and HTTP Addresses

So this is where we actually utilize RegExp. In Flash RegEx works very similar to other programming languages. You simply define a new variable as a with :RegExp class and then assign it a pattern. I used two separate patterns, one matches users, the other matches the http addresses. I won’t go into detail on explaining the RegEx patterns itself here as that is an entirely different topic. What I’m focusing on here is how to implement them in flash. But just for the heck of it, incase you want to take tese and make them better here are the two regular expression patterns I wrote:

• ‘@usernames’: /(\s@+\w*(\s|,|!|\.|\n))/
• ‘http://…’: /[^"|^>](http:\/\/+[\S]*)/

So here is the actual code I use in the widget above. The only difference is the ‘cur’ variable on the first line passes the current title from the twitter RSS feed instead of the dummy string I’ve hardcoded:

private function dropRSS():void {
	var cur:String = "Hey @sunnythaper, @shalerjump, @jamesarcher! Check this out: http://tinyurl.com/377owu"
	if (cur.substr(0,1) == "@") { 			// Skip response messages as they do not always provide enough context to be stand alone statements.
		_current++;
		dropRSS();
	} else {
		cur = cur+" "; // Append a space at the end so RegEx catches trailing expressions

		var twitterUser:RegExp = /(\s@+\w*(\s|,|!|\.|\n))/;		// "
		var url:RegExp = /[^"|^>](http:\/\/+[\S]*)/;

		while(twitterUser.exec (cur) != null) {
			cur = cur.replace(twitterUser, pointToUser);
		}

		while(url.exec (cur) != null) {
			cur = cur.replace(url, setUrl);
		}

		twit.htmlText = cur;
		TweenLite.from(twit, 2, {ease:Elastic.easeOut, y:"-10", alpha: 0});
		_current++;
	}
}

What’s important to take note of is two things: 1) I need to loop and execute the pattern onto the string until it no longer finds any matches 2) I’m passing a function as the second parameter in the replace method as opposed to an alternate string.

• This has worked great but fundamentally I think there is a more efficient way of doing this without looping and executing the RegEx so many times.
• If you know a better way let me know and I’ll update this post.

Implementing Changed on Your Matches

As I said, I’m passing a function to actual handle the replacement as opposed to just passing a replacement string. This is because I need to run some processes on the matches to build urls based off of them. Flash lets you reference the matches in the functions as arguments. Here is the code.

	private function pointToUser():String {
		return " <a href=\"http://twitter.com/"+arguments[1].substr(2,arguments[1].length-3)+"\">"+arguments[1].substr(1,arguments[1].length-2)+"</a>"+arguments[1].substr(arguments[1].length-1,1);
	}

	private function setUrl():String {
		return " <a href=\""+arguments[1]+"\">"+arguments[1]+"</a>";
	}

Of course, if the RegEx pattern generated two or three differently matched terms you could reference them as well via arguments[2], arguments[3] etc.. Here you can do whatever you want. I chose to disect the one argument I was working with through a series of substring routines to trim out unwanted characters in certain parts and then re-insert them outside of the html.

Adobe LiveDoc References:

• Adobe Live Docs: Replace Method
• Adobe LiveDocs: RegExp Object
• Adobe LiveDocs: Regular Expression Syntax
• RegExhibit – RegEx Tool for OSX

	var DynamicExtensions = {
	    dynamicize: function(element){
	        element.dHref = element.href;
			element.dTarget = element.target;
			element.href = "#"+element.target;
			element.target = "";
			element.dynamic = dynamicallyLoad.bindAsEventListener(element);
			Event.observe(element, 'click', element.dynamic);
			return element;
	    }
	}

	Element.addMethods(DynamicExtensions);

	function dynamicallyLoad(e) {
		element = Event.element(e);
		new Ajax.Updater(element.dTarget, element.dHref, {
			method: 'get',
			onComplete: function() {
				setLinks(element,element.dTarget);
				new Effect.Highlight(element.dTarget, {duration: 1});
			}
		});
	}

	function setLinks(e, target) {
		(target) ? selector = '#'+target+' ' : selector = '';
		$$(selector+'a.dynamic').invoke('dynamicize');
	}

	Event.observe(window, 'load', setLinks);

Download & Demo

• View a Demo
• Download the source.

How You Use It

I’m big on javascript that is unobtrusive – so other from including the script (along with prototype.js) all you have to do is assign a class and target to your designated anchor tags. Here’s a breakdown:

• You give the target element an ID in HTML.
• You set the target value of the link tag to the ID of the element.
• You assign the class of the anchor tag to ‘dynamic’.

So the link in the example below would load test.html into the div with the ID of content.

	<div id="content"> This content will be replaced once
	the link below is clicked.</div>
	<a target="content" href="demo.html" class="dynamic">Load Demo</a>

Important Lessons Learned

I said at the beginning of this post I’m not really a javascript expert so this was a learning process for me. The greatest challenge for me was understanding how binding works – it’s something I’m still slightly confused on actually. How to reference functions with callbacks was an additional challenge. Overall I would say there were three main ‘gotchas’ that stumped me for a while.

Callbacks need to be functions to call functions: if you use a callback like ‘onComplete’ you can’t just say ‘onComplete: myfunction()’. Instead you must do something like ‘onComplete: function() { myfunction(); }’. If you don’t the function get’s executed as the assignment to the callback is interpreted. I believe I’m explaining that right. In my case the effect was rendering immediately when you clicked on the link as opposed to delaying until the new content had loaded. This was very bad because if the new content contained dynamic links the script couldn’t bind the event behaviors to them.

Elements need to be extracted from an Event object: in my dynamicallyLoad function I wanted to refer to the object that triggered the event as ‘this’. I thought I could because I binded the function to it as an event listener but that’s where I confused myself. What you need to do is reference the Event object and then get the element from that. That is why the first line of the function reads ‘element = Event.element(e);’.

This script is not rocket science, but it is a useful starting place for me in a lot of projects that need to make minor use of AJAX updates on click. I’ve already expanded this to be less generic to suit the current project I wrote it for. I’ll share with you more basic prototype lessons as I get more chances to utilize it in forthcoming projects.

• Download the code.

Note: I bundled the source with a compressed version of Scriptaculous and Prototype. You can learn more about these compressed versions of prototype at the Google Code project page.