Location: Home » Tips

Tips

1. HTML elements are your friend - pick a good one

That statement says a lot, and you may not even realize it. HTML has dozens of meaningful elements pre-defined for you. Among the most common: h1, h2, h3, p, ul and li. If your code has none of those, or has an abundance of div and span elements, you're doing something VERY, VERY wrong.

It may not be "wrong" in a strict "validation" sense, but its wrong for lots of good development reasons. That is, you can probably get your page to validate using lots of divs and spans, but it is probably not the best way to develop your pages. There's lots of reasons for this:

  1. No one wants to re-invent the wheel. If your content is paragraphs or lists, why should you recreate paragraph/list behavior using generic elements?
  2. Search engines understand meaningful elements and will ascribe that meaning to the content. For example, using a h1 element will usually correspond to a search engine giving the short phrase a lot of weight.
  3. In order to give meaning to divs, you must, often in repetition, apply classes. This creates more work and increases the size of your documents. A good use of HTML elements and CSS selectors will let you more specifically TARGET elements without necessarily needing a class.
  4. When maintaining both your HTML and your CSS, getting particular meaning from lots of divs is more difficult than recognizing a series of simple, descriptive HTML elements. For example, <div class="content">...</div> is more to process than <p>...</p>.

Don't get me wrong, div has its place. Most often people will cite a good use of div when it's used for structure. A page structure is simply its skeleton. In and of itself, the structure is not content, but rather is used to encapsulate the content. For example, the header across the top (in publishing terms the masthead) which contains both logo (h1), slogan (h2) and some initial navigation (ul/li), might be wrapped in a generic container (div). Likewise, your content (often h3/p) might be wrapped by a generic container (div) in order to be able to group it.

No simple tip can teach you ALL there is to know about structure and content. If you remember one thing, remember: if I have lots of divs, I've probably done something wrong.

Finally, a common reason people wrongfully shy away from meaningful elements is because they have default properties. People say all the time, "I can't use p because that adds extra returns." Of course, those aren't "extra returns." Rather, they're the default margins applied to paragraph elements. Likewise for lists (the bullets and the indents). All of those properties can be over-wrriten by a developer.

2. Don't Develop in QuirksMode

QuirksMode is what forces browsers to apply odd default behaviors, meant for backwards compatability of OLD webpages. Among the most common are issues with 100% height, not inheriting properties into tables, IE's bad box model (padding and borders within the width), and block centering. It happens when:

  1. You don't have a doctype at the top of your page
  2. You have a transitional HTML doctype
  3. You're not using at least an HTML 4.01 doctype
  4. You're using XHTML and you have the <?xml?> prolog (which is unnecessary)

So it's really easy to fix. Use one of the following doctypes:

3. Develop in a good browser THEN test with IE.

It sounds backwards. There are a lot of IE users (though diminishing quickly), and so many developers assume that developing for IE first and then other browsers is the efficient way to work. However, this is almost certainly the wrong way.

The most obvious reason is that IE makes some horrible assumptions for element's default properties and CSS behaviors. This is not totally unexpected, and there are a few legitimate reasons for it:

  1. Lots of IE's own specs were created before the standards were finalized. This is a forgiveable offense.
  2. Lots of the assumptions are because most web developers are idiots. Sort of forgiveable.
  3. IE likes to pretend it can fix the mistakes of web developers. While this is good for some, there's no reason that a new web site should rely on the browser to fix its mistakes.

With all that said, however, the default assumptions are fixable. Thus, when you develop in a good browser, IE will apply the correct styling in a vast majority of the cases. Thus, in one fell swoop, you get IE and all the other good browsers.

The second obvious reason is that IE has some major bugs. By testing in IE first, developers often find themselves over-compensating in their CSS. That is, they apply needless styles to fix IE's problems. However, by getting your CSS correct in a good browser first, you can isolate the problem as IE specific. In some cases, doing it correct first fixes the problem in IE anyway. If it does not, the developer can use either conditional comments OR the * html element trick.

So the moral of the story, use IE second.

4. Try before asking

A lot of people just ask a question without even have tried what they're asking about.

It's always better to try first, rather than have us to answer questions you can answer yourself.

And then, if you have any problem, feel free to ask.

5. Help us help you

People are rarely willing to help with obscure questions. In order to get effective help, follow these simple guidelines:

  1. Create a simple test case. No one wants to dig through 4-12 pages of style properties to find a single line.
  2. Minimize your code #1. If you have lots of properties that don't alter the element's behavior, remove them. It's not uncommon for people to have random "position: relative;" strewn about like it's a meaningless property. Believe it or not, it may be the source of your bug.
  3. Minimize your code #2. Use CSS' inheritance and cascading property; it's there for a reason. There is no reason that your stylesheet should have lots of font-family properties. Moving it to the parent most element makes your code more legible.
  4. Minimize your code #3. We don't care if you don't like the shorthand properties (or if you don't understand them). It shortens your code and makes finding the erroneous line just that much easier. If we don't have to parse out 40 margin-n; lines, you'll save us and yourself time in the long run.
  5. Do not come with code that you've copied or had created for you. If you haven't written it or don't understand what it does, then how do you expect anyone to help you fix it?

6. Brush up on your HTML

Chances are pretty good that you don't know as much about HTML as you think you do. If you can answer affirmatively the following questions, you can ignore this rule:

  1. I use a label tag for all my form elements.
  2. I know how to use th, thead, tbody, tfoot, and caption elements.
  3. I know what an element is.
  4. I know what a block level element is and can identify a couple of examples.
  5. I know what an inline element is, and I can give a couple examples.
  6. I understand why that distinction is important.
  7. I know what br does and why its usually NOT what people mean.
  8. I understand that most HTML tags have a semantic value.
  9. I know which tags have no meaning.
  10. I understand the importance of a doctype.
  11. I know what quirks mode is.
  12. I know how to get my page out of quirks mode.
  13. I know what the anchor element is used for, and what it's not used for.
  14. I know why the previous statement is important.
  15. My pages have no validation errors, or I know why they don't.

How did you do? If you didn't do well, then you probably don't know as much about HTML as you ought. In which case, you're going to struggle applying lots of the CSS wisdom offered by the members of #css.

7. Valid != Correct for a particular purpose

Let's be clear. The fact that your code "validates" (as CSS or HTML) does not mean that it will necessarily do what you want.

Validation simply means that your syntax is correct. You have picked valid properties and valid values. Valid CSS and HTML is not magic for "now do what I want."

Writing CSS that is correct for a particular purpose requires two steps:

  1. Figuring out the correct properties and values to achieve your goal.
  2. Then using the correct syntax.

The lesson, if you do the first step correctly then validation just makes sure that you don't have typos. Simply typing arbitrary properties and values may validate, but not give you what you want.

8. Asking for Tutorials

If we didn't post a tutorial or a help page for you, it's probably because we:

  1. don't have one
  2. don't know of one
  3. expect that you can adapt a more generic example to your needs—in other words your problem is a variation of one of many simple problems OR a combination of them
  4. Your problem isn't the type that people write really generic tutorials about
  5. Giving you a tutorial would amount to writing the code for you

Whichever the case, CSS is not a complex "language." It is a simple set of properties applied to boxes. If you can't figure out your problem, start drawing boxes on the screen and then take the handul of properties you have to figure out your problems.

9. About tables for layout

Before you argue the benefits of tables for layout, it's best that you have a good understanding of what CSS is and how it's used. Trust us.

First, most of us were not CSSers by birth, and most of us have wisely migrated away from tables. The fact that you haven't yet conceptualized why less HTML code is a good thing is not our fault.

Finally, tables have their place. In fact, you can do very nifty stuff with tables and CSS. So no one worth their salt is going to argue that there should be no tables ever. However, if you're using tables for layout, you are most certainly wrong.

You can find more info about tables by searching for that word in the "Links"-section of this site

10. Why CSS is probably frustrating to you

Like HTML, CSS is actually fairly simple. What can be simpler than taking a set of known properties and applying a given value to an element? I suppose something that reads your mind, but you'll have to wait a couple decades for that.

Nevertheless, you're probably frustrated because you probably have:

  1. never actually written legitimate HTML. This is true if you've been using tables; your code is devoid of paragraphs, headers, and lists; you hide form tags between rows of a table to avoid extra whitespace; you think that images are a good way to create space; you've never once validated or don't even know what that is; and you use img elements to add design elements.
  2. never once thought through the content before applying style to it. That is, you simply add content to a table regardless of any actual logical connection between code and content.
  3. never spent anytime thinking about how documents are created in a web browser. The default document flow is what CSS designs are all about manipulating. If you don't know how it works by default, you are going to have a hard time using it.
  4. a belief web site creation is simple. Most people think web design is like the church newsletter: that even grandma can do it. In reality, good web work is time consuming if you don't do it a lot. Moreover, being a good web developer probably means a working knowledge of html, css, javascript and at least one server-side language.
  5. started writing CSS by filling in every pretty property. Usually, only a handful of elements actually have any positioning. And, in general, only a few more elements have more than half-a-dozen properties set. So K.I.S.S.
  6. found some complex example that you're trying to follow. Most of the people that come asking questions, ask questions about layouts and designs that far exceed their html and css skills. So they go in search of an example. The problem, however, is that example you're following is probably old and full of browser hacks that you're not going to be able to make heads or tails of. They're probably there for a reason, but you don't know the reason because you've never had to solve the problem before. Start simple.

To ease this frustration, you should begin by writing your content first. Nothing more, nothing less. Once the content is written and properly marked up, then continue by grouping related content into containers (the customary container is the div element). Once everything is grouped together, you can then begin applying style to your page. Add style systematically and incrementally. Start at the top, and work your way down.