Tag Archive: My Best Portfolio

There are many benefits of using CSS. Maintenance of a Web site made with CSS is much easier compared to the ones which are table based. Aside from being able to make extensive changes with one CSS file, the code it generates makes it simpler to update. With CSS, when you decide to craft a change, you simply alter the style and that element is updated automatically anywhere it appears in the site, saving you an enormous amount of time. Without CSS you’d have edit each page independently. CSS generally requires less code compared to a table based layout, making your code lighter, cleaner and easier to maintain.

Cascading Style Sheets Benefits and Search Engine Optimization (SEO)

Another major benefit of CSS is that it makes your Web site SEO friendly. The reason behind this is simple. Search engines spiders are actually lethargic. They don’t go through the bundles of HTML code to get to the indexed codes. Font tags and tables make HTML code cumbersome, and thus reduce the accuracy of the results.

Continue reading


Making changes to the layout
CSS makes it very easy to change the style of a document. Let’s say we wanted to move the picture in the title of this page to the right by 10 pixels. This would be a nightmare in a table based design. We would have to open every page and alter the table width manually.

Fortunately we have used CSS, and all we have to do is open our CSS file which stores the layout of the site, and change the number relating to the position of the image. That will change his position throughout the whole site.

The look and layout of a site can be changed beyond recognition just by altering the CSS file. This makes CSS indispensable for large web sites.

File Size
Probably the mostly useful feature of CSS is that all of the style and layout is removed from the html, so the html page size is very much smaller. The CSS file is downloaded just once by the visitor’s browser and re-used for different pages on a web site. This reduces the bandwidth requirements for your server and also ensures a faster download for your visitors.

Search Engines
A search engine robot will normally consider the content in the start of your html code is more important than the text towards the end of the code. For a table based page the contents of the navigation bar will normally show up as the page description in search engine results. With a CSS page the navigation can be moved to the bottom of the source code, so the search engine displays your content instead of your navigation.

Separating style from content makes life very easy for visitors who prefer to view only the content of a web page, or to modify the content. These could be blind or partially sighted people who might use a screen reader to interpret a page.

Layout and position of navigation can be completely consistent across a site. This was previously possible only using frames.

Disadvantages of CSS
CSS does not work consistently in different browsers. Microsoft Internet Explorer and Opera support CSS in a pretty logical way. Unfortunately their logic does not conform to current CSS standards.

Netscape and Firefox conform more closely to the standards, so a site could look quite different on Internet Explorer from the way it looks in Firefox. This discrepancy restricts the CSS features that can be used on a site – because Firefox is becoming more and more popular the site must be designed for both Firefox and Internet Explorer.

Dreamweaver MX design view has it’s own set of limitations (although I’m told Dreamweaver 2004 is an improvement).

CSS doesn’t work at all in very early versions of Internet Explorer and Netscape. These browsers will display your page as plain html. This is not necessarily a problem – a quick look at our logs suggest that less than 0.1% of visitors are using browsers that are incompatible with CSS, and they will still be able to use our pages, just without the layout.

10 CSS Tips

01. Keep CSS out of the markup.

Linking and/or importing stylesheets would seem to be a no-brainer to the intermediate or advanced CSS developer, but I want to stress why this is so important. I’ve seen many sites start out with clean, well-organized CSS files but then get littered as time goes by, with embedded or even inline styles (due to fast updates needed on short deadlines, or possibly sometimes even pure laziness).

Imagine that you are working on an extremely large-scale website with hundreds of ways content can appear. You have fast deadlines, so you opt for making “quick fixes” or updates by using embedded or inline CSS. Years go by, and this habit continues… Until one day you’re told the site is being completely redesigned (but all the content is to remain the same), and you only have a week to build it (including testing).

Normally, this would have been a fairly simple task of updating the stylesheet(s). Except you have years worth of “quick fixes” scattered throughout the site — and no way to remember where they all are. So now you have to either a) find a way to clean everything up and get everything styled for the redesign in one week (Good luck!), or b) find a new job.

Don’t make your job harder than it really has to be. Linking and/or importing your stylesheets is not optional. Create it clean, keep it clean, and you’ll be much happier.

NOTE: Be careful of adding too many linked and/or imported stylesheets in your markup. If you’re tempted to create a new stylesheet every time you make an update or add new content, you’re not doing yourself any favors. Excessive linking and/or importing can make bug-fixing difficult, and make your styles harder to maintain. It is understandable to want separate stylesheets for different sections or components for larger websites (I’ll go more into that later). Just be careful that you don’t go overboard.

It is worth mentioning that linking too many stylesheets requires additional HTTP requests, which can add up, and potentially hinder performance. Also, Microsoft Internet Explorer 6 has a limit of 32 linked stylesheets.

02. Semantics is not just a buzz word.

You know I have to bring it up; semantics are your best friend. Beyond choosing the most appropriate, meaningful elements to describe your content, make sure also that you’re choosing semantic class and ID attribute values. Besides being the “right thing to do,” it really does make your life easier (and it makes the lives of your fellow team members easier too– if you working as part of a team). Take a look at the following rule:

.l13k { color: #369; }

If you were new to the job, and you saw that in the CSS file, are you going to know right away what that class is for? Most likely not. This class name could be an abbreviation for something, but there’s no real way you can tell right off the bat. Alternatively, maybe you put it there, so you know what it means, right? Today. But will you know what it means three years from now?

Now, let’s take a look at this rule:

.left-blue { color: #369; }

You might immediately know what purpose this class selector serves as you know exactly where the left-side blue module appears. So it would appear that this works. Until along comes that redesign you have to build in a week, as I mentioned earlier. In the redesign, this module is now to be positioned on the right, and colored red. The class attribute values no longer makes any sense, so now you have to either change all your attribute values, or leave it as it is (which could lead to mass confusion).

It is always best to refrain from using colors (either the color name or its hex value) or width/height dimensions in your class attribute values. You should also avoid any attribute values that are presentational (such as “box”).Presentational attributes defeat the purpose of separating presentation from content.

Finally, let’s look at this more appropriately named rule:

.product-description { color: #369; }

Here you can see that the rule styles product descriptions, no matter how many times your design changes. Clarity is a beautiful, beautiful thing.

03. Take advantage of commenting.

Commenting your CSS files can be a great deal of help to you and others during development if you use comments in creative and meaningful ways. At the most basic level comments provide little reminders why a certain rule is used. But you can use comments to really help improve organization and efficiency.

Reminders and notes

The common approach for commenting, leaving reminders and notes for yourself and other developers can help avoid confusion later. Keep these brief and simple. For example:

 /* Turn off borders for linked images */ img { border: 0; } 

Time stamp and signature

Some designers and developers also note the date and time that the CSS file was last updated, along with their name or initials. This information can provide a quick indicator of who to contact, as well as how up-to-date the file is.

 /* Sushimonster Typography Styles    Updated: Thu 10.18.07 @ 5:15 p.m.    Author:     Jina Bolton    ----------------------------------------------------*/ 

Depending on the project, this can be a good idea, particularly if you are working on a team. Keep in mind that some organizations require leaving this type of information out (some companies prefer to keep names and dates out of files), so it is best to find out if there is a mandate on this sort of thing.


It’s a good idea to use comments to indicate the different sections within a CSS file. For example, if all header styles are grouped together, you can use a comment to section these styles off from the next section’s styles:

 /* HEADER    ----------------------------------------------------*/ 

I’ll go more into this a little later, when discussing “Separating style types.”

Comment flagging

If you have your CSS file organized into sections as I described above, comment flagging can also be useful to make it easier using FIND to skip down or up to the parts of the file you want to see. You can use a character (such as an equal sign [=]), along with a keyword (typically the name of the section, such as “HEADER”) to provide “anchors” in your CSS file:

 /* =HEADER    ----------------------------------------------------*/ 

This is particularly useful in long and complex stylesheets. You can read more about this at Stop Design.


A less common, but nonetheless useful approach is to use comments as reference guide. One example of this might be to include a color guide as you can see in Steve Smith’s CSS file:

 /* COLORS    Body Background:       #2F2C22    Main Text:             #B3A576    Links:                 #9C6D25    Dark Brown Border:     #222019    Green Headline:        #958944 */ 

You should place this guide at the top of your CSS file to help you remember what color values you use throughout your site. Another example is of an index-like approach. Here you can define different sections so that you can jump down to them (perhaps by using comment flagging). Here’s one example:

 /* GENERIC    HEADER    SIDEBAR    FORMS    TABLES    FOOTER */  /* =GENERIC    ----------------------------------------------------*/ 

04. Know when to use conditional comments or hacks.

There are many articles regarding the problem with hacks, and why Conditional Comments are a better way to handle Internet Explorer issues. Then there are articles that say otherwise. While I agree that Conditional Comments can be a much better solution than littering your CSS file with hacks, only recently have I come to realize there are instances where they are actually not the most appropriate solution.

Imagine that you want to set a minimum height for an element. The IE6 developers did not implement min-height, so you know that you can use height, which will be treated the same way. Does it make sense to create a whole new stylesheet, and inject it by way of Conditional Comments in your markup, when all you need is this one rule? Would it make better sense to keep the min-height and height rules together, and opt for a small “hack” within the same CSS file? In this case, I would consider it less efficient to use Conditional Comments.

Another thing to consider: if you have multiple places that your styles are located, using multiple CSS files and Conditional Comments can make your debugging process more difficult. Also, if you need to alter something (perhaps the min-height value in the above-mentioned scenario), you have to open more than one file to make this change. In many cases, this may not be such a big deal for you, but imagine if you have something defined in your main CSS file, and then redefined in 3 different IE stylesheets. That could turn out to be a hassle later down the road, especially if another developer making the edit doesn’t realize that these overrides exist.

If you do use Conditional Comments, I recommend leaving a comment in your main stylesheet letting you or a fellow developer know that an IE-specific rule exists. That way when you have to edit a height or something of that nature, you know that you have more than one file to open.

As always, if you do use hack, remember that browser updates can change what works later down the road, and the hack you use now may not work later versions.

05. Organizing selectors and declarations

Always, always keep your CSS clean and organized. I prefer organizing my selectors by style groups:

  • reset styles
  • typography styles
  • layout styles (header, content, footer, etc.)
  • module or widget styles
  • etc.

Then, within each of those groups, I organize selectors by DOM hierarchy (working down the page, from the outside in):

  • any parent styles (containing elements, working outside-in)
  • block-level element styles (paragraphs, lists, etc.)
  • inline element styles (links, abbreviations, etc.)
  • etc.

Then within those, I work by element types:

  • paragraphs
  • blockquotes
  • addresses
  • lists
  • forms
  • tables
  • etc.

Finally, I prefer to organize my CSS declarations by style type:

  • positioning (with coordinates) styles
  • float/clear styles
  • display/visibility styles
  • spacing (margin, padding, border) styles
  • dimensions (width, height) styles
  • typography-related (line-height, color, etc.) styles
  • miscellaneous (list-style, cursors, etc.) styles

Some people like to organize declarations alphabetically. It doesn’t make sense to me, but it might make perfect sense to you. Whichever method you choose, stick with it, and be consistent.

06. Creating a framework

When it comes to developing CSS, If you find yourself doing the same things repeatedly, it is a good idea to consider creating a library or framework. A framework can be made up of a group of stylesheets that act as a foundation for your site, and help speed up your development time. Typical stylesheets you may find in your framework might include:

  • screen.css – A screen CSS file can either have all your styles you want to be used for on screen, and/or can import additional styles, such as the following:
    • reset.css – A reset CSS file can be used to “reset” all the default browser styling, which can help make it easier to achieve cross-browser compatibility.
    • typography.css – A typography CSS file can define your typefaces, sizes, leading, kerning, and possibly even color.
    • grid.css – A grid CSS file can have your layout structure (and act as the wireframe of your site, by defining the basic header, footer, and column set up).
  • print.css – A print CSS file would include your styles you want to be used when the page is printed.

One example of a framework is the Blueprint framework put together by Olav Bjørkøy (which based itself off of work developed by authors including Jeff Croft and Eric Meyer). Another popular framework can be found at the Yahoo! User Interface Library. Many developers do feel that these pre-built frameworks contain markup and CSS that are a bit “bloated” and also that they contain presentational class attribute names.

For the best results, I recommend that you create your own framework that works best for you or your organization.

07. Balance readability and optimization.

Styles in formatting vary from developer to developer. Some developers use formatting styles that offer great readability, and then optimize the files (removing comments, spaces, tabs, carriage returns, etc.) before pushing the file live. This is a great technique and one I would recommend (done carefully). However, if you are somehow in a situation where you can’t really go through those steps, try to find a style that balances readability and optimization. Steve Smith has a great suggestion that offers a little bit of both.

Also, consider using hyphens instead of underscores. Microformats use hyphens as a standard separator, and certain older browsers have a hard time with them. You can read more about this at Underscores in class and ID Names.

08. Master your text editor.

Just as an artist has proper tools they know well, it’s important for a designer/developer to know the tools they use well. For CSS, that would be the editor you are using.

There are many text editors to choose from: TextMate, Coda, BB Edit, TextPad, DreamWeaver, etc. I’m not here to tell you which one to pick; they all have their pros and cons, and the right editor for you is up for you to decide. However, once you have decided on a text editor, make sure you learn everything you can about it. Find out what the shortcuts are, and learn all the tips and tricks you can.

Mastering your text editor is the best way to speed up your development time, and help you be more much more efficient when creating sexy stylesheets.

09. Use version control.

Smoother maintainability is also an important part of creating sexy stylesheets. This is where version control can be your best friend. It’s not only helpful for teams, but it can be a lifesaver even for the sole designer/developer.

Some applications have built-in mechanisms for source control. DreamWeaver uses a check-in/check-out system (that can help make sure that a developer doesn’t edit a file that is already currently being edited), as well as synching capabilities (which lets you sync and merge your local files with your remote files, or vice versa). This can be very handy, but are somewhat limited.

Subversion (SVN) or Concurrent Versions System (CVS) are great tools to use for more robust management, with additional options, like being able to revert, view changes (which is extremely helpful for teams — you can track who added/edited/removed code and when they did it), and resolving conflicts. There’s a great article by Jonathan Snook, called “Hosted Subversion” you can read for more information on how to set this up quickly and easily.

10. Create and maintain a style guide.

While in some cases, a style guide is an author’s guide with grammar rules and writing standards, it can also be used to outline standards for design, development, and content. A style guide is a great way to have a reference manual that can clarify rules on typography, grid, color, image sizes, etc.

When creating a style guide, it is a great idea to provide reference for the markup and CSS. This reference can be used as a handbook for the development team and future developers. It can include defined layouts, in which you can list the different layouts that can be used, and provide the associated markup and styles.

Finally, you can also leave steps for quality assurance for developers, (such as checking validation and accessibility) to ensure the highest quality.


Being an expert in CSS is so much more than having advanced CSS skills (i.e.: fully understanding the cascade, the box model, and how browsers work). I encourage you to think about ways you can constantly and consistently improve maintainability and efficiency. Think beyond what is designed in the comp, even if that is all that you have been provided. Make the CSS intelligent and plan for the future. Overall elegance in workflow is essential to master.

Web 2.0

An umbrella term for the second wave of the World Wide Web. Sometimes called the “New Internet,” Web 2.0 is not a specific technology; rather, it implies two paradigm shifts. The one most often touted is “user-generated content,” and the second is “thin client computing.”

1) The User Rules!
User-generated content, comprised of blogs, wikis and social networking sites, such as Facebook,Hi5,MySpace and Friendster, let everyone have their say on anything and publish it to the world at large. As Web applications become more sophisticated, people can easily develop elaborate personal Web pages, create a blog, and upload their own opinions, audio and video. Users are augmenting the news by reporting current events sometimes faster and with details often overlooked or ignored by the professional news media.

Although millions of opinions and videos, often very amateurish, only add to our information overload, a significant advantage to user-generated content is that truly talented authors, artists, musicians and movie makers can gain an audience much more easily than they could in the past. Word-of-mouth via the Internet is worth a fortune in promotion. Web 2.0 is leveling the playing field in all arenas just as the PC leveled the playing field in business. See blog, wiki, social networking site, MySpace, YouTube and paradigm.

2) Thin Client Computing
In thin client computing, data and applications are stored on Web servers, and a user has access from any computer via a Web browser. Thin clients are not a new concept for the Internet, but many believe that thin client computing will eventually supplant locally installed office and other applications and that turning the Web into a gigantic application server is the ultimate manifestation of Web 2.0.

In time, this could have significant impact on the type of personal computers users choose. As more software is executed from scripts embedded in Web pages, the CPU chips and operating systems become less relevant. Browsers interpret scripts the same way no matter which hardware or software environment they reside in.

In 2007, Google combined several of its office applications into Standard and Premium Editions, the latter a paid service with tech support. Because of Google’s influence, this was a watershed event for thin client computing and Web 2.0 (see Google Apps). See ASP, Web application and Enterprise 2.0.

What Caused Web 2.0?
Bandwidth and power. Faster in many cases than the T1 lines in the enterprise, cable and DSL hookups have extended high-speed connections to individuals and small businesses. In addition, the entry level computer has become powerful enough to execute programming scripts in an HTML page without noticeable delays. Combined with refinements in Web programming, the Web has become a transparent extension of an individual’s PC just as local area networks (LANs) extended the user’s computing resources inside the enterprise in the 1980s and 1990s. See AJAX.

Web Evolution
In the mid-1990s, the Web began (Web 1.0) as a repository of information and static content. Within a couple years, a huge amount of content was dynamic, returning custom results to users. By the turn of the century, the Web became much more interactive (say Web 1.5), allowing users to play, stop, rewind and fast forward through audio and video content. Web 2.0 makes Web-based applications act like local applications, but on a worldwide scale with the social implications mentioned above. In the discussion of Web 2.0, the 1.0 and 1.5 generation labels may be used occasionally, but there is no formal classification.