Max Black's shared items in Google Reader

Monitor Display Sizes » Best Practices HTML and CSS

2010-05-30T04:52:28Z

Shared by Max Black
designsite

Web Design Principles
Monitor Display Sizes

Looking for the lessons? Get started!

Short description of page contents.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Placeholder for pithy quote.

Contents of This Page

Monitors come in sizes (i.e. 17 inches, 21 inches, whatever), but we're more concerned with their display sizes. This tells us how big the actual display of the screen is. The measurement is in PIXELs, which goes along nicely with our use of pixels as units of measurement.

A List of Display Sizes (Desktop Computers)

640x480: The standard monitor size in the mid-1990s. Almost no one designs for a display this small any more.
800x600: According to some surveys, less than 5% of users have monitors this small. But many designers still make their designs to accomodate this size.
1024x768: Currently the "standard" display size. Most designers create their designs with this in mind as their primary size.
1280x1024: Larger than the current "standard" size, but many users view their Web pages in this display size.
1600x1200: A significant number of users have displays this large.
1900x1220: Now we're getting into the high end of display sizes. Most designers don't design for displays this large, unless they're creating "fluid" layouts (see below). If you create a fixed design for a display this large, almost everyone has to horizontally scroll to see your content.
Larger display sizes: "Vanity" displays, big-screen televisions, and so forth.

Note that I didn't get into laptop computers (not too much difference), tablet and notebook computers (often somewhat smaller displays), or mobile devices (very much smaller, and an entirely different subject). These are questions best handled when you get better at Web design.

Layouts: "Fixed" or "Fluid"?

This question pertains to the kind of "layouts" you will use for your pages — a concept we will cover later.

More about layouts.

The simple definitions:

Fixed width layouts: The width is "fixed," or set at a specific number of (usually) pixels. No matter how narrow or how wide the display is, the width of the Web page is the same.
Fluid width layouts: These adjust themselves based on the width of the user's monitor display, and are usually based on ems or percentages.

There are subcategories of fluid layouts, particularly the layout style called "elastic." There are also combinations of layouts called "fixed-fluid." We won't go into that here.

Which one is better? Neither one is "better." The question is, which choice — fixed or fluid — suit the needs of your users, and which personally appeals to you as a designer. Only you can answer these questions.

Accessibility » Best Practices HTML and CSS

2010-05-30T04:52:10Z

Shared by Max Black
designsite

Web Design Principles
Accessibility

Looking for the lessons? Get started!

What "accessibility" is, and why your Web sites should be accessible

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Accessible Web sites provide the maximum potential audience by allowing any Web user to access a site. — Web Design Group

Web specialist Craig Grannell says it better than I can about Web accessibility

Designers (and clients paying for their time) aren't the only ones to benefit from CSS. Visitors will, too, in terms of faster download times, but also with regard to accessibility. For instance, people with poor vision often use screen readers to surf the Web. If a site's layout is composed of complex nested tables, it might visually make sense; however, the underlying structure may not be logical. View the source of a document and look at the order of the content. A screen reader reads from the top to the bottom of the code and doesn't care what the page looks like in a visual web browser. Therefore, if the code compromises the logical order of the content (as complex tables often do), the site is compromised for all those using screen readers. Accessibility is now very important in the field of web design. Legislation is regularly passed to strongly encourage designers to make sites accessible for web users with disabilities. It's likely that this trend will continue, encompassing just about everything except personal web pages. (However, even personal websites shouldn’t be inaccessible.)

... more coming ...

The 'Design' of Web Design » Best Practices HTML and CSS Lessons

2010-05-30T04:50:10Z

Shared by Max Black
designsite

Web Design Principles
The 'Design' of Web Design

Looking for the lessons? Get started!

A flying look at the idea of "design" in Web design.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

The Design of Web Design

Web design is the creation of digital environments that facilitate and encourage human activity; reflect or adapt to individual voices and content; and change gracefully over time while always retaining their identity. — Jeffrey Zeldman

The function of design is letting design function. — Micha Commeren

Contents of This Page

This site does not teach design principles in and of themselves. This site will teach you the nuts and bolts of creating Web pages, but it will not teach you how to design them in any artistic sense. Articles by Francisco Inchauste, Andy Rutledge, and Von Glitschka, among many others, address the topic of design vs. tool — art vs. craft, if you will.

Design began like any craft: people practiced it, studied it and challenged themselves. While modern design tools and resources certainly make our many tasks easier, they don’t always improve our work. Tools and shortcuts are temporary. Great design is timeless. The best tool available is sitting in our heads; we just need to upgrade it once in a while. — Francisco Inchauste

If the entire idea of "designing for the Web" leaves you drawing a blank, read Rutledge's article for a good introduction to the concepts underlying basic design. His example of transforming the "About copy" and "Registration copy" of the product "Optimizr" from static, undifferentiated text to a graphically driven, highly structured and reorganized is one of several excellent visual examples of how design drives and enhances function and form. Also, you might take his design test to assess your knowledge of, and responses to, the fundamentals of design. (You can't cheat, because Andy didn't give an answer key!) In fact, just explore the various design and design-related articles on Rutledge's site. He is not the be-all end-all of Web design, and his political views are far from my own, but his work, acerbic and opinionated as it is, is an excellent starting point for those who want to transcend HTML and CSS nuts and bolts.

Designing for the Web, as I see it, is a multi-layered process. It's a process in which each layer addresses specific design needs related to client aims, brand characteristics and site user habits and expectations. Sadly, the last of these layers to be applied in the process, the application of style, is an oft-maligned element of design. Style for its own sake or by itself is not design, certainly, but stylistic concerns are important to successful design. — Andy Rutledge

Web Standards

One area of Web design I have bought into, in large part because of my connection to SitePoint but also because of personal inclination, is the notion that web standards are important.

When you think about it, most browsers are incredibly forgiving of errors. Even if you code in strict HTML (or XHTML), the browsers will put up with a lot of "guff" from designers — badly written code, improper implementations, a certain amount of misspellings, chaotic structure, and many other errors and poor practices, and still make a manful effort to display a Web page in some sort of decent presentation.

A lot of designers — including some very skilled ones both amateur and professional — figure that if a browser will display something written a particular way, it's okay to code it that way even if it violates all notions of Web standards. They'll tell you that if it works, if it's easier, then they have no problem coding with non-standard techniques, and Web standards — and validation — is not particularly relevant.

More about validation.

They have some reasonable arguments, but I don't entirely buy them. There are a number of reasons why I advocate designing to standards (as much as humanly possible). Many of those arguments are detailed in the Validation page linked above.

Designer Craig Cook gives his definition of Web standards:

[W]eb standards are the functional specifications for the core languages the web is built on. They define how user-agents should handle and interpret these languages, and how web authors should write them.

Like most designers, Cook bases his standards on those hewn out by the W3C, which has, since the inception of the World Wide Web, given us a set of guidelines and best practices that help us build sites that display well in all modern browsers.

Cook continues:

For one computer to understand another, they need to speak the same language and follow the same rules. So you can think of web standards as the rules of grammar that make web languages understandable. Assuming that web browsers are programmed according to the specifications, we need to speak a language the browsers can understand to get our message across. By the same token, a browser manufacturer who wants their software to operate correctly needs to build it so it correctly interprets the language as it is written.

Most — not all — browsers interpret standards-compliant Web designs in virtually the same way. A design that looks one way in Firefox, for example, will display (almost) identically in Opera, or Camino, or (mostly) Internet Explorer. This was not always the case. However, now is not the time to re-examine the Great Browser Wars of the late 1990s and early 2000s. Suffice it to say that with the occasionally maddening exception of Internet Explorer versions 6 and 7 (and sometimes 8), and rare quirkiness from the other modern browsers out there, browsers implement CSS fairly thoroughly, and that in turn enables us to construct elegant, beautifully designed Web pages that look almost the same from one browser to the next.

Chris Mills, a developer for Opera, writes a brief synopsis of where Web design was before standards were widely implemented. It's an excellent reminder of where we were then, and how much progress has been made up through now.

In the old days, people used to do things like laying out their web sites inside giant tables, using the different table cells to position their graphics, text etc (not what tables were intended for, adds superfluous markup to the page). They used to use invisible images called spacer GIFs to fine tune positioning of page elements (not what images are intended for, add superfluous markup and images to the page). They used to write JavaScript that generated menus etc on the fly (no good for people with JavaScript disabled in their browsers, or people with visual impairments using screenreaders, which get confused by such JavaScript) or worked on only one browser (what about people using other browsers?). They used to insert styling information directly into the HTML using <font> elements (terrible for maintenance, and adds superfluous markup to the page). And many other crimes against web development. The worst thing is that I say "in the old days" above, but the fact is that a lot of people are still doing things like this!

Web development is a messy skill at the best of times, but bad practices like these just make it harder. Using web standards and best practices, as outlined in this course, is the best way to go.

The Three Layers of a Web Site

Like the cakes your mom might bake (not mine, she despised baking), Web sites are made up of three layers. (This part of the page owes a great deal to Cook's lucid descriptions.)

Content — HTML or XHTML
Presentation — CSS
Behavior — JavaScript or another client-side scripting language

The HTML content layer tells the browser how to denote the different parts of the document, and what each part means. This provides the basic structure for a Web page, and can be considered the "bottom layer."

The CSS presentation layer tells the browser how to visually display the Web page. It is the "second layer" of the site, controlling the appearance of the site but leaving the structure intact.

The JavaScript behavior layer tells the browser what to do when certain "events" occur, letting both the user and the designer manipulate some parts of the Web page to allow enhanced functionality and interactivity.

Cook sums up the integrated functionality of the three layers:

These are different languages performing different tasks. When these facets of the page are all mixed together, the language becomes muddy and difficult to understand. But if we separate the layers, we end up with three distinct-yet-connected beings, each of which can be modified and maintained without interfering with the others. Each layer then becomes lighter and stronger.

Note: Cook provides a clear distinction between the terms "document" and "page," a distinction I had not considered before reading his article. He writes that a document is "[t]he plain text file containing the content and markup which is served to the browser," while a page consists of "[t]he content (text, images, objects) when rendered by a browser." To differentiate: "a page is what you see, but the document is what you build." Excellent distinction, and one I intend to follow through the course of this site, even if I have to reverse-engineer some of the already-written pages.

Focus on Content

Michael Seidel, a usability and content management expert, writes of the need to focus on content first and foremost in your designs. Content is indeed "the seed of the design process," he writes, but the structuring and formatting of content is itself an integral part of visual design. Seidel writes:

You can strategize until you're blue in the face about what your content should be and how it will be created and maintained. But ignore how it will be presented and your content will flounder once it leaves your cozy den of theory and hits the real world.

Seidel writes that he is talking about "simple formatting":

Strong headings,
Bullet points,
Short sentences, and
Scannable paragraphs

Seidel writes that no matter how obvious these elements may seem in their necessity for creating usable designs, designers forget it over and over again. He bemoans the prevalence of "impossibly cluttered and kludgy design" even on today's Web.

Seidel writes:

Your readers need content they can kiss. Don't make it a complicated kind of love. Break things down to their core. Written content with a strong visual hierarchy helps simplify the creation process. It helps designers build clean, purposeful interfaces.

These things matter.

Never forget.

Formatting may seem like minutia, but it's not. Make sure that content design is a key part of your content strategy equation. Fretting over style will pay off in crazy amounts in the long run.

The Joy of Cooking

Designer and content strategist Nicole Jones serves us a useful metaphor: design is like cooking a meal.

Before you begin cooking, Jones writes, a chef does some planning. Who are the guests? What do they like and dislike? How are they feeling — what is their mindset? What are they coming to eat? (Patrons visiting a restaurant specializing in local seafood would be surprised to be told that the evening's special is meatloaf.) What is available at that time of year?

A good designer asks similar questions. Who is the site for? What do the likely users prefer, and what do they avoid? How are they likely to approach the site? What do they expect to be able to do upon clicking into the site? What can the designer provide, and what is beyond his capabilities or inclinations?

Building on her metaphor, Jones continues:

A great chef is an accomplished editor; the entire experience matters. The menu is consistently good from start to finish, without overt techniques or an overwhelming amount of ingredients. The chef disappears. The food is not intimidating, precious, or minimal. ... After all, a delicious meal is not a masterpiece. It's sweet and savory, and intended to be eaten.

She concludes that designers "ask questions, cook with the diner in mind, and use [their] tools responsibly."

Further Reading

Jeffrey Zeldman, the dean of Web design, gives us a wake-up call about the misconceptions that make up most people's perceptions of the concepts behind Web design.

It's hard to understand web design when you don't understand the web. And it's hard to understand the web when those who are paid to explain it either don't get it themselves, or are obliged for commercial reasons to suppress some of what they know, emphasizing the Barnumesque over the brilliant. — Jeffrey Zeldman

Steven Bradley has given us a Design Hierarchy of Needs, ranking five fundamentals of design from the most basic need of functionality — the site must function properly — through reliability, usability, proficiency, and finally creativity as necessary elements of any Web site's design. A recommended read.

David Rodriguez attempts to find the middle ground in (business-oriented) Web design between unbridled creativity and bland, generic "corporatism."

A much more narrowly focused article from Sam Dunn focuses on several excellent methods for strengthening the visual appeal of your site.

CSS Zen Garden is one of the best places on the Internet to begin looking over Web designs. Anyone can submit a site (re)design; the HTML remains exactly the same for every version of the site, but the CSS is dramatically different from one submission to the next. One person's version might be militaristic and sharp-edged, while another might take you into a bright blue oceanscape. A seminal showcase of the infinite variety of aesthetic, concept, and function that can be produced for the Web.

More reading and content will be added periodically.

The evolution of a website can equally be put down to a mixture of nature (what the coder puts into the site) and nurture (what the end-user adds with growth), both of which have significant importance and shouldn't be ignored. — Alex Dawson

Keep in mind that a user is simply a human being, an average Joe, a passerby on the street who might be a web-savvy tech-support guru, or an elderly lady who's only just started using a computer. People use web sites, so it's a handy term, but just try to keep in mind that we're talking about regular humans, rather than some kind of machine-operating robot. — Elliot Jay Stocks

Simplicity is the ultimate sophistication. — Leonardo Da Vinci

Commenting in CSS » Best Practices HTML and CSS

2010-05-30T04:49:39Z

Shared by Max Black
designsite

Web Design Principles
Commenting in CSS

Looking for the lessons? Get started!

Short description of page contents.

Principles Links

The entire Web Design Principles section can be accessed through the menu below.

Principles Menu

Placeholder for pithy quote.

Commenting in your stylesheet follows a different format, but the same idea, as commenting in your HTML page. Here's how you leave yourself a comment in your stylesheet:

/*here's my comment*/

The /* */ is the key to setting the comments apart and keeping the browser from trying, and failing, to interpret them as CSS elements.

Me, I like to set them off a bit more: /*** ***/. That's okay, just be careful not to overdo it. You can do this if you really want:

/******************
******************
******************
Lots of blither about me!
My code is wonderful! Here's my contact info.
Here's information about my cats.
More pointless gibberish that slows loading time.
Wheeeee!
******************
******************
******************/

but why do you want to?

Just a reminder, make sure the /* */ begin and end the comment.

Color » Best Practices HTML and CSS

2010-05-30T04:48:44Z

Shared by Max Black
designsite

Web Design Principles
Color

Looking for the lessons? Get started!

A brief examination of color in Web design.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Placeholder for pithy quote.

Contents of This Page

We've already seen that we prefer to use hex codes instead of the names of colors for our CSS. If you use hex codes, you have tens of thousands of choices of colors. If you use names, you have a grand total of 16: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow.

The 16 Named Colors:

black	gray	silver	white
yellow	lime	aqua	fuchsia
red	green	blue	purple
maroon	olive	navy	teal

(Chart adapted from Tizag.com.)

I don't know about you, but I want more than 16 color choices!

There are two general ways to add color to your site through your stylesheet: color for fonts, and background-color for elements such as headers, paragraphs, lists, blockquotes, and other items.

Here's an example:

h1 {
   color: #ffcccc;
   background-color: #000099;
}

Now let's break it down.

Your <h1> font is displayed with the color #ffcccc. The background of that <h1> element is #000099.

There is one other way to indicate color, RGB. We won't learn that here, except as it's quoted in the reference below.

You can also use "shorthand" for certain hex codes, but I won't get into that here.

This is a quote from HTML Dog:

red
Is the same as
rgb(255,0,0)
Which is the same as
rgb(100%,0%,0%)
Which is the same as
#ff0000
Which is the same as
#f00

Almost poetic, isn't it? Web design haiku.

Hex Values

We were just looking at hex values for colors. You're going to end up using them, like it or not. Understanding them completely is, at least for me, not entirely necessary. I crib from charts such as this one, which we've used in the lessons, or color scheme generators such as Adobe's Kuler, and don't worry too much about it. But that's not a good enough place to leave it. Let's explore the wonderfully confusing world of hex values for just a moment.

Hex, or hexadecimal, values, make up the standard for color representation in Web pages. A hex value is a 6 digit representation of a color. The first two digits (RR) represent a red value, the next two are a green value (GG), and the last are the blue value (BB).

In other words, the six-digit code is actually three pairs of code. That's important. We'll see why later.

Hexadecimal Color Values:

Decimal	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Hexadecimal	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F

(Chart again adapted from Tizag.com. Thanks, folks.)

Note that instead of using double-digit numeric values, hex codes use 0-9 and then A-F.

0 is the minimum (actually, nil) amount of a color in a hex value. F is the maximum amount. Hence, #000000 — no color — is black, and #ffffff — full values for red, green, and blue — is white.

Want more? That gets you into color theory, which I won't get into here.

Hex Shortcuts

Pssst! You can use shortcuts in writing your hex codes. Well, sometimes.

Remember I told you that hex codes come in three sets of pairs? That's the basis for hex shortcuts.

If a pair of color values — say, 00 or aa — is the same, you can get away with using it only once in your stylesheet.

Therefore, you can use three digits in your code instead of six. Saves a little wear and tear on your long-suffering fingers. Here's a couple of examples:

color=#000000;

becomes

color=#000;

We didn't just trim three 0s off the end, we trimmed one off of each pair of zeroes:

00 00 00

One more:

color=#bb7733;

becomes

color=#b73;

We trimmed the second of each pair:

bb 77 33

RGB Values

Honestly, I almost never use RGB values in my coding, mostly because I can't keep them straight, but also because some old non-Internet Explorer browsers don't recognize them. (With the advent of rgba values being used in CSS3, I am going to have to learn.) In the meantime, here's a quick rundown.

RGB stands for Red, Green, Blue. Every color has a value of 0 (no color) to 255 (full color). The format in your stylesheet for using white in RGB value is:

background-color="rgb(255,255,255)";

216 "Web-Safe" Colors

Older Web tutorials advised folks to only use a group of 216 "web-safe" colors. These are "paired" hex code values such as #cc0033 or #22ffdd. The reason for this is that, in older browsers and monitors, they were the only colors that could be "guaranteed" to display the same from one computer to the next. However, with more modern browsers and monitor displays, almost no one follows this any longer. You can find color charts of web-safe colors hanging around the Internet, but I wouldn't worry about it.

Units of Measuring Size » Best Practices HTML and CSS

2010-05-30T04:47:45Z

Shared by Max Black
designsite

Web Design Principles
Units of Measuring Size

Looking for the lessons? Get started!

Short description of page contents.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Placeholder for pithy quote.

Contents of This Page

Units of measurement directly impact your "layouts," which we will cover in a later portion of these lessons.

Unfortunately, it's somewhat confusing. So pull your pants up and let's roll!

There are three units of size (width and length, basically) that you use in determining the size of your Web page, and the size of the various elements (most often fonts, but other elements also):

pixels (px)
ems (em)
percentages (%)

Pixel: Pixels are the tiny dots that make up the display on a computer screen. Everything that shows up on a computer screen is displayed in pixels. It's fairly standard from one computer to another, so it's pretty close to an absolute size. A typical font size is 16px. Pixels have their drawbacks: Internet Explorer users can't resize text set in pixels, which may frustrate the ones with vision problems, and sometimes trying to print a Web page set in pixels can cause problems. (IE7 and IE8 users can use "page zoom" to resize their entire page, as can Opera users. Doesn't solve the problem, but gets around it somewhat.)

Em: Ems are a relative size, which means they change depending on the size of the elements they are "related" to. It is generally related to the font size. So the size 2em is twice the size of the current font size. Using ems is considered best practice by many designers. However, there is a drawback: Internet Explorer 6 sometimes renders fonts set in ems as considerably larger (or smaller) than other browsers. Since I hate IE6 and wish it were dead, I wouldn't recommend that you not use ems to serve IE6's orneriness (and I am very aware that many users have to use IE6 in their workplaces, or are just not knowledgeable enough to know they have other options). Overall, while there are issues surrounding the use of ems, they tend to work the best in Web pages. Nothing is perfect....

Percentages:This is an even more relative unit of measurement. You might have a font as 80% of the main font size.

There are other ways to measure the size of elements, including points, picas, centimeters, millimeters, and others, but we stick with pixels, ems, and percentages virtually all of the time. (Points were introduced from the world of printing, and don't translate well into Web work. The others are even worse for Web design.)

A measurement value of zero (0) doesn't need a unit of measurement.

This is correct:

border: 0;

This is not correct:

border: 0px;

Going With the Flow

Remember, you cannot make a visitor to your site view your site exactly the same as everyone else, no matter how much you may want to. The phrase "go with the flow" has more than a philosophical or slang meaning for Web designers — you literally have to go with the flow of the browser and the computer display.

Ian Lloyd gives us an excellent primer on when to use pixels, ems, and percentages. I'm taking the liberty of including a rather long quote from his book. It's just that good.

Which method of measurement should you use for your padding: pixels, ems, or percentages? If each of the examples above creates the same effect on the web page, what difference does your choice make? The answer is: it depends on how you want your design to behave. If you intend your design to change with the browser window, then percentages is the way to go. Any value that's set using percentages will change as the size of the browser window changes: the bigger the browser window, the bigger your padding will become. If you want your design to scale well with different font sizes, then you should use ems, because the measurements will be based on how your users set the font size in their browsers. If users increase their browsers' font sizes, then sizes set in ems will also increase accordingly. If you're after a precise design with graphical elements that line up exactly, regardless of browser window size or font setting, then setting sizes in pixels is the most predictable method of all. A pixel will nearly always represent a single dot on the user's screen. Why nearly? Because most browsers now offer a page zoom facility which will magnify everything in proportion, over which you have little control.

Page Layouts » Best Practices HTML and CSS

2010-05-30T04:47:06Z

Shared by Max Black
designsite

Web Design Principles
Page Layouts

Looking for the lessons? Get started!

Some of the fundamental principles behind the page layout.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

The experienced web designer, like the talented newspaper art director, accepts that many projects she works on will have headers and columns and footers. Her job is not to whine about emerging commonalities but to use them to create pages that are distinctive, natural, brand-appropriate, subtly memorable, and quietly but unmistakably engaging. If she achieves all that and sweats the details, her work will be beautiful. If not everyone appreciates this beauty — if not everyone understands web design — then let us not cry for web design, but for those who cannot see. — Jeffrey Zeldman

Contents of This Page

There are a blue million ways to lay out a Web site, from extremely simple to incredibly complex. If you search Google with the terms "CSS layout," you'll see what I mean. But before we go forward, let's take a look at what designers used to do in the wild, wooly, and semantically inaccurate days of yore.

Abandoning Table-Driven Layouts

When I began fiddling about with Web design in 1998 (strictly as a hobby — I've only begun to get serious about Web design since around 2008), every page layout that wasn't simply "stacked content" (a single full-page column with one element "stacked" one on top of the other like pancakes) was designed with tables.

Tables are wonderful things, for presenting tabular data. But early on in the game (pre-CSS), designers discovered that with some ingenuity, they could use tables to lay out their pages. It's only been since 2007 or thereabouts that something of a consensus has been reached: CSS-driven (tableless) layouts are best practices, and using tables to create page layouts is just flat wrong.

In 2005, when the debate between CSS and table-driven layouts was raging, Web designer Jon Henshaw explained:

Tables were never intended by the creators of HTML to control the visual style of a web page. They were only meant to display data with columns and rows. There wasn't a mechanism in place to address the needs of more advanced layouts, so some ingenious web designers discovered that they could use tables to implement robust layouts. Since that time, web designers have been regularly misusing the HTML language, mainly out of necessity.

In 2008, the tutorial site Learn Web Design Online wrote:

Now in 2008, the debate is more of historical interest, since it is clear that the web industry had gone in the direction of CSS-based tableless design. This is evidenced in the past years by many major websites doing an entire sitewide redesign to recode their table-based layouts to tableless layouts. If you pick up HTML/CSS books that are published in 2007 and 2008, you will find that it is CSS-based tableless design is what they will teach you.

The same site, in a page titled Benefits of using CSS based Tableless Layouts, gives a number of reasons why CSS-driven layouts are superior to obsolete table-based layouts. Three years before, Henshaw made many of the same observations; Web designer Cameron Olthius wrote on the same topic in 2006. To sum up their arguments, CSS-driven layouts are standards-driven; cleaner; far easier to maintain; more accessible to disabled users; easier for search engines to catalog; perform better; give a multitude of opportunities for creative expression; and are semantically more accurate.

On their side of the argument, advocates for table-driven layouts contend that tables are much more intuitive and easier to understand than CSS layouts; CSS layouts are subject to a number of "bugs" that tables don't fall prey to; and have some advantages, such as equal heights for columns, that CSS layouts do not have without "hacks" or workarounds.

Henshaw concluded in 2005:

The main argument for still using tables today stems from bad habits, and complacency. What is often said is that using tables is easier, and that browsers don't support it. It can certainly be easier in some cases, but browsers do support it. Internet Explorer can be frustrating to design for, because it doesn't adhere to web standards very well, but there are many fixes and workarounds that will enable CSS based layouts to render correctly. If there was ever a time to start designing tableless layouts, it's now.

Henshaw wrote his article months before Internet Explorer 7 came out. With all of that browser's flaws and quirks, it supports CSS-driven layouts much, much better than its persnickety predecessor, IE6.

More bluntly, Olthius wrote:

It's my belief that if you're a professional web designer (in other words, you exchange money for your services) then you should be building sites strictly with CSS.

In my view, Olthius is spot on. I can't imagine anyone, professional or amateur, who claims to adhere to anything approaching modern design practices advocating anything except tableless, CSS-driven layout design.

So why spend so much time and bandwidth on the subject? Because the subject is still being debated, and Web designers who ought to know better have stubbornly continued to advocate for table-driven Web design. You will run into knowledgeable people who strongly advocate tables for Web layouts. I appreciate their determination and their passion, but they are simply wrong. If you intend to design according to best practices, then you design using CSS to handle your layouts.

In the interest of completeness, I should mention an effort, led by some of the best minds at SitePoint and other design organizations, to use "CSS tables" to create layouts. SitePoint founder Kevin Yank wrote about this in 2008, and SitePoint published a controversial book, Everything You Know About CSS Is Wrong! co-authored by Yank and Web design guru Rachel Andrew, strongly advocating for the use of CSS tables for laying out pages. Unfortunately, since IE7 and earlier iterations of that browser do not support CSS tables whatsoever, it is impossible to use such techniques to design pages for anything approaching a general audience. IE6 has been around since 2001, and almost all designers must create their pages with that browser in mind. Who knows how long it will take for IE7 to run its course and disappear? Until then, learning how to code with CSS tables is little more than an academic exercise. (In light of the new layout techniques that will, we are told, be included in CSS3 when it is released and when browsers begin supporting it, we may never use CSS tables to create layouts.)

... more coming ...

Positioning Elements » Best Practices HTML and CSS

2010-05-30T04:46:42Z

Shared by Max Black
designsite

Web Design Principles
Positioning Elements

Looking for the lessons? Get started!

Positioning elements for page layouts.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Position is nine-tenths of the law. — Maggie Tuck

Contents of This Page

Positioning elements in an HTML page is usually done through the CSS stylesheet. There is some argument over how semantically correct this is, since CSS is supposed to be about a page's style and appearance, and HTML is about content and structure, but I'm not going to rehash that argument here. Suffice it to say that when you consider the issue, it's plain (to me) that CSS is the right venue to handle positioning. You are free to disagree.

The key to understanding positioning is understanding the box model of Web design layout. We touched on the concept in another page:

More about block and inline elements.

If you haven't read the page above, you might go back and look it over before moving forward on this page.

Much of the information on this page comes from two excellent books by Ian Lloyd and Craig Grannell, and from several well-regarded Internet sources: Tommy Olsson, Mike Hall, Steven Bradley, and BarelyFitz Designs. As always, the sources contain far more information that I have included here. You should definitely check them out on your own.

Steven Bradley notes:

When people are new to CSS layouts there’s a tendency to gravitate toward positioning. Positioning seems like an easy concept to grasp. On the surface you specify exactly where you want a block to be located and there it sits. Positioning is a little more complicated than it first appears though. There are a few things that can trip up a newbie and a few things to understand before positioning becomes second nature. You can do some great things with positioning, once you develop a deeper understanding of how it works.

Maybe a bit obvious and even trite, but it's true, and therefore worth quoting.

The Box Model

There are a ton of illustrative images on the Net, but I was lucky enough to secure permission to use this one from the owner, Craig Cook. (Craig's excellent ruminations and lessons on Web design are found in this and other pages of this site as well. He even sent me a better version of the graphic than the one appearing on his site, one I've provided here.)

Oooh, it's all three-dimensional and stuff....

But what does it really mean? Here's Cook to explain it all:

Working from the outside in and back to front, we have an invisible margin area between the edge of this element and its adjacent elements. Inside the margin, we can apply a background color, and a background image will overlay that. Padding is invisible space between the edge of the box and its contents, and the background will show through the padding area. Overlaying all this is a border, outlining the visible edge of the element.

Steven Bradley gives us the following information:

width of containing block (box) = margin-left + border-left-width + padding-left + width + padding-right + border-right-width + margin-right

height of containing block (box) = margin-top + border-top-width + padding-top + height + padding-bottom + border-bottom-width + margin-bottom

More about margins and padding.

More about borders.

And Mike Hall gives us some more clarification:

Margins, borders and padding are all optional but for purposes of calculating positions and sizes they are given a default width of zero if not specified. Different widths can be set for each individual side (top, right, bottom and left) if desired. Margins can even have negative values. The width and height of each box is equal to the width and height of the outer margin box. Note that this is not the necessarily the same as the width and height of the content area. A box can contain any number of other boxes, creating a hierarchy of boxes that corresponds to the nesting of page elements. The browser window serves as the root element for this hierarchy.

Basically, every element in your stylesheet is, in your HTML page, surrounded by a box. The dimensions are set depending on the content and the characteristics of the element. We can use the width and height properties in our CSS markup to define the box boundaries in specific manners.

There are two main types of boxes, block and inline.

More about block and inline elements.

Bradley writes:

Block level boxes are laid out vertically one after the other. If you have two block level boxes next to each other in your html, the second will sit below the first. Inline boxes on the other hand are laid out horizontally. An inline box will always sit to the right of the box that precedes it, assuming there's enough room in the containing element. Inline boxes will wrap though. They will start to the right of the previous box and fill whatever horizontal space is remaining. They will then wrap to the next line and again move to fill the horizontal space. A block level box would automatically drop to the next line before filling any space.

You might read Bradley's excellent examination of the box model — the source of the above quote — for more information.

We can use margins and padding to set the width and height of our "box" elements, and we can use borders, background colors, and background images to add visual interest (in technical terms, "spiff it up"). The background colors or images we use will show behind the padding and borders, but not the margins.

How do we know the dimensions of a particular box? We can best see that in an example.

Let's say we have a div element that is defined as 100 pixels wide:

.example {
   width: 100px;
}

We can add 10 pixels of padding to the box if we like, and even a 5px border:

.example {
   width: 100px;
   padding: 10px;
   border: 5px solid black;
}

The total width of the .example element is 130 pixels. Howzat? Simple math.

5px + 10px + 100px + 10px + 5px = 130px

The borders on each side (left and right) are 5px apiece. The padding on each side is 10px apiece. The central element is 100px. Total that on your calculator or in your head and you get 130px.

Why is that important? Well, if you use a background image that is 115px wide, you'll see quickly enough that the dimensions of the .example element have 15px that aren't filled by the image. That won't look right.

Collapsing Margins

Sometimes, margins between two box elements "collapse," resulting in the larger of the two margins being used and the other one "collapsing" to a de facto value of zero. Very uncool.

I'm not going to go into this little problem, but I'll give you a link to an excellent reference article by Tommy Olsson and Paul O'Brien that will tell you what you need to know, including how to keep it from happening.

The Basics of Positioning

There are four types of positioning in CSS:

static;
relative;
absolute; and
fixed

Or in CSS code terms:

position: static;

position: relative;

position: absolute;

position: fixed;

That's all well and good, but what do the terms mean? And just as importantly, what do they do, and how can I use them effectively in my designs?

Well, the terms are confusing. As my friend Tommy Olsson writes:

Most of us probably regard this matter from a layout point of view, from which the names seem quite odd. A static element isn't static at all, it moves around as we scroll the page. A relatively positioned element is only relative to itself. An absolutely positioned element is not absolute, but relative to some other element. And a fixed element is both absolute and static.

But the W3C didn't assign these names from a layout perspective. The folks in that group assigned these names from a "document" perspective.

More about documents and tags.

Within the HTML document, a static element is "static" — unmoving — within the document flow. A relatively positioned element is "relative" — to itself. An absolutely positioned element is indeed positioned "absolutely" within its container and removed from the document flow. And a fixed element is "fixed" with respect to the document flow.

By helping you understand the different kinds of positioning, I can help you make informed and proper decisions as to when to use static, relative, absolute, and fixed positioning in your designs.

So let's figure them out. But we won't start by defining the four positioning states, not just yet.

Setting the Position Property

CSS gives us the position property as shown above. It also gives us the inherit value:

position: inherit;

Descendant elements — those coming below the positioning rule or selector in the stylesheet — do not inherit that positioning, but position: inherit forces inheritance.

More about CSS selectors, properties, and values.

More about inheritance.

Any HTML element can be positioned, including all block and inline elements.

More about block and inline.

Position properties can also be modified with the following properties:

top
right
bottom
left

Static Positioning

The static positioning value is the "default" value for every HTML element. If you don't give an element a different positioning value, it will be positioned as a static element. You won't use position: static very often, except to undo an earlier positioning rule. A (bad) example:

body {
   position: absolute;
}

#footer {
   position: static;
}

As unlikely (and insane!) as it would be to position everything in your body as absolute, this example serves a purpose: to show you how you would make your #footer revert to the default static status.

Statically positioned elements appear in your displayed page based on whatever statically positioned content appeared before them. Modified by margins and padding, the elements still stay in place with respect to the other content. If you don't change anything's positioning, you often end up with a single "stack" of static content, like a big stack of flapjacks, posed one on top of the other in a big, boring vertical column.

Okay, maybe less boring and a bit tempting....

Relative Positioning

Like most things worth doing, relative positioning takes some thought and effort to grasp properly. Relatively positioned elements are positioned in relation to itself. Say what?

Okay, we'll let Tommy explain it, in what he calls "layman's terms."

The box generated by the element is laid out just as it is for static elements. Then the rendered box is shifted horizontally and/or vertically, according to the values of the top, right, bottom, and left properties. But here's the tricky part — as far as the rest of the document is concerned, the box is still in its original place! It is laid out where it should be, and it will occupy that position in the document flow. It's only the rendered box that is shifted, relative to that original position. If we move it a large distance, we will leave a hole in the document.

Since this is the case (and it is, as counter-intuitive or just plain confusing as it may seem), we can't use position: relative for columnar layouts. And if used in its simplest form, it will merely move elements around a few pixels. So, useless, right? Not at all. It has a side effect that clever Web designers have long used to their advantage.

Remember those top, right, bottom, and left properties? These "push" the selected element (think boxes, remember) out of its original, static position. How so?

Setting a relatively positioned element 20 pixels from the top:

#element {
   position: relative;
   top: 20px;
}

moves the "box" 20 pixels down from where it would have been had we not futzed with the positioning.

(Since we can use negative values, we could achieve the same effect with this:

#element {
   position: relative;
   bottom: -20px;
}

although we don't usually do it this way — it's just needlessly complex more often than not.

Top and bottom positioning cancel each other out, as do left and right positioning. They don't work together. However, top and left, top and right, bottom and left, or bottom and right, work beautifully together.

This code:

#element {
   position: relative;
   top: 20px;
   left: 60px;
}

positions the specified element 20 pixels from the top and 60 pixels from the left (or 20 pixels towards the bottom and 60 pixels to the right, if you prefer).

Absolute Positioning

Tommy Olsson writes:

An element with position:absolute is removed from the document flow, which means the rest of the document acts as if the element weren't there. It won't affect subsequent elements. Instead, it could end up layered over other elements, unless we make sure it doesn't.

This is a key to remembering the uses, and pitfalls, of absolutely positioned elements. Many, many Web designers, including sophisticated professionals, routinely rely on absolute positioning for, well, darn near everything. And many times, it gives them what they want. You can position elements precisely where you want them, with pixel-perfect precision. You can even lay out columns. However, absolute positioning has some major drawbacks.

Any absolutely positioned element is removed from the document flow. The rest of the page ignores the absolutely positioned element and goes about its business presenting its content as if the absolutely positioned element doesn't exist. The absolutely posotioned element can, and so often will, end up sitting on top of another portion of the document, layered over other elements as Tommy writes. There are times when we want this to happen, but more often it isn't the effect we want.

Or even more maddeningly, you get your page positioned perfectly with one or more absolutely positioned elements. Looks great. Then you change the screen resolution, and everything goes to pot. The relative and statically positioned elements adapt to the new resolution, but the absolutely positioned elements ... don't.

Steven Bradley writes:

The key to understanding absolute positioning is understanding where the origin is. If top is set to 20px the question you should be asking is 20px from where.

We can still use the top, right, bottom, and left properties, but in a much different way than they function in a relatively positioned element. The four properties now specify the positions of the four edges of the absolutely positioned "box" element. You can use pixels or ems (or other, less used) units of length to specify the values of these properties. You can even use percentages, but that's complicated — percent values for top and bottom refer to a percentage of the height of the containing block, while for right and left it refers to the width of the containing block.

In fact, the whole idea of absolute positioning is made even more complicated by the concept of the containing block. Hitch up your pantaloons and get ready for a ride....

The Containing Block

The concept of the containing block applies to more than just absolutely positioned elements, but it's a key concept in working with absolute positioning, so we'll tackle it right here. Tommy quotes the CSS 2.1 specification:

If the element has "position: absolute", the containing block is established by the nearest ancestor with a "position" of "absolute", "relative" or "fixed" ... If there is no such ancestor, the containing block is the initial containing block.

What in the heck does that mean? What's my ancestors have to do with anything? Granny, are you controlling my Web page?

Thankfully, Granny isn't involved in this.

The containing block for an absolutely positioned element is its nearest positioned "ancestor" element, say, a #body or a #div that has a position selector attached to it. If none exist, the containing block is, essentially, the html element. Tommy writes, succinctly enough:

In other words, we can assume that if there is no positioned ancestor for an absolutely positioned element, the containing block is the document itself.

Here's a quick example:

<div class="whatever">
   <p>Some content.</p>
</div>

The #whatever div creates a containing block for the paragraph. In its turn, the p element creates a containing block for the text "Some content".

One of the cool effects of the containing block paradigm is that when a relatively positioned element can become the containing block for an absolutely positioned element. In that case, we can exert control over the containing block.

When an "ancestor" element is positioned relatively, we can position an element occurring after that element absolutely. The containing block doesn't move with the position: relative affixed to it, it just allows us to control its "descendant" element's absolute positioning. Now we can use the top, right, bottom, and left properties to adjust the element within the corresponding edge of the containing block. This:

left: 10px;

has the left-hand edge of the absolutely positioned element is located 10 pixels from the left-hand edge of the containing block.

Naturally, Internet Explorer 5 and 6 both choke on this to an extent. Tommy explains:

In a CSS2-compliant browser, we could specify all four properties to give both the position and the dimensions of our absolutely positioned element. Unfortunately, IE5/6 do not support this, so in the real world, we will often need to specify one vertical position (either top or bottom) and one horizontal position (left or right) and then set the width property and, sometimes, the height property. These bugs also apply to values specified as percents. In IE5/6, they do not apply to the dimensions of the containing block, but of the parent block. As we have seen, those can be two very different things. The percentage bugs are also present in Opera, up to and including version 8. They are fixed in Opera 9.

I don't worry too much about bugs in obsolete versions of Opera (and Firefox), because their users tend to update their browsers in a very short time after the release of a new version. Internet Explorer users, on the other hand, are stuck with the version of the browser that came with their copy of Windows unless they buy a new computer, upgrade their operating system, or otherwise obtain an upgraded version.

It's also worth noting that if you have a block element relatively positioned, it establishes itself as a new containing block. Mike Hall writes: " Positioned elements within it will use the 'offset' position of that element as a base for positioning. In other words, the offsets of descendant elements are compounded." If you have an inline element relatively positioned, it does not establish itself as a new containing block, but uses the offsets of its own containing block. Hall again: "If the relatively positioned element is an inline element, its offsets are not combined with the offsets of its positioned descendants. Instead they are based on the same containing block used by the relatively positioned element."

One more thing: you have another value for the top, right, bottom, and left properties, called auto:

left: auto;

This tells the browser to place the absolutely positioned element where it would be placed if it were positioned as a normal, i.e. static, element. This can be very useful.

This is quite confusing; I suggest you follow up by perusing Tommy Olsson's article explaining this in more detail.

Nesting Absolutely Positioned Elements

Ian Lloyd gives us a nifty little example of nesting absolutely positioned elements one inside the other.

If we start with an absolutely positioned block 200 pixels from the top and 200 pixels from the left:

#redblock {
   position: absolute;
   top: 200px;
   left: 200px;
   background-color: red;
   width: 100px;
   height: 100px;
}

you get, well, a small red box 200 pixels down and in.

Here's the HTML code:

<div id="redblock"></div>

(Notice that the div does not contain any content.)

Now, let's say we want a smaller yellow box to appear inside our red box.

We might want to put the yellow box 220 pixels down and 220 pixels in. We would be wrong.

First, we need to place the div containing the #yellowblock ID inside of the div containing the #redblock ID. Like so:

<div id="redblock">
   <div id="yellowblock"></div>
</div>

This means that the #yellowblock div inherits the positioning of its parent element, the #redblock div.

More about inheritance.

Now, to make this work, we create the #yellowblock CSS. We'll place the yellow box 20 pixels down and 20 pixels in from the top left point of the red box, and make it half the width of the red box:

#yellowblock {
   position: absolute;
   top: 20px;
   left: 20px;
   background-color: yellow;
   color: red;
   width: 50px;
   height: 50px;
   padding: 5px;
}

Here's what Ian's nested elements look like.

Nifty, huh? Ian Lloyd has given us a great visual example of how absolutely positioned elements can work in concert with one another.

You might want to play with the code a bit in your own page (or just copy and paste the source code of the example page into a blank HTML file). Try making the #yellowbox width and height 100px. Try changing the positioning. Have some fun with it.

Fixed Positioning

If you have figured out absolute positioning, you pretty much understand fixed positioning. (Mike Hall actually classifies fixed positioning as a variant of absolute positioning.) The biggest difference is that for an element with fixed positioning, the containing block is always the initial containing block — generally, the html element that defines the entire HTML document. The top, right, bottom, and left properties always reference the edges of the browser window, or if you're creating a print stylesheet, the paper.

More about print stylesheets.

Elements with fixed positioning don't move. Period. If you've seen pages with fixed navigation schemes, for example (here's a demo of one from CSS guru Soh Tanaka, and here's the main page for that demo), they use fixed positioning to make it all happen.

Naturally, Internet Explorer 5/6 poses a problem with using position: fixed;. Neither browser recognizes the selector at all. That's why you rarely see designers using this one.

The Z-Index

Whether you're using relative, absolute, or fixed positioning, it's entirely possible that you have "boxes" on top of one another to one extent or the other: overlap. If we want to control which box is on "top" in our display, we can use the z-index property.

(This has no effect on elements positioned statically.)

The z-index property is a numeric value, positive or negative. To understand what it does, we have to think in three dimensions for a moment. (You might jump up to Craig Cook's nifty illustration of the box model for a visual reminder of how this works.)

I'm going to let Tommy explain this again, since his understanding of the property is much deeper than mine:

A computer screen is (currently) two-dimensional. It's a flat area with a width and a height, onto which we can render our CSS boxes. But CSS actually works in three dimensions. The X and Y axes are our normal horizontal and vertical axes, respectively. The Z axis is perpendicular to those two. Think of it as pointing straight into the front of and out the back of the screen. The higher the value of the z-index property, the closer the element is to the user. This is called the stacking level.

Tommy doesn't go into intensive detail about stacking levels and stacking contexts, for which we can be grateful, I suppose. A rule of thumb about this is that you can assign a "stacking level" — the order of the stack in three dimensions — using the z-index property.

I'm going to shamelessly steal Tommy's example to illustrate this effect. Given the following HTML code:

<div id="first">
   <div id="a">...</div>
   <div id="b">...</div>
</div>
<div id="next">
   <div id="c">...</div>
   <div id="d">...<div>
</div>

and the following CSS rules:

#first {
   position: relative;
}

#next {
   position: relative;
}

Both the first and next divs are relatively positioned. Therefore, they are the containing blocks for any absolutely positioned "children," or "descendent" elements.

The inner, "child" divs (a, b, c, and d) are relatively positioned. Now we can influence the stacking order for the four letter divs using the z-index. Like so:

#a {
   z-index: 4;
}

#b {
   z-index: 3;
}

#c {
   z-index: 2;
}

#d {
   z-index: 1;
}

Since the a div has the highest (therefore the highest priority) number, it will appear on "top" in the stack. The d div will be the last, or "bottom" element. The actual numbers used aren't important — you can achieve the same effect by using these values:

#a {
   z-index: 9999;
}

#b {
   z-index: 100
}

#c {
   z-index: 10;
}

#d {
   z-index: 1;
}

Tommy gives some more vital information:

We can also affect the stacking order of first and next, should they overlap, because they live in the same stacking context. But what if we want next or c to slide in between a and b? Now we’re out of luck, because next and c exist in different stacking contexts from a and b, and there is no way that we can insert them between those two. Likewise, we cannot intersperse child elements of b with child elements of a, because a and b establish their own separate stacking contexts. Just as knowledge of the containing block is extremely important for absolute positioning, the stacking context is important when using z-index.

If you use negative numbers in your z-index values, those designated elements will appear behind other elements, whether they bear a positive z-index value or are undesignated. Some designers like to use this to make sure a particular element is always below everything else:

z-index: -9999;

Web designer Louis Lazaris gives us more info on the z-index in an informative Smashing Magazine article, including a look at the use of z-index with JavaScript, implementation problems with IE and Firefox, and an array of varied elements and creations that hinge on the use of the z-index property.

Final Thoughts

Tommy has provided us an excellent example page showing all of the positioning schemes employed in the same document. IE 5/6 users will not see it properly, because those browsers are broken. Mike Hall has also provided some nifty examples.

Classes and IDs » Best Practices HTML and CSS

2010-05-30T04:45:35Z

Shared by Max Black
designsite

Web Design Principles
Classes and IDs

Looking for the lessons? Get started!

Classes and IDs, the similarities and differences.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Placeholder for pithy quote.

Contents of This Page

We use classes and IDs to hang specific modifications from in our stylesheets.

What exactly does that mean?

In and of themselves, classes and IDs do nothing. It's what we do with them that counts. We "hook" things to them.

The folks at CSS-Discuss note:

Classes are useful to apply similar declarations to a variety of elements. In design, you often want thematic style to be applied consistently. For example, you may wish for all external links to be red, while internal links are blue. Using the class attribute in this case makes sense. IDs are useful to uniquely identify a particular element. On the face of it, this may seem to be a narrow use, but if you consider that a Contextual Selector [see below] can be used to apply declarations to elements which are contained by a particularly ID'ed element, the usefulness is greater. For example, you may wish to have all menu links be green, while content links are red. Placing the menu inside an element which is ID'd as "menu" or "content" respectively allows you to make contextual styling based on the section of the page.

Wow, that was confusing. Accurate, but confusing (and when you get this concept figured out, you'll reread this quote and agree with it completely).

Chris Coyier writes:

We need ways to describe content in an HTML/XHTML document. The basic elements like <h1>, <p> and <ul> will often do the job, but our basic set of tags doesn't cover every possible type of page element or layout choice. For this we need ID's and Classes. For example <ul id="nav">, this will give us the chance to target this unordered list specifically, so that we may manipulate it uniquely to other unordered lists on our page. Or we might have a section on our page that has no relevant tag to signify it, for example a footer, where we might do something like this: <div id="footer">. Or perhaps we have boxes in our sidebar for keeping content over there separated in some way: <div class="sidebar-box">.

Did that help you or confuse you? Maybe a little of both?

That's partly because Chris is talking about using classes and IDs for layout purposes, something you may not have gotten to yet.

More about layouts.

In the stylesheet, classes and IDs can either stand alone or go with an HTML element:

either

.bigfont {
   font-size: 4em;
}

p.bigfont {
   font-size: 4em;
}

Notice that the class is designated by the period in front of the class name: .bigfont. Just the word "bigfont" by itself would mean nothing in your stylesheet.

Both of these examples make a pretty huge font when applied to a specific chunk of code. The first class, bigfont, can be applied to anything: an unordered list, a blockquote, a header, whatever. It's what the code warriors call "an implied universal selector," applying to anything you like. The second, bigfont p, will only work if applied to a paragraph (<p>).

Here's how either of them would work in your HTML page:

<p class="bigfont">text to be enlarged</p>

Only the text in the paragraph classed bigfont would be enlarged.

You can even use multiple classes in a single CSS element. Here's an example suggested by Olsson and O'Brien, and modified by me:

div.foo.bar {
   font-size: 4em;
}

div.foo.bar[title^="Help"] {
   font-size: 4em;
	color: #ff08ff;
}

In the first selector, the div labeled with two classes, .foo and .bar, would only effect changes on an HTML div element with both classes incorporated into it:

<div class="foo bar">Matches 1st example</div>

In the second selector, the div labeled with two classes, .foo and .bar, and incorporating the title, Help, would only effect changes on an HTML div element with both classes incorporated into it:

<div class="foo bar" title="Help">Matches 2nd example</div>

Note: Internet Explorer has some bugaboos with classes. In IE6, the class selector doesn't work if the class name starts with a hyphen (-) or an underscore (_). IE6 and below (IE5.5, for example, which few people bother with designing for, but IE6 is still out there in all its persnickety glory), if you use multiple class selectors (as in our example above), it will only pay attention to the last selector, and will ignore the others. Grr.

The Difference between Classes and IDs

An ID (short for identifier), works exactly like a class. Everything written above also applies to IDs.

So what's the difference? Actually, some fairly big ones.

An ID is identified by a # instead of a ., like so:

#bigfont {
   font-size: 4em;
}

An ID can only be used once per HTML page, where a class can be used over and over again. There's a reason for that: the # mark is used for internal links, like so:

http://www.example.com#comments

The browser goes directly to the element ID'd as "comments".

Let's say that again, with feeling:

An ID can only be used once per HTML page, where a class can be used over and over again.

If you do repeat an ID in a page, some browsers will be forgiving enough to display it the way you meant it to be seen, but some won't. And it will not pass a validation check.

More about validating your pages.

Coyier gives us a terrific analogy about the difference between classes and IDs:

Maybe a good analogy here is bar codes and serial numbers. Take an iPod in a store. On the packaging will be a bar code. This tells the store what the product is, so when it is scanned, the system knows exactly what the product is and what it costs. It might even be able to know what color it is or where it was kept in the store. All iPod of this same type have the exact same bar code on them.

The iPod will also have a serial number on it which is absolutely unique to any other iPod (or any other device) in the world. The serial number doesn't know the price. It could, but for the store this wouldn’t be a very efficient way to store and use that data. Much easier to use the barcode, so that for example, if the price changed, you could just change the price for that bar code and not every individual serial number in your system.

This is much like ID's and Classes. Information that is reuseable should be kept in a class and information that is totally unique should be kept in an ID.

You can specify a particular element to be affected with the ID selector:

ul#navigation {
   font-size: 2em;
}

but make sure no whitespace is between the type selector and the ID selector. In other words, this:

ul #navigation { WILL NOT WORK!
   font-size: 2em;
}

will not work!

Note: Internet Explorer 6 will ignore an ID selector unless it's the last one in the selector; if you put a class after it in a multiple selector, IE6 will not recognize it. Grr again.

Limiting Classes to Specific Elements

One thing you can do with a class that you can't do with an ID is to give specific elements with that class particular styling, while not putting that styling on other instances of that class.

Say what? Here's an example.

Say you've created a class called "critical", used for the most important parts of your text content. You want to style it in a classy serif font, boldface it, increase its size a bit, and expand the letter spacing to set it off just that little bit more:

.critical {
   font-weight: bold;
   font-family: "Palatino Linotype", "Book Antiqua", "Century Schoolbook", Georgia, serif;
   letter-spacing: 0.05em;
}

But, you decide that text inside a blockquote should be italicized instead of made bold. Easy enough:

blockquote.critical {
   font-weight: normal;
   font-style: italic;
}

Note there is no space between "blockquote" and ".critical."

Now, this text:

<blockquote class="critical">
   <p>Important text.</p>
</blockquote>

will appear in the proper font, with the proper letter-spacing, but italicized instead of in boldface.

Ian Lloyd explains it better than I can:

By prefixing our normal class selector with an element name, we're telling the browser to apply the following declarations to that element-and-class combination only. It's as simple as element.class, but make sure you don't leave any spaces!

Using Classes and IDs Semantically

Coyier reminds us about using classes and ID semantically. Instead of paraphrasing, let's just quote him:

Also avoid this:

<div id="right-col">

ID is appropriately used here as the page will likely only have a single right column, but the name is inappropriate. Try and describe the context of the element, not where it is or what it looks like. An ID here of "sidebar" would be more appropriate.

This is a mistake I commonly make, so don't repeat my blunders.

The Wonderful World of Fonts » Best Practices HTML and CSS

2010-05-30T04:45:08Z

Shared by Max Black
designsite

Web Design Principles
The Wonderful World of Fonts and Typography

Looking for the lessons? Get started!

A look at fonts and typography for Web sites.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Web design is 95% typography. — Oliver Reichenstein

Contents of This Page

There is a lot more to choosing fonts than merely picking a font you like from Microsoft Word. There are really only a few fonts that work on (almost) all systems, from Windows to Mac and Linux. These are called "web-safe" fonts because you can expect that, when you use them, almost all the people who visit your site will see it in the font you like.

If you don't have Microsoft Word on your machine, try using your word processor or text editor to display the fonts. If you don't have one of those, then you'll have to go through your machine's Fonts applet (or your equivalent) to display your fonts. There are also a lot of free font utilities on the Internet to manage and display the fonts on your machine. One simple one I can recommend for Windows users is Free & Easy Font Viewer. A free utility for Mac and Linux users (and Windows, if they choose) is Opcion.

Here's a list of the "web-safe" fonts, from WebDesignDev and my own SitePoint article. (All the images are public-domain PNGs from Wikimedia.) The fonts in italics can be found on 95%+ of the computers in existence. The others are on a strong majority of systems, and can be used to base your font-family "font stacks" on as well.

The Four Types of Fonts

Serif Fonts: Copperplate Gothic Light, Georgia, Palatino Linotype, Times New Roman (pictured below)

In the second illustration, the serifs of the font are marked in red.

Sans-serif Fonts: Arial, Arial Black, Arial Narrow, Century Gothic, Gill Sans, Lucida Sans Unicode, Tahoma, Trebuchet MS, Verdana (the illustration below depicts Helvetica, a Mac font very similar to Arial)

Monospace Fonts: Andale Mono, Courier New (pictured below), Lucida Console

Cursive and Fantasy Fonts: Comic Sans MS, Impact (not sure what font is depicted below)

Only about half of these fonts can reasonably be used to create "font stacks" for your pages, particularly your body text — you don't want to sacrifice readibility for appearance. That's why three relatively boring fonts — Verdana, Arial, and Arial's Mac cousin, Helvetica — are perhaps the most popular body text fonts in use today.

Font Stacks Using @font-family

Creating "families" of fonts in what we call @font-family groups, after the CSS property, is something designers argue over at length. But, everyone appreciates a starting place.

Here are some very simple, basic suggestions for font stacks you might use in your designs. Remember, these are suggestions. Take them, use them, think about them, and change them as needed.

The basic formula is simple: Start with a font you like, then give a close alternative that others will see if they don't have the font you like, then give a more universal (web-safe) alternative, and finally end with the generic "serif," "sans-serif," or "monospace" font name. Remember, the universal fonts go at the END of the stack, not the beginning!

Notice that all fonts that have more than one word must be enclosed in quotes, with the comma outside the closing quote: for example:

"Times New Roman", serif.

Serif Fonts

A good serif font stack to start with might be:

font-family {
   Georgia, "Times New Roman", serif;
}

What you're telling the browser: "Use Georgia to display this text. If you don't have Georgia on your machine, use Times New Roman. If you don't have that, either, use whatever default serif font you have."

Here's a serif font stack I sometimes use, beginning with a Microsoft Vista font, following with two serifs often used on Linux machines, and finishing with the two universal fonts:

font-family {
   Constantia, "Liberation Serif", "Nimbus Roman No9 L 
Regular", Georgia, "Times New Roman", serif;
}

Note: Georgia looks better than Times New Roman on the Web, and should be used in preference, i.e. before Times New Roman in your stacks.

Sans-Serif

A good sans-serif font stack might be:

font-family {
   Helvetica, Arial, sans-serif;
}

Here's a sans-serif font stack I sometimes use, again beginning with a Microsoft Vista font, following with two sans-serifs often used on Linux machines, continuing with a widely used Mac font, and finishing with the near-universal Arial:

font-family {
   "Segoe UI", "Liberation Sans", "Nimbus Sans L", Helvetica, 
Arial, serif;
}

Verdana is perhaps the most widely used font on the Internet, because it is so readable and easy on the eye. It's a good bit wider than the relatively narrow Helvetica/Arial combinations. Here's a Verdana-based stack you might consider, starting with a popular Mac font, moving to two Linux fonts, and ending with Verdana:

font-family {
   "Lucida Grande", "DejaVu Sans", "Bitstream Vera Sans", 
Verdana, sans-serif;
}

Many experts believe that sans-serif is a better font choice for large blocks of text (say, paragraphs) that serif. I'll let Ian Lloyd explain:

A serif font is one that has all those little flourishes at the ends of each letter. These flourishes ... are known as serifs. They're great for reading printed material, as they give a little shape to the words, making them easier to read. However, on the screen, serif fonts can become a little messy, especially when they're used for smaller type — there simply aren't enough pixels on the screen to do these little flourishes justice. For this reason, you’ll notice that many web sites use sans-serif fonts (from French, translating as 'without serif') when the font size is set quite small.

Serif fonts are excellent for headers and blocks of text intended to be displayed in larger sizes, and with fewer words included.

Does everyone agree with this? Not at all. For a single example out of many, my friend Vivien, in her site Inspiration Bit, gives us an excellent compendium of 32 sites designed around the Georgia font.

Monospace Fonts

Monospace fonts are used primarily for presenting code and other "fixed-width" text. (You're seeing the code on these pages in either Consolas, Andale Mono, Lucida Console, or Courier New, depending on what's on your machine.) A good monospace font stack might be:

font-family {
   "Andale Mono", "Courier New", monospace;
}

Here's a monospace font stack I sometimes use, again beginning with a Microsoft Vista font, following with two sans-serifs often used on Linux machines, and finishing with two web-safe fonts:

font-family {
   Consolas, "Liberation Mono", "Nimbus Mono L", "Andale Mono", 
"Courier New", monospace;
}

Fantasy/Cursive Fonts

It's tough to create a fantasy or cursive font stack that will show up on most computers. The only two that are widely used, Impact and Comic Sans MS, are very, very different in appearance; Impact is a heavy, compressed font sometimes used for headers, and Comic Sans MS, created to give the appearance of "comic-book" lettering, has been so terribly overused and misused that many designers refuse to use it at all.

Warning: A lot of people don't like the Vista fonts (I used Constantia, Segoe UI, and Consolas in my examples). If you find they don't look good in your designs, take them out!

A lot of designers like to combine serifs and sans-serifs in their designs. For example, the design for this site uses Georgia, a "universal" serif font, as its base, and a sans-serif, Helvetica Neue, as the font for its central body content. (You're reading this in Helvetica Neue right now, or, if your machine lacks that font, either Helvetica or Arial.) The combination of serifs and sans-serifs seems to work very nicely in most designs.

Making Font "Shortcuts"

Like some other CSS properties, you can make "shortcuts" out of multiple font properties. For example:

.regtext {
   font-weight: bold;
   font-size: 14px;
   font-family: verdana, arial, sans-serif;
}

can be shortened:

.regtext {
   font: bold 14px verdana, arial, sans-serif;
}

The folks at Tech-Evangelist, whose shortcuts I cribbed, remind us:

Not all related CSS rules can be combined into a shortcut, but many of the most commonly used rules can be condensed into a single line. You do need to be aware that order in which you place the CSS values does make a difference. Also, CSS shortcuts should be tested in a range of browsers because CSS rules are not always interpreted the same. Internet Explorer 6 is very buggy when it comes to rendering CSS rules properly. You should test all style sheet code in all of the most popular browsers...

Styling Your Fonts

There are several ways to control the appearance of a font. Four of the most common are listed below:

Font size
Font style
Font weight
Font variant

Let's look at each of these in turn.

Font size

The meaning of the CSS attribute font-size is pretty obvious. It controls the size of the font as it appears on your display. There are several ways to choose the size of your font: pixels, ems, percentages, and keywords. You might want to review the section on units of size:

More about units of measuring size.

Pixels are absolute across all browsers. Setting your font's size in pixels prevents some browsers, particularly Internet Explorer 6 and7, from allowing a user to resize the font using the text-resize function in their browsers. Firefox and Safari users can resize pixel-defined fonts, while Opera and IE7 users have a "zoom" function that resizes the page quickly and easily, text included. One popular "baseline" font size is 16px:

body {
   font-size: 16px;
}

Ems are relative units of measurement. It is considered best practice to use ems whenever possible in sizing fonts (and other Web elements). It is scalable, which means that it resizes relative to its parent element. (Confused yet?) If you set a font size on the body, or even better, if you don't set a font size on the body, thereby leaving it up to the user's own preferences, the subsequent font elements — headers, paragraphs, list items, margins, paddings, and the like — will resize relative to that original "parent" size.

We'll go back to the popular 16-pixel base size for our example. If your user has chosen 16 pixels as his base font size (or more likely, your user hasn't chosen anything and left it to his browser default), everything you size will be relative to that 16px base. For example:

h1 {
   font-size: 2em;
}

h2 {
   font-size: 1.5em;

p {
   font-size: .9em;
}

ul li {
   font-size: 1.2em;
}

makes the following size choices:

Your h1 elements will be twice the size (2em) of the base font size of 16px — in essence, 32px.
Your h2 elements will be 1.5 times the size (1.5em) of the base font size of 16px — in essence, 24px.
Your p elements will be .9 times, or 90% (.9em) of the base font size of 16px — about 14px.
Your li elements (in your ul) will be 1.2 times, or 120% (1.2em) of the base font size of 16px — about 19px.

Change the base font size from 16px to something else, say 12px, and the relative sizes change as well:

Your h1 elements will be twice the size (2em) of the base font size of 12px — in essence, 24px.
Your h2 elements will be 1.5 times the size (1.5em) of the base font size of 12px — in essence, 18px.
Your p elements will be .9 times, or 90% (.9em) of the base font size of 12px — about 11px.
Your li elements (in your ul) will be 1.2 times, or 120% (1.2em) of the base font size of 12px — about 14px.

(See below for a different take on using ems in your layout.)

Percentages are quite similar to ems in their effect on your font sizing. Percentages work like so:

h1 {
   font-size: 200%;
}

h2 {
   font-size: 150%;

p {
   font-size: 90%;
}

ul li {
   font-size: 120%;
}

Yahoo Development Network gives us a useful chart that tells us what percentage to use to get our fonts at a particular pixel size, i.e. 16px=123.1%. The chart assumes a default of 13px and a 16px line-height, and assumes the user has not altered the browser or monitor defaults.

Font style

This seems a bit generic of a term to use, considering everything we're doing is "styling" fonts. But this font attribute simply controls whether the font presents itself as normal (the default value), italicized, or oblique:

p {
   font-style: italic;
}

h4 {
   font-style: oblique;
}

The oblique value isn't used often, mostly because a lot of fonts don't have an oblique version. Most browsers use italics as a substitute for obliques.

Font weight

The font-weight attribute helps you decide how much "weight," or thickness, to add to a font. It gives you some finer control than the usual "boldface," or HTML <strong> </strong> tag. Basically, it goes from 100 to 900 in gradations of 100 (in other words, a font-weight of 247 won't be of any use). Stick to 100, 200, 300, and so on.

Many browsers won't display a lot of difference between the 100s, either. While you can use them if you like, you'll probably be just as well served sticking to the three most popular font-weight values: 100 (light), 400 (normal), and 700 (heavy, or bold):

p {
   font-weight: 100;
}
OR
p {
   font-weight: 400;
}
OR
p {
   font-weight: 700;
}

You can also use keyword values such as bold, bolder, and normal, but few designers use these.

Font Variant

There is only one "variant" in the font-variant group, the ability to have fonts appear in small caps. Not every font supports small caps. Here's how to use it:

p {
   font-variant: small-caps;
}

The 62.5% Method of Sizing Fonts

I know I talked about font sizing just above, but this is tricky enough to warrant its own section.

This information is based on the excellent book by Craig Grannell that I reference throughout this site, a blog post by Trevor Davis, and two articles by the inventor of this technique, Richard Rutter.

Basically, the idea is to set your base font size in your body (or whatever other governing element you choose to use, i.e. your wrapper) to 62.5%. This causes your base font size to display at 10 pixels in most browsers. By doing this, 1em of size is equivalent to 10px.

Designers do this primarily because Internet Explorer won't resize text set in pixels. Some later versions of IE will "zoom" the entire page, but that pain-in-the-rumpus browser won't resize just the text, like just about every other browser does.

Rutter writes:

Text for the screen is sized with CSS in terms of pixels, ems or keywords. As most of us know, sizing with pixels is easy: get your selector and give it a font-size — no more thought required. Sizing with keywords is more complicated and requires a few workarounds, but you're in luck as the techniques are well documented. That leaves ems. At this point people often leg it. "Ems are too inconsistent," they say, "they're too hard; they never work." ... If the world were an ideal place, we'd all use pixels. But it's not, we have the broken browser to contend with. IE/Win will not allow readers to resize text that has been sized in pixels. Like it or not, your readers will want to resize text at some point. Perhaps they are short-sighted, doing a presentation, using a ridiculously high resolution laptop or simply have tired eyes. So unless you know (not think) your audience won’t be using IE/Win or will never wish to resize their text then pixels are not yet a viable solution. ... Using ems however, allows all browsers to resize text and also provides pixel-level precision and so they tend to be my unit of choice.

Davis notes that he does something slightly different:

Although I typically then set my container font-size to 1.2em, which in turn sets the font-size to 12 pixels. But still, then you know that 1em is equal to 12 pixels.

Rutter agrees, noting that "10px text is too small for the real world." Using his technique allows us to do the following:

1em is 10px, 0.8em is 8px, 1.2em is 12px, 1.6em is 16px, and so forth.

You have to size the individual elements — the paragraphs, headers, list items, etc — but this method gives you a great deal of control over your font sizes, and enables you to use ems quickly and easily. Basically, Rutter has done the math for you.

This isn't a foolproof method by any stretch: there are issues with it, which is why many designers (including myself, at least as of this writing) don't use it. (One problem is that ems cascade and pixels do not, which means that if you size your body fonts at, say, 1.3em and your h1 at 1.5em, your h1 will display at 19.5px, not 15px as you may have planned. Kudos to Will Bond for pointing this out. And SitePoint adviser Stephen Chapman notes that 1em won't necessarily equal 10px unless the user's screen resolution is set to 1em=16px, which it often is, but not always. In a related SitePoint thread, design adviser Paul O'Brien gives an excellent method of setting all browser displays to a default of 13px.) But many, many designers swear by it. You may well adopt it for your own purposes.

One excellent source of information on this method, and the use of ems in general for sizing fonts, is Jon Tan's article on ems and elastic layouts.

Further Reading

Reading Jon Tan is a must for anyone interested in the finer aspects of typography and fonts for the Web. (And check out the subtly elegant site design while you're there.) If you're not sure where to start, try this entry first, and go from there.

Typography maven and Web design expert Jason Santa Maria gives us an excellent overview, with detailed examples, for using a variety of fonts in your designs.

Block and Inline Elements » Best Practices HTML and CSS

2010-05-30T04:44:34Z

Shared by Max Black
designsite

Web Design Principles
Block and Inline Elements

Looking for the lessons? Get started!

Information on block and inline elements.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Placeholder for pithy quote.

Contents of This Page

There are two kinds of elements in HTML: block and inline. The difference is, as Tommy Olsson writes, "mainly semantic and grammatical." But I think we can decrypt Tommy's description to provide a more colloquial understanding.

I'm going to start by quoting a long but excellent metaphor from Ian Lloyd (emphasis mine):

I've moved house recently. When was the last time you moved? It's amazing how much stuff we seem to amass, especially those little trinkets that collect dust on the mantelpiece. You have to find some small boxes to put these bits and pieces in so they don't get damaged, and of course you then need some larger packing boxes into which you can put those smaller boxes. So on the day before the move — possibly earlier if you're more organized than I am — you start to place your trinkets into small boxes (here's a tip: shoe boxes work well). You then place those shoe boxes into bigger boxes, along with some books and those video tapes of the X-Files that you know you'll never watch but can't bring yourself to throw away. This process continues through the night, and eventually (usually about three minutes before the moving truck is due to arrive) all of your stuff is finally packed and ready to go (whew!). If you think of the different types of boxes as block-level elements, and your other stuff — the books, videos and trinkets — as inline elements, you'll start to understand the difference between the element types.

Two differences I have with Ian on this: one, my wife insists on having us packed days before we are to move, and two, I fully intend to watch some of my X-Files videotapes again someday....

Block-Level Elements

Block-level elements act as "containers" for other elements. In other words, you put other elements inside block elements. Lloyd again:

A block-level element can contain other block-level elements, as well as inline elements.

Here's an incomplete list of block elements, courtesy of Olsson and HTML Help:

blockquote
div
header (i.e. h1)
p
ul
ol
form
table

Some block-level elements, such as p, can only contain text and inline elements. Others, such as form, can contain only block-level elements (in HTML Strict coding, at least). And some, like the ubiquitous div, can contain text, inline, and block-level elements.

Unless you override the browser's default styling, block-level elements such as p and div have an implicit line break both before and after, making it impossible to have two block-level elements side by side on the same page. (CSS commands can override this.)

Sizing the Blocks

By default, a block-level element expands to a width of 100% of its parent container, whether it be the entire body element, a container element such as a div, or something else. It will also expand by default to whatever height it needs to have. But remember — "default" means "I can change it." So let's see how we can change the default width and height of a block-level element.

(In doing this, we're moving towards learning how to create layouts for our pages. Are you excited yet?

More about layouts.

You can see this by looking at this very text. This text that you're reading right now is contained inside a block-level element — a p — that, except for imposed padding, stretches to take up the entire center column of this page. However, the light gray and dark gray boxes (in p, ul, and pre block-level elements respectively) have their widths constrained to, I believe, 95%. That prevents them from ramming up against the right-hand border of the center column.

Let's give an example.

Say you want to "punch up" a particular paragraph, to get the attention of your readers. You create a "punchup" class:

.punchup {
   width: 50%;
   padding: 5px;
   font-weight: bold;
   color: #ff0000;
   font-size: 1.25em;
   background-color: #ffe4e1;
}

Any paragraph with the .punchup class will be constrained to 50% of the width of its parent container, has some padding, will be in bold, will be bright red, will be 25% larger than the other text, and has a light pink background to make it stand out that much further.

<p class="punchup">This text is guaranteed to snag the attention of all your readers. Woo-hoo!</p>

It looks like this:

This text is guaranteed to snag the attention of all your readers. Woo-hoo!

With all the fancy text formatting used in that class, the width constraint may make the biggest impact, as it sets that text apart from the surrounding text.

We could add height to the code also:

height: 250px;

giving us:

This text is guaranteed to snag the attention of all your readers. Woo-hoo!

Notice that the element is significantly elongated vertically, and is flush against the left side of the container (minus padding). We could increase the height even more, and use this structure to develop a vertical "sidebar" for a page, maybe containing a navigation scheme or other such info. And we will, a bit later on.

You can also add borders to block-level elements, further defining the blocked-out space. Insider tip: Not only do borders often look good in a final design, many designers use a 1px black border around all of their elements during the design process, to help them keep track of how their block-level elements are positioned on the page. They remove the borders before you and I see the final product.

More about borders.

The Box Model

We're learning the rudiments of what Web designers call "the box model" — using block-level elements with margins, padding, height, and width values to construct "boxes" in which to contain our material. See the links below for more information.

More about margins and padding.

More about positioning elements.

More about layouts.

Inline Elements

Inline elements function "inline" within text. Lloyd writes:

An inline element can only contain other inline elements. ... It's perfectly okay to nest one inline element inside another. ... [However, i]nline elements can never contain block-level elements.

Again relying on Olsson and HTML Help, here's a partial and (very) incomplete list of the most popular inline elements in HTML:

a (the anchor element)
cite
em
img
span
strong

Inline elements do not contain block-level elements (with one exception, the object element, which we won't get into here). Inline elements have no implied line breaks.

Some designers believe that they can transform an inline element with the CSS display: block declaration. This does not work; i.e. you cannot put a h1 element inside a a href link. Let's let Olsson explain this one:

HTML has block-level and inline elements. CSS has block and inline boxes (plus a few others). These are very different things. The distinction in HTML has to do with semantics and syntax, while the distinction in CSS has to do with rendering and presentation. By default, block-level elements generate block boxes, and inline elements generate inline boxes (this is a grossly simplified explanation, but is generally true). The display property can change the type of the generated box, but CSS cannot change the grammatical or syntactical rules of HTML.

Note: One of the most important, and often overlooked, characteristics of the img element is that it is an inline element and not a block-level element. It must be contained within a block-level element, usually a div or a p:

<p>Some text.</p>
<img src="images/picture.jpg> This is WRONG.
<p>Some more text.</p>

This leaves the inline img element stranded, with nothing to contain it.

<p>Some text.</p>
<p><img src="images/picture.jpg><p> This is RIGHT.
<p>Some more text.</p>

This places the inline img element inside a block container, all safe and snug.

Borders » Best Practices HTML and CSS

2010-05-30T04:44:08Z

Shared by Max Black
designsite

Web Design Principles
Borders

Looking for the lessons? Get started!

Short description of page contents.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

[W]hy should love stop at the border? — Pablo Casals

Contents of This Page

CSS allows you to place borders around elements such as paragraphs, divs, and other block-level items. You have a number of options as to both styles and widths.

Border Styles

solid
double
groove
dotted
dashed
inset
outset
ridge
hidden (the default)

Let's take a look at how they shape up in our stylesheet. We'll use the <p> element to hang our border on, and give each paragraph a class corresponding to the border style.

More about classes.

p.solid {
   border-style: solid; 
}

OR

p.double {
   border-style: double; 
} 

OR

p.groove {
   border-style: groove; 
} 

OR

p.dotted {
   border-style: dotted; 
} 

OR

p.dashed {
   border-style: dashed; 
} 
OR

p.inset {
   border-style: inset; 
} 
OR

p.outset {
   border-style: outset; 
} 

OR

p.ridge {
   border-style: ridge; 
} 
OR

p.hidden {
   border-style: hidden; 
}

gives us:

This paragraph has a solid border around it.

This paragraph has a double border around it.

This paragraph has a grooved border around it.

This paragraph has a dotted border around it.

This paragraph has a dashed border around it.

This paragraph has an inset border around it.

This paragraph has an outset border around it.

This paragraph has a ridged border around it.

This paragraph's border is hidden.

Almost no one uses the hidden value for a border unless it is to override an earlier styling.

Border Widths

Border widths work only if styles are also chosen (obviously). You can make your border a single pixel in width or something hugely big, whatever works for your design needs. While there are keywords such as "medium" and "thick" available, I've never seen anyone use them. Stick with pixels.

p.groove {
   border-style: groove;
   border-width: 10px;
}

gives us

This paragraph has a grooved border 10 pixels in width.

Border Colors

By default, borders show in black in most browsers. If you find that boring, you can change that color to something far more spiffy.

p.groove {
   border-style: groove;
   border-width: 10px;
   border-color: #f25f0f;
}

gives us this:

This paragraph has a grooved border 10 pixels wide, colored in spiffy orange.

(Notice that some border styles automatically give a lighter variant of the selected color to help create the groove, or ridge, or whatever styling.)

You can use other color value methods such as RGB or keywords (i.e. 100 100 255 or blue, but I prefer the hexes.

Setting the Direction of Your Borders

So far we've looked at making borders for all four sides of the block element. If you want a border on fewer than four sides, that's easy to implement.

The key is the border-[direction] property. You pick your choice of direction (or side):

top
right
bottom
left

No surprise there....

However, most designers don't use it by itself, but in conjunction with other border style properties. Here are some examples, cribbed from the page at Tizag. You can get an idea of how it's used, and then try your own combinations.

p { border-bottom-style: dashed; 
   border-bottom-color: yellow; 
   border-bottom-width: 5px; 
}

gives us:

This paragraph has a yellow, dashed bottom border 5 pixels in width.

p { border-top-style: double; 
   border-top-color: purple; 
   border-top-width: thick;
}

gives us:

This paragraph has a purple, double top border using the "thick" CSS value (which we normally don't use).

And you can add multiple border styles to a single paragraph (or other element) for maximum, over-the-top styling.

Combining the Selectors and Values

Most designers don't waste time and bandwidth writing multiple lines of border code. It's much easier to combine them into one line, using the border property.

Here's one example, combining three values of width, style, and color:

p {
   border: 20px outset blue;
}

giving us:

This paragraph has a border 20 pixels wide, blue in color, and outset.

Margins and Padding » Best Practices HTML and CSS

2010-05-30T04:43:42Z

Shared by Max Black
designsite

Web Design Principles
Margins and Padding

Looking for the lessons? Get started!

The many ways to add margins and padding to HTML elements.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Placeholder for pithy quote.

Contents of This Page

Margins and padding both provide space between various HTML elements. But they do it in somewhat different ways.

One of the most confusing differences in Web design is between margins and padding, and the decision as to when to use one or the other sometimes puzzles even knowledgeable designers. So let's start with the difference between the two. I cribbed this from an excellent short article on the subject by Kamal Mettananda.

Margin: defines space between border and other outer elements.
Padding: defines space between border and element content.

What does that mean, exactly? Let's take a look at the diagram (used with permission from Kamal Mettananda).

See the difference? When separate elements need space between them, use a margin. When text or an inner element needs space between itself and its parent, use padding.

Margins

As we can see in the graphic above, margins define the "negative space," or "whitespace," around an HTML element such as a paragraph, a header, an image, a div, or something else.

p {
   margin: 15px; 
   border: 1px solid black;
}

gives us:

This paragraph has a nice fat margin of 15 pixels on every side. The border shows you where the edge of the <p> element is.

How can you tell? The example paragraph is somewhat farther away from the rest of the text than other paragraphs in this section. That's because of the margin. (The space between the top, right, bottom, and left edges of the paragraph itself and the border is the default padding added by your browser. See below for more on padding.)

Elements such as the paragraph have some default margins built into the browsers' own stylesheets (yes, they have them, and they are different from one browser to the next), but it usually isn't much, and you can't rely on it to drive your design. Best to control your margins yourself.

Margin Units of Measurement

Like so many other things on the Web, you can use margins with pixels, ems, or percentages:

p {
   margin: 15px;
} 

OR

p {
   margin: 1em; 
} 

OR

p {
   margin: 2%; 
}

Some situations call for one, some for the other. I've never used percentages in margins myself, so I can't speak to that one. I've used both pixels and ems frequently. Remember, ems are flexible and pixels are absolute and unchanging (as much as anything on the Web is "unchanging" ...)

Margins for the Four Sides

Sometimes you want an equal amount of margins on all four sides of a "box" element such as our paragraph above. In that case, you get off easy. The default for margins is to set all four sides equally:

p {
   margin: 15px; 
}

gives us a paragraph with 15 pixels' worth of margins on each of the four sides — top, right, bottom, and left.

TRouBLe

The four values of the margins go in clockwise order: from the top, to the right, to the bottom, and finally to the left.

An easy memory prompt (a mnemonic) is to remember the word TRouBLe (trouble) for the Top Right Bottom Left order. If you don't follow the order properly, you'll be in TRouBLe.

You can add different margins to each side of your paragraph or other HTML element. The order is, as I noted, clockwise, but let's start with the longhand version:

p {
   margin-top: 0px;
   margin-right: 2px;
   margin-bottom: 40px;
   margin-left: 5px;
   border: 1px solid black;
}

gives us something like:

This paragraph has a different margin on each of its four sides. As with the other example, the border shows the outer edge of the <p> element.

Do you have to write so many properties when you add margins to a single element? No! You can use shortcuts. The same margin values in the above example can be shortened in your coding:

p {
   margin: 0 2px 40px 5px;
}

for the exact same result:

This paragraph has a different margin on each of its four sides, but this time we used a nifty shortcut. Again, the border shows the outer edge of the <p> element.

Note the spacing between the four values, and note that the values go clockwise around the four sides of the box, our "TRouBLe" paradigm.

Often we want to add one value of a margin to the left and right, and another to the top and bottom. We can do that with CSS shortcuts also:

p {
   margin: 20px 5px;
}

In this case, the first value controls the top and bottom margins, and the second value controls the right and left margins:

This paragraph has top and bottom margins of 20px and right and left margins of 5px. The border shows the outer edge of the <p> element.

Padding

Tizag gives us a succinct explanation of padding:

A padding is the space between an element's border and the content within it.

In real-world terms, we often use padding to give us some "negative space," "whitespace," or simply some breathing room between text or an image and its containing border. Here's two examples (you'll see how similar they are to the examples in the margin section just above):

p {
   padding: 15px; 
   border: 1px solid black;
}

gives us:

This paragraph has a nice fat padding of 15 pixels on every side. The border shows you where the edge of the <p> element is.

To the contrary, here's this:

p {
   padding: 0; 
   border: 1px solid black;
}

gives us:

This paragraph has no padding at all. The border shows you where the edge of the <p> element is. Claustrophobic, isn't it?

Like margins, elements such as the paragraph have some default padding built into the browsers' own stylesheets (yes, they have them, and they are different from one browser to the next), but it usually isn't much, and you can't rely on it to drive your design. Best to control your padding yourself.

Padding Units of Measurement

Like so many other things on the Web, you can use padding with pixels, ems, or percentages:

p {
   padding: 15px;
} 

OR

p {
   padding: 1em; 
} 

OR

p {
   padding: 2%; 
}

As I wrote above for margins, some situations call for one, some for the other. I've never used percentages in padding myself. I've used both pixels and ems frequently. Remember, ems are flexible and pixels are absolute and unchanging (as much as anything on the Web is "unchanging" ...)

Padding the Four Sides

Sometimes you want an equal amount of padding on all four sides of a "box" element such as our paragraph above. In that case, you get off easy. The default for padding is to set all four sides equally:

p {
   padding: 15px; 
}

gives us a paragraph with 15 pixels' worth of padding on each of the four sides — top, right, bottom, and left. (Notice I went around the four sides like a clock, from the top around clockwise to the right. We follow the same rule here as with margins: the four sides are dealt with in clockwise order by your stylesheet.)

You can add different paddings to each side of your paragraph or other HTML element. The order is, as I noted, clockwise, but let's start with the longhand version:

p {
   padding-top: 0px;
   padding-right: 2px;
   padding-bottom: 20px;
   padding-left: 5px;
   border: 1px solid black;
}

gives us something like:

This paragraph has different padding on each of its four sides. As with the other example, the border shows the outer edge of the <p> element.

Do you have to write so many properties when you add padding to a single element? No! You can use shortcuts. The same padding values in the above example can be shortened in your coding:

p {
   padding: 0 2px 20px 5px;
}

for the exact same result:

This paragraph has different padding on each of its four sides, but this time we used a nifty shortcut. Again, the border shows the outer edge of the <p> element.

Note the spacing between the four values, and note that the values go clockwise around the four sides of the box, our "TRouBLe" paradigm.

Often we want to add one value of padding to the left and right, and another to the top and bottom. We can do that with CSS shortcuts also:

p {
   padding: 20px 5px;
}

In this case, the first value controls the top and bottom padding, and the second value controls the right and left padding:

This paragraph has a top and bottom padding of 20px and a right and left padding of 5px. The border shows the outer edge of the <p> element.

Internet Explorer 5.5's Quirky Handling of Margins and Padding

Note: Internet Explorer 5.5 for Windows does not deal with margins or padding (or borders, for that matter) correctly. If you find yourself unlucky enough to have to design for that rather antiquated browser, you might be interested in learning about the box model hack that can get around IE5.5's problems.

Different Kinds of Stylesheets » Best Practices HTML and CSS

2010-05-30T04:37:31Z

Shared by Max Black
designsite

Web Design Principles
Types of Stylesheets

Looking for the lessons? Get started!

The three different kinds of stylesheets, and more.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Placeholder for pithy quote.

Contents of This Page

There are three ways to style your page with CSS:

External — keeping it in a separate file;
Internal — including it in the head of each page; and
Inline — including individual style commands in the HTML itself.

There's one thing all three have in common: the same kinds of user mistakes. I've made them, others make them, and you will make them. Tizag.com gives us this reminder:

Until you become accustomed to using CSS code, you will probably find your CSS code not working as you expected. A leading cause of this might be an out of place :, ;, {, or } or it might be that you forgot to use a :, ;, {, or } when it was required.

Remember, computers are stupid. They have no more intelligence than the tables they sit on. They don't know when you meant to include a code snippet like a ; or a }, and they won't fix it for you.

Anyway, back to it.

External Stylesheets

External stylesheets (sometimes called embedded stylesheets) are considered the best way to handle your CSS. There's a very simple reason for this: when you're managing a site of, say, 100 pages, all controlled by a single stylesheet, and you want to change your link colors from blue to green, it's a lot easier to make the change in your CSS file and let the changes "cascade" throughout all 100 pages than it is to go into 100 separate pages and make the same change 100 times. External stylesheets also reduce the amount of Web page code, which makes it easier for Google and other search engines to find your page's content and give your page a higher ranking. And, since browsers cache the external stylesheet, your pages load faster. Unless your site has a fundamentally different set of styles on its different pages, you should opt for the external stylesheet. This is definitely best practice.

Add an external stylesheet by using the link HTML attribute. This is the command I use in these pages:

<link rel="stylesheet" href="css/stylesheet.css" type="text/css" media="screen">

This tells the browser to look in the css folder to find the stylesheet.css file, and apply it to the page.

Internal Stylesheets

Internal stylesheets (sometimes called "embedded" stylesheets) are not, technically, "stylesheets," but "inline style blocks." Either way, they go in the head of the individual HTML page and control only that one page. We used that as the way to code your first page in these lessons, for the simple reason that it was easier to go back and forth within the same page to make changes than go back and forth between separate files. Internal stylings override styles from external stylesheets.

You can add an inline style block to the head of your HTML page like so:

<style type="text/css">

... add style attributes and so forth here ...

</style>

Roger Johannson explicitly recommends not using internal style blocks:

This should also be avoided, since it is best to keep HTML and CSS in separate files.

I'm not as strict about insisting on not using internal style blocks as Roger, but then again, I'm not the expert he is.

Use of CDATA in Internal Stylesheets

Sometimes you will see the CDATA character string used in the HTML code for an internal stylesheet, as such:

<style type="text/css">
   /* <![CDATA[ */

... add style attributes and so forth here ...

   /* ]]> /*
</style>

While this may be useful in XHTML documents, HTML parsers do not recognize the CDATA elements, and therefore shouldn't be used in your HTML documents. (In fact, you'll notice that the CDATA code strings are commented out with the /* */ CSS comment codes, so that HTML documents won't "see" them.)

My friend Tommy Olsson explains:

A CDATA-section is normally used for content that contains a lot of 'special' characters (like '>' and '&') that normally need to be escaped. Most browsers only support CDATA-sections for XML documents (including XHTML served as real XHTML, but not pretend-XHTML served as HTML). As far as I know, Opera is the only browser that supports CDATA-sections in HTML.

In the same forum thread, fellow Web expert Stephen Chapman notes:

That CDATA tag is commented out so that the XHTML validator sees it but the web browsers do not. ... If you are using an HTML doctype rather than trying to pretend that your page is XHTML then just remove the entire comments. If you are using real XHTML then remove the /* and */ from around each and leave the CDATA tag in place ....

Unless you decide to begin coding in XHTML, don't bother with it.

Inline Styling

Inline styling formats individual blocks of HTML. I've almost never used this, and I doubt you will very often either, though admittedly there are certain situations where you would use inline styling. (Side note: I am actually using a good bit of inline styling in these Principles pages, for one-time examples of various effects and capabilities.) Here's an example of inline styling for a paragraph:

<p style="color: blue; font-family: Arial;">

This codes that one single paragraph as displaying in blue and in the font Arial. Nothing else on the page is affected.

Inline styling overrides external and internal styles, so if you do use it, it will impose its styling on whatever else you've done with CSS for that text block.

Also notice that in inline styling, we only use quotation marks at the very beginning and the very end of the style elements. When the browser sees that second quotation mark, it interprets it as bringing the inline styling to a close.

<p style="color: "blue"; font-family: "Arial";"> wrong!

This will not work!

Note: Microsoft will tell you that programs such as Word and Publisher will "create" HTML pages formatted with CSS. They will — using thousands of lines of inline style commands, repeated over and over and over again. It's semantically disastrous, hard on the browser, creates conflicts within the page, and in general is just plain awful. And Microsoft isn't the only firm that creates these kinds of programs. Use word processors and desktop publishers to create the documents that they were designed to make, not Web pages.

Johannson also recommends against using inline styling:

This should be avoided since it mixes structure and presentation.

And Jean-Baptiste Jung says:

[T]he style attribute is bad practice, that goes completely against the CSS philosophy.

Same caveat as above: I'm not as strict about insisting on not using internal styling as those guys, but they are the experts, I am not.

XHTML 1.1 deprecates inline styling. Just so you know; since we aren't coding in XHTML, it won't affect us.

Linking Multiple External Stylesheets

It's also possible to link multiple external stylesheets to a single page. In that case, the one lowest in the page will override earlier sheets.

Importing Stylesheets

Note: There's yet another way to link stylesheets to Web pages: the @import method. I've read through and taken part in a number of discussions about this technique on the SitePoint forums, and my conclusion is, although it's certainly legitimate, there's just no reason for you to use this method of linking your stylesheet over the regular method described above. Certainly a beginning designer won't bother with it. However, I'll show you how it's done, and you can do your own research.

<style type="text/css" media="all">
   @import "style.css";
   @import "advanced.css";
</style>

This example imports two separate stylesheets, style.css and advanced.css. Sometimes designers use the @import method to hide a particular stylesheet from older browsers (which don't recognize the @import command), and to manage large numbers of stylesheets in a single block of code — sometimes a useful technique for large corporate or academic sites, for example. The drawback is that using the @import can cause your page to display, briefly, in a completely unstyled appearance — the irritating FOUC, or "flash of unstyled content" phenomenon. Primarily this happens with Internet Explorer. There's a way around this; check the linked BlueRobot page for details. Or better yet, until you have a reason to do so, don't bother with the @import command.

Jean-Baptiste Jung writes:

While it works, the @import directive is much slower than the other way to include stylesheets into a html document ... It will not make a difference on low traffic websites, but if you have the chance to own a popular website, don't waste your visitor's time using @import.

Linking Your External Stylesheet to Your HTML Page

To link your external stylesheet to your page, include this in the head of your HTML page:

<link rel="stylesheet" type="text/css" href="css/mystyles.css"
media="screen">

This assumes that you've created a css folder for your stylesheet, and you've named it mystyles.css.

The rel attribute stands for the file's relationship to the rest of the page, and the type shows that it's a text file acting as a CSS stylesheet.

Media Types

When you use an external stylesheet, you should tell the computer what kind of media devices that stylesheet will support. "Huh?" you may ask, "it supports the computer, duh ..." Well, there's more to it.

We're talking about the media attribute. It's an HTML attribute, but is associated with stylesheets.

The most common media device that is supported by a stylesheet is the desktop, laptop, or notebook computer. (So your "duh!" is somewhat validated!) In CSS-speak, that's called a "screen" device. Other devices are printers, mobile devices, projection screens, and a whole raft of assistive technologies. (The W3C site gives a complete list of the media types stylesheets support. And Ian Lloyd warns us that using some of the lesser-known media attributes in your site could prove troublesome.)

What does all of this mean in the real world?

For general purposes, you can get away with two separate stylesheet distinctions: screen and print. Like so:

<link rel="stylesheet" href="css/stylesheet.css" 
type="text/css" media="screen">

<link rel="stylesheet" href="css/printstyle.css" 
type="text/css" media="print">

That means you're going to need TWO stylesheets, one for screen displays (what you're probably using to view this site right now), and one for printing. Fortunately, the link below can help you with designing your print stylesheet. It's not as tough as you might think.

If you have a small site not particularly suitable for printing, or you're just that lazy, you can use the default setting of all:

<link rel="stylesheet" href="css/stylesheet.css" 
type="text/css" media="all">

It's not considered best practice to just omit the media attribute entirely, though some people do. Some people also bungee-jump into asphalt parking lots.

Creating "Print" Stylesheets

People will, sooner or later, print your Web page for their own use. If you don't create a print stylesheet, the browser's default will determine what the page looks like, and it usually isn't pretty. Do your users the courtesy of giving them a proper print stylesheet. They dramatically increase the usability of your site.

While there are numerous ways to format a print stylesheet, I've used these pages as my primary sources for this walkthrough:

I am amazed at the number of major web sites whose pages cannot be printed properly because the content either doesn’t fit on the page, or is cluttered with ads and menus that have no useful purpose on a printed page. — Tech-Evangelist

Of course, providing a proper print stylesheet is best practice for Web design.

Your print stylesheet works with your main stylesheet. You don't have to create an entirely new stylesheet, just make some changes to what you already have.

A good print stylesheet does the following:

Change colors to black on white.
Change the font to serif.
Change the font size (if needed).
Underline all links.
Remove non-essential images.
Remove navigation.
Remove most or all of the advertising.
Remove all JavaScript, Flash, and animated images.

Start by adding a second stylesheet declaration to your HTML page. Let's say your original stylesheet is named style.css. Now add print.css to the page:

<link rel="stylesheet" href="/css/style.css" type="text/css" 
media="screen">
<link rel="stylesheet" href="/css/print.css" type="text/css" 
media="print">

Notice that the media attribute changes, from screen to print. This tells your browser to use the first one for display on a computer monitor, and the second one for a printer. Make sure your print stylesheet is second in line behind the main stylesheet!

More about media attributes.

Now just copy your main stylesheet (style.css in our example) to a blank text file and save it as print.css. Now that you've done that, we can begin to change it around to suit your printing needs. The new print.css sheet will be much simpler and shorter than the main stylesheet.

In the new stylesheet, set your entire site's width to 100%. This will be the first command on the new sheet.

html {
   width: 100%;
}

We're going to move from pixels to points to control the size of the printed text. Pixels are used for electronic displays, but don't work well for printed output. Conversely, points don't work well for electronic displays, but work nicely for handling print sizing.

Set the body width to seven inches. That ensures that everything printed on the page will fit on a standard (8 inches wide) piece of printer paper. We're also going to set the background color to white, the color of the fonts to black, and the base size of the fonts to 12 points.

body {
   width: 7in;
   background-color: #fff;
   color: #000;
   font-size: 12pt;
   letter-spacing: normal;
}

In the width measured in inches, we're actually using points here: 7 inches equals 504 points. We could have just as easily written the CSS code this way:

 body {
   width: 504pts;
}

The conversion factor is: 1 inch = 72 points.

Some sites recommend that you have your page print in a serif font suitable for printing, say Times (for Mac and Linux users) or Times New Roman (for everyone else). Other sites warn you that having your printed site appear in a font different from the display font may surprise users. It's your call. If you want to have the font print in a print-friendly serif, add this to the body selector:

font-family: Times, "Times New Roman", serif;

The letter-spacing: normal selector returns the letter spacing to normal, if you've changed it around on your sheet. You might not need this one now, but it won't hurt and might be useful when you modify your stylesheet.

More information about fonts.

Another good thing is to ensure that your images don't have borders around them. This is another addition that may well not be necessary for your page, but it won't hurt to add it:

img {
   border: 0px;
}

Your page probably has a good number of hyperlinks. Obviously they won't work on paper, but if it's important to have them printed (for reference, etc), here's how to have them print with descriptive text and URLs (what good is a hyperlinked chunk of text without its URL for us to see?).

To have the descriptive text print:

a:link, a:visited {
   color: #520;
   background: transparent;
   font-weight: bold;
   text-decoration: underline;
}

With this CSS code, your page's hyperlinks will show up in a dark red, good enough to appear legibly in both a color and a grayscale output, with the additions of boldface and underlining to help the text of the links stand out.

Modern browsers will allow you to insert the URLs of the links after the text. It assumes that the text of your page's body is contained in a #content ID; you will, of course, need to change this to reflect your own CSS layout. (If you add it to your body selector, a URL will appear in the header upon printout, an effect you may want to avoid.)

#content a:link:after, #content a:visited:after {
   content: " (" attr(href) ") ";
   font-size: 90%;
}

Note: the spacing in the above code is very important. Don't change it around.

Now go through your stylesheet. Note any elements you don't want to print, such as headers, footers, sidebars, advertisements, search boxes, navigation menus, etc. Make sure they are all referenced by either a class or ID. If they're not, give them one, but don't style it in the main stylesheet. One good method is again from Tech-Evangelists, and recommends giving each of the unnamed elements that you don't want printed the class of .nopr — standing for "no print."

More about classes and IDs.

Now give all of these elements a single attribute: display: none.

Here's an example:

.nopr, #footer a, #header, #navbar, .soclinks, #searchbox, #sidebar {
   display: none;
}

Because of the display: none attribute and value, none of these will display when your page is formatted for printing.

If you want to prevent all elements within a table column or CSS division from displaying, simply add an asterisk. Like this:

#sidebar *

Any elements that remain (say, #content) should be coded to make sure that all of their content appears on the page — no running off the page. Add this to the selectors. We'll use #content as our example:

   width: 100%;
   margin: 0;
   float: none;

If you have elements that display in a lighter color, say a header in your sidebar that displays in white, change it so it prints in black. Here's an example:

#sidebar h2 {
   color: #000;
}

Check your page's layout for your printer, not by printing each page, but by going through your browser's Print Preview function. Make whatever tweaks are necessary.

Eric Meyer, one of the leading proponents of CSS, wrote a seminal article for A List Apart on printing your pages back in 2002. It is still an excellent reference today, and, as noted above, one I've borrowed from extensively for this section. A List Apart's Derek Featherstone gives us a much more sophisticated way of formatting our print pages. WestCiv's "Printing" is another interesting take on print stylesheets. And 37signals provides an interesting visual take on the results of their print stylesheet.

History of CSS » Best Practices HTML and CSS

2010-05-30T04:33:20Z

Shared by Max Black
designsite

Web Design Principles
History of CSS

Looking for the lessons? Get started!

Some guides to learning more about the history of CSS.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

Following the light of the sun, we left the Old World. — Christopher Columbus

Ross Shannon gives a good thumbnail history of CSS here. Want to learn more? You might be interested to read The CSS saga and Who created CSS? CSS Early History. These links will introduce you to seminal figures like Håkon Wium Lie, Pei Wei, Dave Raggett, and Bert Bos, the battle over how presentational control should be divided between user agents (browsers), designers, and end users, the Microsoft-Netscape wars, Netscape's attempt to replace CSS with JavaScript, and Microsoft's game-changing embrace of CSS in IE 5 for the Mac. Fun reads all.

CSS Crib Sheet » Best Practices HTML and CSS

2010-05-30T04:32:57Z

Shared by Max Black
designsite

Web Design Principles
CSS Crib Sheet

Looking for the lessons? Get started!

A 'cheat sheet' for CSS usage

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

No, we don't cheat. And even if we did, I'd never tell you. — Tommy Lasorda

Mezzoblue's Dave Shea gives us an extremely useful CSS Crib Sheet. I'll give you a shortened version of Shea's list below, along with some additions from Roger Johannson. Some of the tips Shea and Johannson give us may not make sense to you yet, but keep the crib sheet handy; you will refer to it again and again, and you'll eventually learn why these guys say what they're saying.

When in doubt, validate. More about validation.
Build and test your CSS in the most advanced browser available before testing in others, not after. More about browsers.
When relying on floats for layouts, make sure they clear properly. More about floats.
Margins collapse; apply padding or a border to avoid. More about margins and padding.
Try to avoid applying padding/borders and a fixed width to an element..
Avoid the Flash of Unstyled Content in IE. More about importing stylesheets.
Don't rely on min-width in IE.
When in doubt, decrease widths. More about .
Content not showing up properly in IE? Check the Peekaboo bug. More about .
Be careful when styling links if you're using anchors. More about using IDs in anchors.
Make sure your desired effect actually exists. (Shea is referring to non-standard CSS effects.)
Divide and Conquer: use commenting to turn off large sections of style. (Nifty trick for debugging stylesheets.)
Remember 'LoVe/HAte' linking. More about ordering anchors.
Remember 'TRouBLEd' borders. More about borders.
Specify units for non-zero values.
Test different font sizes. More about fonts.
With stylesheets, test embedded (internal); launch imported (external). More about external stylesheets.
Add obvious borders to help debug layouts.
Don't use single quotation marks around paths for images.
Don't link to empty stylesheets as 'placeholders' for future stylesheets (like handheld or print media style sheets).
Understand the CSS box model. More about the box model.
Use only allowed characters for class and id. More about IDs and classes.

Printable version of the CSS Crib Sheet.

Inheritance » Best Practices HTML and CSS

2010-05-30T04:26:34Z

Shared by Max Black
designsite

Web Design Principles
Inheritance

Looking for the lessons? Get started!

How "child" elements "inherit" the characteristics of their "parents."

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

We inherit nothing truly, but what our actions make us worthy of. — George Chapman

Contents of This Page

Parent-Child Relationships in CSS

One of the concepts behind the idea of the cascading stylesheet is inheritance. The top-level element of any HTML page is its body; many designers use this as a selector. When you apply an attribute to the body selector, the other, lower-level elements inherit the attribute. Like this:

body {
   color: blue;
}

With this color: blue; attribute and value assigned to everything within the body selector, all the text in your site will appear in blue. This is because of CSS inheritance.

However, if you add the same attribute, and a different value, to a child element such as an h1, that particular element will appear differently.

Like this:

h1 {
   color: red;
}

In this case, every text element within the body element except the h1 element will appear in blue. The h1 element will appear in red. This is a further example of inheritance.

Inline elements such as the HTML tag em can also be styled. Normally, this line of code would only make the emphasized word appear in italics, while the previous styling (the red color) would remain:

<h1> some <em>emphasized</em> text</h1>

However, you can add styling to the particular HTML element that, because of inheritance, would override the earlier red coloring:

em {
   color: green;
}

Now, the h1 would still appear in blue, except for the em, which is now styled to appear in green.

Parent-Child Relationships in CSS

The idea of "parent-child" relationships in CSS grows directly from the concept of inheritance.

Just as a child inherits eye color and other traits from a parent, a "child" element will inherit styling from a "parent" element.

Try to get used to reading about "parent" and "child" elements in CSS, as it's a commonly used metaphor.

Child elements are contained by parent elements. Therefore, they inherit their properties.

Let's say you have a parent div and a child p within that div.

Your HTML might look something like this:

<div class="foo">
   <p>Stuff.</p>
</div>

In your stylesheet, you might decide that everything in that div needs to be red. So here's your CSS:

.foo {
   color: #ff0000;
}

Adding that style to your stylesheet means that the paragraph contained inside the "foo" div will be red, without your needing to add the color: #ff0000; selector to that paragraph.

When you find yourself griping, "I made one single change to my stylesheet and now everything looks different!", a basic grasp of the "parent-child" concept will often rescue you.

CSS Selectors, Attributes, and Values » Best Practices HTML and CSS

2010-05-30T04:18:17Z

Shared by Max Black
designsite

Web Design Principles
CSS Selectors, Attributes, and Values

Looking for the lessons? Get started!

The functions of CSS selectors, attributes, and values.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

But one of the attributes of love, like art, is to bring harmony and order out of chaos, to introduce meaning and affect where before there was none, to give rhythmic variations, highs and lows to a landscape that was previously flat. — Molly Haskell

Contents of This Page

You should know the proper terminology for the different parts of your stylesheet. Of all places, the Microsoft Web site gives us some invaluable assistance in learning the proper names of different CSS components. The page is old and hasn't been updated in a long while, but the information itself is solid. Two more up-to-date references are Ian Lloyd's Build Your Own Web Site The Right Way Using HTML & CSS, and Rachel Andrew's The CSS Anthology: 101 Essential Tips, Tricks & Hacks.

CSS elements can be broken down by rule, selector, declaration, property, and value.

This is an entire rule (sometimes called a style declaration):

p {
   font-size: 10px;
}

A selector is the HTML tag being styled:

The declaration (sometimes called a declaration block) is the portion of the CSS rule within the curly brackets:

{
   font-size: 10px;
}

The property (sometimes called the attribute) is the particular element that is applied to a selector:

font-size

The value is the, well, value assigned to a particular property:

10px;

Let's say we have this hypothetical command inside your stylesheet:

body {
   font-size: 0.8em;
   color: #ff0000;
}

Tizag.com writes:

"Property" is the CSS element you wish to manipulate and "value" represents the value of the specified property. The selector name creates a direct relationship with the HTML tag you want to edit.

What does that mean? Well, in our example above, the body tag (the selector) is manipulated — modified — by two properties that change the font size and the color of everything in the body.

We use these terms in these pages.

Note: Some designers write their CSS code all on one line, like this:

body {font-size: 0.8em; color: #ff0000; }

There's nothing wrong with this.

Selector Types

There are several types of selectors commonly in use.

Type Selectors

Basically, a "type selector" styles every instance of a particular HTML element appearing in the site. For instance:

a {
   color: #ff0000;
}

has every single a element (essentially, every link) in your site appearing in bright red. Andrew writes: "Type selectors are often used to set the basic styles that will appear throughout a web site." Easy enough, though using type selectors paints with a relatively broad brush.

Class Selectors

As noted, type selectors style every instance of a particular element. Maybe you don't want that. Let's say you have a section of your page where you want your links (the a elements) to appear in a stylish, muted gray instead of that firehouse red you've chosen for other parts of your site. Easy enough, you assign a class.

More about classes and IDs.

We create the following class in our stylesheet:

.subtlelink {
   color: #808080;
}

Now, when we assign that class to a link in our HTML code:

<a href="http://www.yahoo.com" title="Yahoo" class="subtlelink">Yahoo</a>

those links, and only those links, will appear in a nice, subtle gray.

Note: Actually, they will only if you put the .subtlelink below (after) the original red-styled links in your stylesheet. Specificity comes into play here. You'll find out more about specificity later on this page.

ID Selectors

Those of us who know these things know that classes and IDs work much alike.

More about classes and IDs.

However, an ID can only appear once on a page, so they are usually used for one particular element on a page.

#navigation a {
   color: #808080;
}

gives us those gray links only inside an HTML element designated as "navigation":

<div class="navigation">
   <p><a href="http://www.yahoo.com" title="Yahoo">Yahoo</a></p>
</div>

We can combine ID and class selectors:

#navigation .subtlelink {
   color: #808080;
}

like so:

<div id="navigation">
   <p><a href="http://www.yahoo.com" title="Yahoo" class="subtlelink">Yahoo</a></p>
</div>

Descendant Selectors

Basically, this means that if you include more than one element inside a styled class (such as our given "subtlelink") or ID, everything gets styled.

In other words, this:

#navigation a {
   color: #808080;
}

styles all of these links:

<div id="navigation">
   <p><a href="http://www.yahoo.com" title="Yahoo">Yahoo</a></p>
   <p><a href="http://www.google.com" title="Google">Google</a></p>
   <p><a href="http://www.altavista.com" title="Alta Vista">Alta Vista</a></p>
</div>

A descendant selector is made up of a list of selectors, separated by spaces (very important!) that matches a page element or group of elements from the outside in. In our example, our page contains a div that has the ID of navigation. As a result, #navigation a refers to all of the a elements inside the #navigation div.

Confused yet? I wrote that (under the guidance of Andrew's excellent book) and I'm confused! Trust me, this works.

Child Selectors

Lastly, we have child selectors, which refers to the concept of inheritance.

More about inheritance.

Andrew defines child selectors thusly: "The descendant selector matches all elements that are descendants of the parent element, including elements that are not direct descendants."

Say what? Let's look at an example.

Let's use some fresh faux CSS classes, "leftside" and "standout". The "leftside" class will indicate material that will, we trust, appear on the left side of our site, and the "standout" class will apply to text that we want to stand out. And, so I don't have to type so much, let's switch from anchor links to paragraphs in our HTML examples.

...more to come...

Grouping Selectors

Selectors can be grouped together, as long as you separate them with a comma and a space. Instead of:

h1 {
   font-family: Arial, sans-serif;
   color: #fff;
}

h2 {
   font-family: Arial, sans-serif;
   color: #fff;
}

h3 {
   font-family: Arial, sans-serif;
   color: #fff;
}

it's much cleaner and easier to maintain to do this:

h1, h2, h3 {
   font-family: Arial, sans-serif;
   color: #fff;
}

You can also differentiate between your elements, setting different rules for specific elements after setting a rule for a group. In other words, you can do this:

h1, h2, h3 {
   font-family: Arial, sans-serif;
   color: #fff;
}

h1 {
   font-size: 1.5em;
}

In this example, your h1 element will be displayed in Arial, in white (#fff), and in a 1.5em size. Note: For this to work, the standalone h1 coding must be after the group coding.

Lloyd tells us:

You can think of the commas in CSS selectors (like the one above) as the word "or."

Declarations can also be grouped. In some stylesheets, you will see something like the following:

h1 {
   font-weight: bold;
}

h1 {   
   font-size: 10px;
}

h1 {
   line-height: 12px;
}

h1 {
   font-family: Georgia, serif;
}

Incredibly long-winded. Just combine them, separating each selector with a semicolon:

h1 {
   font-weight: bold; 
   font-size: 10px;
   line-height: 12px;
   font-family: Georgia, serif;
}

Contextual Selectors

You can classify individual selectors according to their context — in other words, according to the element you wish them to style. Generally, they override the styling you've added to (for example) your body element, or the browser's own defaults.

Following Ian Lloyd's lead, I think we can get a pretty good grasp of what this means.

Let's say you want to create a class called "highlight." You want it to show its text in italics, and in a different font from the rest of the text.

More about styling your fonts.

You're only going to use it on certain paragraphs. So you create a contextual selector:

.highlight p {
   font-style: italic;
   font-family: Georgia, "Times New Roman", serif;
}

By wrapping a paragraph, or a group of paragraphs, in a div with the highlight class, you can have those paragraphs appear in your styling:

<div class="highlight">
   <p>This text is italicized and displays in Georgia.</p>
</div>

More about the DIV and SPAN elements.

That will work great on the designated paragraphs, and other paragraphs will keep the original styling.

However, this will not work:

<p class="highlight">This text is supposed to appear in italics and Georgia, but it will not.</p>

Why not? Because your highlight p CSS command already names a p in its selector. By designating a paragraph (a second p) as containing the class "highlight", you give the browser one too many paragraphs to search for. Your "highlight"-styled paragraph won't display properly.

Contextual selectors work with more than paragraphs. Let's say you have a link inside your navigational scheme, which you have sensibly ID'd as "navigation." By creating the following in your stylesheet:

#navigation a {
   text-decoration: none;
   color: #ff0000;
}

you've ensured that all the links inside this scheme will have no underline, and will be red in color:

<div id="navigation">
   <p><a href="links.html" title="Links">Links</a></p>
   <p><a href="contact.html" title="Contact Me">Contact Me</a></p>
</div>

Let's say you want to ensure that all the paragraphs in your footer (which you've ID'd as "footer") have their lines spaced at 150% of the normal line spacing. By creating the following in your stylesheet:

#footer p {
   line-height: 150%;
}

you ensure that everything in your footer is so spaced:

<div id="footer">
   <p>Footer text.</p>
</div>

while your other paragraphs enjoy the original spacing.

I cribbed those two examples directly from Lloyd's book; he provides several more that serve to thoroughly illustrate the concept.

Cascading Order

We've discussed the "style" aspect of CSS, but we have not mentioned the "cascading" aspect. Basically, this comes into play when one element is superseded by another in the stylesheet, or when two elements contradict one another. There must be some way for one element to "win out". The simplest (and therefore the least accurate) way to view this is "last one in wins." In other words, the last selector to be cited overrides earlier mentions.

Web designer Craig Grannell explains it a bit differently:

The value closest to the element in question is the one that is applied.

Well, that's confusing. Let's see an example. Let's say you make your h2 green:

h2 {
   color: #008000;
}

but farther down in your stylesheet, you forget what you did earlier, and again style your h2, this time in stunning purple:

h2 {
   color: #800080;
}

All of your h2 text will appear in purple. The purple, appearing later in the stylesheet, overrides the green.

A more complete list of "CSS overrides," or "cascades," can be found in the WDG HTML Help pages. I've simplified their list for you:

!important. The !important property wins out over everything, and as a result is often misused. Use this powerful property wisely and with restraint. More about the !important property can be found here.
Specificity. The "specificity" rule is quite confusing, and is explained more thoroughly here. Basically, the higher a rule's specificity, the more "weight" it carries in the stylesheet, and will "win out" over a less "weighty" rule.
Last rule specified wins. As described above. Both the !important property and "specificity" win out over "last one in wins."

It's also worth noting that when you import (or link) multiple stylesheets, say a print stylesheet, the cascade principle applies here, also. Anything in the second (or third, or fourth) stylesheet override the properties in the first.

More about print stylesheets.

Using Lower Case in CSS

It's not a hard-and-fast rule that you should use all lower case letters in typing your CSS, but, well, you should. It's best practices for a number of reasons, mostly consistency, and because if you ever find yourself writing XHTML, you'll have to use lower case letters. So why not use it from the outset? Also, CSS classes and IDs are case-sensitive: in other words, this class:

.typeset

is different from this one:

.typeSet

You can imagine the confusion that could ensue once you start going down that road. Unless you can keep all of those upper- and lower-case class and IDs straight, just use lower case letters in all of your CSS. You'll be glad you did.

CSS Definition and Characteristics » Best Practices HTML and CSS

2010-05-30T04:10:42Z

Shared by Max Black
designsite

Web Design Principles
CSS: Definition and Characteristics

Looking for the lessons? Get started!

The definition and characteristics of CSS.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

You affect the world by what you browse. — Tim Berners-Lee

Contents of This Page

CSS stands for "Cascading Style Sheet." Like many, I write the word as "stylesheet" (one word, not two). I won't get into the semantics of "stylesheet" vs. "style sheet." You will see both in your travels around the Web.

According to a definition written by Maxine Sherrin and John Allsopp of Westciv:

A stylesheet is a set of instructions each of which tells a browser how to draw a particular element on a page. It's very important to grasp this idea of HTML elements when you are working with CSS.

Web specialist Craig Grannell gives a longer take:

CSS is the W3C standard for defining the visual presentation for web pages. HTML was designed as a structural markup language, but the demands of users and designers encouraged browser manufacturers to support and develop presentation-oriented tags. These tags "polluted" HTML, pushing the language toward one of decorative style rather than logical structure. Its increasing complexity made life hard for web designers, and source code began to balloon for even basic presentation-oriented tasks. Along with creating needlessly large HTML files, things like font tags created web pages that weren't consistent across browsers and platforms, and styles had to be applied to individual elements — a time-consuming process.

The concept behind CSS was simple, yet revolutionary: remove the presentation and separate design from content. Let HTML (and later XHTML) deal with structure, and use a separate CSS document for the application of visual presentation.

And author and Web designer Rachel Andrew writes:

The basic purpose of CSS is to allow the designer to define style declarations (formatting details such as fonts, element sizes, and colors), and to apply those styles to selected portions of HTML pages using selectors — references to an element or group of elements to which the style is applied.

Think about driving through a particular neighborhood. If all the homes were built by the same developer, you might see the same three or four house styles repeated over and over again. But each one has differences — different color schemes, different landscaping, shutters on the windows or a lack thereof, different kinds of roof shingling, bay windows or casement windows, myriad other differences. Think of the fundamental house structures as the HTML of a site, and the different stylings and "decorations" as the CSS. (Actually, this isn't a great analogy — CSS can control much of a site's structure, and it adds a lot more to a site's final appearance and function than a paint job or a set of oak shutters does to a house. But it's a bad starting point.)

Someone very knowledgeable wrote about CSS for Wikipedia. Roger Johannson of 456 Berea Street wrote a more in-depth article on the subject. Using their articles, and Andrew's book The CSS Anthology, as guides for the content on this page, I can start by telling you that CSS describes the presentation semantics, or the look and formatting, of a Web page.

Looking Backward to Move Forward

Sometimes it's helpful to look backwards before we move forward. Here's an example of Then vs. Now, cribbed from Wendy Peck's Bare Bones, No Crap, CSS Text Control Primer. (I love it for the title alone.)

The Old Broke-Down Fogey Way of Controlling Presentation:

<p><font color="#ff0000" size="2" face="Verdana, Arial, Helvetica, sans-serif">Text ready for control.</font>

Yes, your browser will read this and style the paragraph appropriately. So what's the problem?

Imagine having a dozen, or a hundred, such paragraphs on your page. Every one needs styling — some differently than others. When you make a change to one, you need to comb through the page, making the same change a dozen or a hundred times — and when you're finished, you get to go through the process again on the next page in the site. And the next.

The New Hotness Way of Controlling Presentation (if by "new" you mean "since around 1998")

The CSS
p {
   font-family: Verdana, Arial, Helvetica, sans-serif;
   font-size: 12px;
   color: #ff0000;
}

The HTML
<p>Simple content text ready for control.</p>

Want to change the color of your dozens of paragraphs from #ff0000 to something else, say a nice light blue: #f0f8ff? Easy, just change one line of CSS:

color: #f0f8ff;

Changes done, go have a cup of coffee. Peck observes:

No matter how fancy CSS may get, this is the basic principle. The real power, other than reducing the amount of code in each page dramatically, is the ability to change your mind because the control for the text and the text are in totally different places.

Separating Content and Structure from Presentation

The biggest reason why we have two separate entities — HTML and CSS — is to separate document structure and content from its presentation.

Johannson writes:

Structure consists of the mandatory parts of an HTML document plus the semantic and structured markup of its contents. Presentation is the style you give the content. In most cases presentation is about the way a document looks, but it can also affect how a document sounds — not everybody uses a graphical web browser. Separate structure from presentation as much as possible. Ideally you should end up with an HTML document which contains the structure and content, and a separate CSS file which contains everything that controls presentation. ... When an HTML element exists that has a structural meaning suitable for the part of the content that is being marked up, there is no reason to use anything else. In other words, do not use CSS to make an HTML element look like another HTML element, for instance by using a span element instead of an h1 element to mark up a heading. By using semantic HTML, you will make the different parts of a document meaningful to any web browser, be it the very latest graphical web browsers on a modern PC, an old web browser that doesn’t handle CSS, a text-based browser in a Unix shell, or assistive technology used by people with disabilities.

Wikipedia notes:

This separation can improve content accessibility, provide more flexibility and control in the specification of presentation characteristics, enable multiple pages to share formatting, and reduce complexity and repetition in the structural content ...

Later in his document, Johannson notes quite accurately that for CSS to properly control the stylings and presentation of an HTML document, the HTML must be semantically accurate and well-formed. One cannot hide or override the flaws of the other.

CSS Instead of Tables

One of the primary functions of CSS is to control the layout of a Web page. (My stylesheet for this site controls this page's three-column, header/footer layout, for example.) A lot of very good, and very capable, designers still use tables for laying out their sites. There are dozens of reasons why this is no longer viable in a modern, best practices-driven Web design world (one design firm, Chromatic, lays out 13 very good reasons, in some detail), but trust me, table-driven layouts are over and done with. When someone who seems knowledgeable about Web design advocates tables over CSS to you, ask them why they're not running Windows 3.1 instead of their WinXP or Win7 on their computers — or why they're not using an Apple Lisa instead of a Mac OSX.

Browser Support for CSS

Not all browsers support CSS's most modern accepted form, CSS 2.1, completely. (CSS 3 is in development, and us design folks are all giddy about it, but it will be years before a majority of browsers implement its elements properly, so for now, let's stick with CSS 2.1. That's quite enough to deal with!)

As noted above, different browsers manage CSS (and HTML) with varying degrees of accuracy. None of them get it right 100% of the time, but some come very close. Browsers actually come in families, and the families each have their own strengths and weaknesses.

The Gecko Family: Includes Firefox, Camino, Flock, SeaMonkey, etc. Very, very good at handling CSS.
Presto: Opera is the only browser in this family. Also very strong at handling CSS.
The Webkit Family: Mac's Safari and Google's Chrome, along with OmniWeb, Shiira, iCab, and others are Webkit browsers, and all handle CSS quite well.
The Trident Family: Internet Explorer (the big dog in the yard), Maxthon, Sleipnir, NeoPlanet, and a few other browsers comprise this family of browsers. There's always one dysfunctional crowd in the neighborhood, and this one is it. Microsoft claims that IE8 fully supports CSS 2.1. It doesn't, though it's much better than IE7, and light-years ahead of its predecessor, the almost hatefully deficient IE6. As for IE9, we'll see in 2011.

Because a majority of the world's computer users surf the Web with some version of Internet Explorer, you have to design with IE's flaws and bugs in mind. There is an entire cottage industry of designers who have documented and attempted to find fixes or "hacks" for a plethora of IE bugs. Sooner or later, you will find yourself making use of their work.

Some designers get snippy about supporting IE6 and other superseded, "obsolete" browsers. "Those people need to get with the new millennium," they snap. "I would no more design for IE6 than I would build a car that burns leaded gasoline." That's their prerogative, but to my mind it's exclusionary and wrong. Hundreds of thousands of Web users (at the least) rely on IE6 for their Internet needs, whether by choice (informed or not) or by necessity. To lock them out of your Web site because you think their browser is not serving the needs of your users.

Roger Johannson agrees, while acknowledging the limitations of designing for IE and other less functional browsers. He observes:

It's important to stress that people using old (obsolete) browsers and browsers that by design do not support CSS must not be locked out. In the nineties, browser sniffing was a popular way of redirecting people using the 'wrong' browser (normally anything but Internet Explorer for Windows) to a page that told them to upgrade their browser to gain access to the site. These days you can handle unsupported browsers in a better way. One big advantage of using logical, semantic HTML is that it makes documents accessible and usable even without CSS. The presentation — the way the document looks — won't be the same as in a supported browser, but the content will be there. In most cases, for most visitors to a site, the content is actually more important than the way it is presented. That's why it is better to send an unstyled page to unsupported browsers than to lock them out of the site.

Sending your less up-to-date users to an unstyled version of your site is a drastic solution, but sometimes necessary. More often, we can have the design "degrade," presenting a less sophisticated version of our styling and presentation for the less capable browsers without losing functionality, elegance, or appeal.

Validating Your Code » Best Practices HTML and CSS

2010-05-30T04:10:08Z

Shared by Max Black
designsite

Web Design Principles
Validating Your Code

Looking for the lessons? Get started!

How to validate your code, and why you should.

The entire Web Design Principles section can be accessed through the menu below.

Principles Links

These technologies, which we call "web standards," are carefully designed to deliver the greatest benefits to the greatest number of web users while ensuring the long-term viability of any document published on the Web. — Web Standards Group

Even the most proficient Web designers sometimes fail to validate their documents — checking a Web document against the existing, DOCTYPE-specific technical specifications. This is always a mistake. HTML and CSS validation does not guarantee perfect Web documents, and some truly heinous Web sites can be designed that are completely valid. However, there are compelling reasons why you should make every effort to learn HTML- and CSS-valid standards, and comply with them. It's best practice.

Validating your Web page won't guarantee that it will appear just the way you want it. It only ensures that your code is free of syntax errors. As Roger Johannson writes:

Note that "works in any web browser" does not mean "looks the same in every web browser." Making a document look identical across browsers and platforms is next to impossible. Not even using only images will make a website look exactly the same everywhere. Documents that are published on the web will be accessed by a wide variety of browsing devices on several operating systems, with monitors of differing size and quality (or no monitor at all), by users who may have changed their browser's default text size and other preferences. Realising this and accepting that you simply cannot fully control the visual appearance of a website in your visitors' browsers will make your life a lot less frustrating. Anyone who creates websites needs to understand that there are technical prerequisites to consider, the same way as those who publish on paper or make movies or television have other prerequisites to consider.

Having said that, let's look at some reasons why you should validate your designs. (Much of the following information is sourced from an article by Nick Kew and provided to the World Wide Web Consortium, , a classic 2003 article from Mark Pilgrim, the Roger Johannson article cited above, and from Opera's Web Standards Curriculum set of hands-on tutorials.)

Validation Helps You Find Errors

This may sound like a "duh" statement, but often designers like you (and me) sit and stare at dysfunctional Web pages for minutes, hours, or even days trying and failing to find an error that is breaking your site. Validation can often find those small, hard-to-spot errors almost instantly. Pilgrim writes: "[T]he validator is an automated tool that can highlight small but important errors that are difficult to track down by hand, and may actually solve the problem that's driven you crazy. If you create valid markup most of the time, you can take advantage of this automation to catch your occasional mistakes. But if your markup is nowhere near valid, you'll be flying blind when something goes wrong. The validator will spit out dozens or even hundreds of errors on your page, and finding the one that is actually causing your problem will be like finding a needle in a haystack." As you learn to write valid code, you will make fewer errors, and the validator will actually be more useful in finding the few mistakes that have crept into your code.

Ensuring Pages Display as Identically as Possible across Different Browsers

While most modern browsers manage to sort out a lot of error-riddled HTML pages, the errors are not always caught and handled gracefully. Worse, different browsers don't handle errors the same way, resulting in differences in style, appearance, layout, and/or even function. Kew writes:

"Using standard, interoperable markup and stylesheets, on the other hand, offers a much greater chance of having one's page handled consistently across platforms and user-agents. Indeed, most developers creating rich Web applications know that reliable scripting needs the document to be parsed by [browsers] without any unexpected error, and will make sure that their markup and CSS is validated before creating a rich interactive layer. When surveyed, a large majority of Web professionals will state that validation errors is the first thing they will check whenever they run into a Web styling or scripting bug."

Faster Downloading and Rendering of Your Pages

Not only does CSS make HTML pages smaller, leaner, and more efficient, thereby speeding their download time, clean and valid code ensures that the browsers are not slowed by quirky, erratic, or broken code.

Better Accessibility

Disabled users employing screen readers and other "assistive technologies" will be far better served by clean, standards-compliant HTML and CSS.

Opera's Chris Mills writes:

[O]ne of the big issues on the Web is making web sites accessible to everyone, no matter who they are, regardless of circumstance. This includes making web sites usable by people with disabilities such as blindness/visual impairment and motor impairment (ie, people who have restricted movement, and might not be able to use their hands properly, or at all). By using web standards and best practices, you’ll be able to make your web sites usable by this significant group of the web audience with no extra effort.

Coding for the Future

Creating error-free, standards-valid HTML and CSS is the best guarantee that your Web pages remain consistent, accurate, and functional as possible as time wears on, browsers update, and standards change. W3C tells us, "Validation is one of the simplest ways to check whether a page is built in accordance with Web standards, and provides one of the most reliable guarantee that future Web platforms will handle it as designed."

Teaching Best Practices

As noted above, writing valid, standards-compliant code is best practice for Web design. It also teaches and encourages best practices for Web design. While many veterans have learned to create error-free code and make relatively few validation errors, most beginners make more errors. Computer validation checks can help beginners learn from their mistakes.

Increasing Your Search Engine Ranking

Web designer and marketer Christine Churchill notes, "Bad HTML can hurt your site in the search engines without you ever realizing it. ... While [modern ] browsers are very forgiving of your HTML errors, search engine spiders aren't nearly as kind. It helps to think of a search engine spider as a web browser — just like a browser, the spider needs to interpret your page and figure out what you're saying. Only then can it properly index your page. Search engine spiders also care about the structure of your Web page because they give extra weight to keywords placed inside certain HTML tags." She notes that most beginners will almost certainly find validating their sites frustrating, tedious, and even pointless. But as the beginner improves his/her skills, the number of errors will decrease, the site design will improve, and the frustration will decrease. Johannson agrees: "The separation of content and presentation makes the content represent a larger part of the total file size. Combined with semantic markup this generally improves search engine rankings."

Search strategist and online marketing expert Joost de Valk agrees that designing to Web standards helps optimize sites for search engines. You might take a close look at de Valk's article to see how he reorganized his site structure to make it more user- and SEO-friendly. He concludes:

A good site structure is a requirement for Search Engine Optimization. It allows both your users and search engines to find content within your site more easily. A good structure is well categorized, and pages within it only link to other pages on the same topic.

De Valk also writes a useful article on POSH, or "Plain Old Semantic HTML", a popular paradigm of standards-based practices. If you follow Web standards and best practices as delineated in this site, you're pretty much following POSH standards as well.

Simpler Adaptation

Coding to Web standards helps ensure that your sites work not only with different operating systems (Windows, Mac, Linux), but with alternative browsing systems, including mobile phones, televisions, PDAs, gaming consoles, and iPads. While these devices often have limitations such as screen size, processing power, and others, if you adhere to current standards, you can be all but certain that your site will work on all of these devices. Mills reminds designers: "There are more mobile phones in the world than PCs, a lot of which are Internet-capable, so can you or your clients afford to miss out on this market?"

Ensuring Others are Willing to Help You Fix Your Problem

I learned to code by trial and error, and by frequently shouting for assistance on the SitePoint forums. One reason why I've stayed with SitePoint for years is their acceptance of me as (then) a newbie Web designer (and now a journeyman designer who still asks "duh" questions), and their willingness to walk me through my mistakes. But more than once they advised me to validate my code and come back. They were far nicer about it than most people are willing to be. Pilgrim points this out in his essay: typically, the new designers creates a "Help!" post on some design forum, and is told, "Validate your code and then come back if you need help." Sometimes the questioners come back, often they do not. If you validate your code, fix the errors you know how to fix, and then shout for help on an expert forum, you're far more likely to get the assistance you need.

A Sign of Professionalism

Creating valid, error-free Web sites is a strong sign that the designer adheres to professional standards. Kew writes: "Seasoned, able professionals will take pride in creating Web content using semantic and well-formed markup, separation of style and content, etc. Validation can then be used as a quick check to determine whether the code is the clean work of a seasoned HTML author, or quickly hacked-together tag soup."

Why Don't Big Corporate Sites Pass Validation?

In June 2008, Web entrepeneur Jonathan Lane noted that the Web sites of 35 (out of 40) Fortune 500 companies failed validation. One of the most spectacular failures was of Amazon's Web site; other validation failures were registered for Microsoft.com, Google.com, Apple.com, Yahoo.com, MySpace.com, and many other Web behemoths. Take a look at Jonathan's chart below, which shows the breakdown among valid and invalid corporate sites. (This graph is from mid-2008, so I'm sure things have changed somewhat since then. But I doubt that much...)

(Image from Jonathan Lane's article cited above, used under the Creative Commons free distribution license.)

There are any number of reasons why large, expansive (and undoubtedly expensive) Web sites for such firms. Lane speculates that Amazon's 1500 validation errors (including the lack of a DOCTYPE!) comes from a failure to upgrade their site management system. Other, less flagrantly invalid corporate sites may be from inattention, a failure of their content management systems to produce valid code, lack of willingness to create standards-compliant code, ignorance, or laziness. Or all of the above.

Summing Up

My friend Tommy Olsson sums it up nicely:

Why should we spell-check our text before publishing it on the web? Because mistakes and errors can confuse readers and detract from the important information. The same can be said for markup. Invalid markup can confuse browsers, search engines and other user agents. The result can be improper rendering, dysfunctional pages, pages that remain unindexed by the search engines, program crashes or the end of the universe as we know it! If our page doesn't display the way we intended, we should always validate our markup before we start looking for other problems ... With invalid markup, there are no guarantees.

On the other hand, Jukka Korpela gives us a useful caveat:

Validation is about catching some syntax errors, nothing more. It is useful only if you know the syntax rules so that you can see what's wrong. Validation does not do anything that you would not be able to do on your own. Validation is useful because you, being presumably human, are not particularly good at following formal rules or checking that they are obeyed. Thus, a validator does not teach you how to write HTML. It just points out mistakes. You are supposed to learn HTML from other sources.

Korpela provides an interesting and useful essay on the limitations of validating your HTML and CSS, and the misunderstandings many people bring to the concept of validation.

In that same vein, a poster on the Pilgrim article writes: "There is a problem though, at a certain level of knowledge, that you need a little help to understand what validation is and how to use a validator. I had a real steep learning curve when I started doing web standards stuff, and frankly I got a bit peeved at RTFM type comments. Sometimes you don't have quite enough knowledge to know WHY that part of the manual is of use to you." He is absolutely right. Validators can be confusing and frustrating for beginners to use.

The Wikipedia article on the popular W3C validation service (see below), based in part on the seminal book HTML, XHTML & CSS by Elisabeth Castro, notes: "All mark-up validators suffer from an inability to see the 'big picture' on a web page. However they excel at picking up missed closing tags and other technicalities. This does not mean that the page will display as the author intended in all browsers. Even if validated, all web pages should be tested in as many different browsers as possible to ensure that the limitations of the validator are compensated for and that the page works correctly."

Using the W3C Validator

Probably the best overall way to validate your markup is to use the free W3 Validator, as noted above.

(There are other good validators out there, but the W3 Validator is the "gold standard" for HTML and CSS validation.) It can be a bit confusing to the beginner, but practice will give you a good grasp of how to fix the errors the validator finds. Olsson reminds us, "Don't forget to include a DOCTYPE declaration, so the validator knows against which standards it should check your document." Olsson and many others recommend HTML Tidy as a good (and free) program to help you tidy up sloppy or invalid code. Firefox users can download and install the HTML Validator, an add-on based on HTML Tidy, to facilitate validation from within the browser. Opera users can just right-click a page and validate it (via a link to the W3 Validator) from a menu option.

Max Black's shared items in Google Reader

Monitor Display Sizes » Best Practices HTML and CSS

Web Design PrinciplesMonitor Display Sizes

Looking for the lessons? Get started!

Accessibility » Best Practices HTML and CSS

Web Design PrinciplesAccessibility

Looking for the lessons? Get started!

The 'Design' of Web Design » Best Practices HTML and CSS Lessons

Web Design PrinciplesThe 'Design' of Web Design

Looking for the lessons? Get started!

The Design of Web Design

Commenting in CSS » Best Practices HTML and CSS

Web Design PrinciplesCommenting in CSS

Looking for the lessons? Get started!

Color » Best Practices HTML and CSS

Web Design PrinciplesColor

Looking for the lessons? Get started!

The 16 Named Colors:

Hexadecimal Color Values:

Units of Measuring Size » Best Practices HTML and CSS

Web Design PrinciplesUnits of Measuring Size

Looking for the lessons? Get started!

Page Layouts » Best Practices HTML and CSS

Web Design PrinciplesPage Layouts

Looking for the lessons? Get started!

Positioning Elements » Best Practices HTML and CSS

Web Design PrinciplesPositioning Elements

Looking for the lessons? Get started!

Classes and IDs » Best Practices HTML and CSS

Web Design PrinciplesClasses and IDs

Looking for the lessons? Get started!

The Wonderful World of Fonts » Best Practices HTML and CSS

Web Design PrinciplesThe Wonderful World of Fonts and Typography

Looking for the lessons? Get started!

Block and Inline Elements » Best Practices HTML and CSS

Web Design PrinciplesBlock and Inline Elements

Looking for the lessons? Get started!

Borders » Best Practices HTML and CSS

Web Design PrinciplesBorders

Looking for the lessons? Get started!

Margins and Padding » Best Practices HTML and CSS

Web Design PrinciplesMargins and Padding

Looking for the lessons? Get started!

Different Kinds of Stylesheets » Best Practices HTML and CSS

Web Design PrinciplesTypes of Stylesheets

Looking for the lessons? Get started!

History of CSS » Best Practices HTML and CSS

Web Design PrinciplesHistory of CSS

Looking for the lessons? Get started!

CSS Crib Sheet » Best Practices HTML and CSS

Web Design PrinciplesCSS Crib Sheet

Looking for the lessons? Get started!

Inheritance » Best Practices HTML and CSS

Web Design PrinciplesInheritance

Looking for the lessons? Get started!

CSS Selectors, Attributes, and Values » Best Practices HTML and CSS

Web Design PrinciplesCSS Selectors, Attributes, and Values

Looking for the lessons? Get started!

CSS Definition and Characteristics » Best Practices HTML and CSS

Web Design PrinciplesCSS: Definition and Characteristics

Looking for the lessons? Get started!

Validating Your Code » Best Practices HTML and CSS

Web Design PrinciplesValidating Your Code

Looking for the lessons? Get started!

Web Design Principles
Monitor Display Sizes

Web Design Principles
Accessibility

Web Design Principles
The 'Design' of Web Design

Web Design Principles
Commenting in CSS

Web Design Principles
Color

Web Design Principles
Units of Measuring Size

Web Design Principles
Page Layouts

Web Design Principles
Positioning Elements

Web Design Principles
Classes and IDs

Web Design Principles
The Wonderful World of Fonts and Typography

Web Design Principles
Block and Inline Elements

Web Design Principles
Borders

Web Design Principles
Margins and Padding

Web Design Principles
Types of Stylesheets

Web Design Principles
History of CSS

Web Design Principles
CSS Crib Sheet

Web Design Principles
Inheritance

Web Design Principles
CSS Selectors, Attributes, and Values

Web Design Principles
CSS: Definition and Characteristics

Web Design Principles
Validating Your Code