Вы находитесь на странице: 1из 10

What Beautiful HTML Code Looks Like

By Chris Coyier On 11/9/2009 With 264 Comments I originally wrote this over two years ago. It was getting a little long in the tooth, especially now that HTML5 has come along and made HTML far more beautiful than even XHTML 1.1 was. So I updated it! I can't help but view source on every nice looking website I see. It's like if you had x-ray glasses that allowed you to see any person you ever saw in their underwear at will. How could you not? It's just so tempting to see if a beautiful website is built with beautiful code as well, or if its beauty if only skin-deep. Code? Beautiful? Sure. After all, Code is Poetry. This is just HTML, so it can't be quite as intricate and elegant as a dynamic language, but it still bears the brush strokes of its creator. It gets me to thinking, what makes beautiful code? In HTML, it comes down to craftsmanship. Let's take a look at some markup written they way markup should be written and see how beautiful it can be.

Large PNG Original PSD Text of HTML

It's big enough to print out and tape up inside your locker to impress your friends. Well, it might be a bit of an awkward size. I'll make the PSD available in case you want to alter it.

HTML5 - HTML5 and it's new elements make for the most beautiful HTML yet. DOCTYPE - HTML5 has the best DOCTYPE ever Indentation - Code is indented to show parent/child relationships and emphasize hierarchy. Charset - Declared as first thing in the head, before any content.

Title - Title of the site is simple and clean. Purpose of page is first, a separator is used, and ends with title of the site. CSS - Only one single stylesheet is used (media types declared inside stylesheet), and only served to good browsers. IE 6 and below are served a universal stylesheet. Body - ID applied to body to allow for unique page styling without any additional markup. JavaScript - jQuery (the most beautiful JavaScript library) is served from Google. Only a single JavaScript file is loaded. Both scripts are referenced at the bottom of the page. File Paths - Site resources use relative file paths for efficiency. Content file paths are absolute, assuming content is syndicated. Image Attributes - Images include alternate text, mostly for visually impaired uses but also for validation. Height and width applied for rendering efficiency. Main Content First - The main content of the page comes after basic identity and navigation but before any ancillary content like sidebar material. Appropriate Descriptive Block-Level Elements - Header, Nav, Section, Article, Aside... all appropriately describe the content they contain better than the divs of old. Hierarchy - Title tags are reserved for real content, and follow a clear hierarchy. Appropriate Descriptive Tags - Lists are marked up as lists, depending on the needs of the list: unordered, ordered, and the underused definition list. Common Content Included - Things common across multiple pages are inserted via server side includes (via whatever method, language, or CMS that works for you) Semantic Classes - Beyond appropriate element names, classes and IDs are semantic: they describe without specifying. (e.g. "col" is much better than "left") Classes - Are used any time similar styling needs to be applied to multiple elements. IDs - Are used any time an element appears only once on the page and cannot be targeted reasonably any other way. Dynamic Elements - Things that need to be dynamic, are dynamic. Characters Encoded - If it's a special character, it's encoded. Free From Styling - Nothing on the page applies styling or even implies what the styling might be. Everything on the page is either a required site resource, content, or describing content. Comments - Comments are included for things that may not be immediately obvious upon reviewing the code. Valid - The code should adhere to W3C guidelines. Tags are closed, required attributes used, nothing deprecated, etc.

10 Best CSS Practices to Improve Your Code

CSS, Code, Programming 164

Its really easy to find yourself wondering how your CSS got to be such a mess. Sometimes its the result of sloppy coding from the start, sometimes its because of multiple hacks and changes over time. Whatever the cause, it doesnt have to be that way. Writing clean, super-manageable CSS is simple when you start off on the right foot and make your code easier to maintain and edit later on. Here are 11 tips for speeding up the process, writing CSS that is slimmer, faster and less likely to give you a headache.

1. Stay Organized
Just like anything else, it pays to keep yourself organized. Rather than haphazardly dropping in ids and classes in the order in which they come to mind, use a coherent structure. It will help you keep the cascading part of CSS in mind and sets your style sheet up to take advantage of style inheritance. Declare your most generic items first, then the not-so-generic and so on. This lets your CSS properly inherit attributes and makes it much easier for you to override a specific style when you need to. Youll be faster at editing your CSS later because it will follow an easy to read, logical structure. Use a structure that works best for you while keeping future edits and other developers in mind.

Resets and overrides Links and type Main layout

Secondary layout structures Form elements Miscellaneous

2. Title, Date and Sign


Let others know who wrote your CSS, when it was written and who to contact if they have questions about it. This is especially useful when designing templates or themes.

Wait a minute whats that bit about swatch colors? Over the years, Ive found that adding a simple list of common colors used in my style sheets is extremely helpful during initial development and when making edits later on. This saves you from having to open up Photoshop to sample a color from the design, or look up colors in the sites style guide (if it has one). When you need the HTML code for that specific blue, just scroll up and copy it.

3. Keep a Template Library


Once youve settled on a structure to use, strip out everything that isnt generic and save the file as a CSS template for later use. You can save multiple versions for multiple uses: a two-column layout, a blog layout, print, mobile and so on. Coda (the editor for OSX) has an awesome Clips feature that lets you do this easily. Many other editors have a similar feature, but even a simple batch of text files will work nicely. Its insane to re-write each and every one of your style sheets from scratch, especially when youre using the same conventions and methodologies in each.

4. Use Useful Naming Conventions


Youll notice above where I declared a couple of column ids and I called them col-alpha and col-beta. Why not just call them col-left and col-right? Think of future edits, always. Next year you may need to redesign your site and move that left column to the right. You shouldnt have to rename the element in your HTML and rename the id in your style sheet just to change its position. Sure, you could just reposition that left column to the right and keep the id as #col-left, but how confusing is that? If the id says left, one should expect that it will always be on the left. This doesnt leave you much room to move things around later on. One of the major advantages of CSS is the ability to separate styles from content. You can totally redesign your site by just modifying the CSS without ever touching the HTML. So dont muck up your CSS by using limiting names. Use more versatile naming conventions and stay consistent. Leave position or style specific words out of your styles and ids. A class of .link-blue will either make more work for you, or make your style sheet really messy when your client later asks you to change those blue links to orange. Name your elements based on what they are, not what they look like. For example, .comment-blue is much less versatile than .comment-beta, and .post-largefont is more limiting than .post-title.

5. Hyphens Instead of Underscores


Older browsers like to get glitchy with underscores in CSS, or dont support them at all. For better backward compatibility, get into the habit of using hyphens instead. Use #col-alpha rather than #col_alpha.

6. Dont Repeat Yourself


Re-use attributes whenever possible by grouping elements instead of declaring the styles again. If your h1 and h2 elements both use the same font size, color and margins, group them using a comma. This:

You should also make use of shortcuts whenever possible. Always be on the lookout for opportunities to group elements and use declaration shortcuts. You can accomplish all of this:

with only this:

Its very important that you understand the order in which CSS interprets these shortcuts: top, right, bottom, left. A big clockwise circle, starting at noon. Also, if your top and bottom, or left and right attributes are the same, you only need to use two:

This sets the top and bottom margins to 1em, and the left and right margins to 0.

7. Optimize for Lightweight Style Sheets


Using the above tips, you can really cut down the size of your style sheets. Smaller loads faster, and smaller is easier to maintain and update. Cut out what you dont need and consolidate wherever possible by grouping. Use caution when using canned CSS frameworks as well. Youre likely to inherit lots of bulk that wont be used. Another quick tip for slim CSS: you dont need to specify a unit of measure when using zero. If a margin is set to 0, you dont need to say 0px or 0em. Zero is zero regardless of the unit of measure, and CSS understands this.

8. Write Your Base for Gecko, Then Tweak for Webkit and IE
Save yourself troubleshooting headaches and write CSS first for Gecko browsers (Firefox, Mozilla, Netscape, Flock, Camino). If your CSS works properly with Gecko, its much more likely to be problem free in Webkit (Safari, Chrome) and Internet Explorer.

9. Validate
Make use of W3Cs free CSS validator. If youre stuck and your layout isnt doing what you want it to do, the CSS validator will be a big help in pointing out errors.

10. Keep a tidy house


Separate browser-specific CSS to its own individual style sheet, and include as needed with Javascript, server-side code or conditional comments. Use this method to avoid dirty CSS hacks in your main style sheets. This will keep your base CSS clean and manageable.

Written exclusively for WDD by Jeff Couturier Do you follow these methods when coding your websites? What other techniques do you use to create better code?