What is an em?

Firstly for anyone that hasn’t used ems before, here’s the definition:

An em is a unit of measurement in the field of typography. This unit defines the proportion of the letter width and height with respect to the point size of the current font. Originally the unit was derived from the width of the capital “M” in a particular typeface. This unit is not defined in terms of any specific typeface, and thus is the same for all fonts at a given point size. So, 1 em in a 16 point typeface is 16 points.

Using ems to set the font size

There’s many ways that you can use ems. Personally, I prefer to set the font size so that all HTML elements within the page are consistent and use 10px throughout a website using the following code:

body, select, input, textarea {
font: 0.625em/1.4 tahoma, verdana, arial, helvetica, sans-serif;
}

This is just the starting point though to reset the font size to a consistent level. The 1.4 sets the line-height and following on from that is the font-family which will change depending on the project but the one thing that is consistent is the 0.625em regardless of the website I’m working with.

By doing this, it allows me to easily set font sizes for other elements and containers within the site. For example, if I want to set a font size to 12px then I can do so by declaring an em size of 1.2em; If I want 9px, then it’s 0.9em and so on.

As you can see from the following CSS code, creating font sizes using em values is actually just as easy as using pixels but with the advantage that they can scale regardless of the device or web browser being used:

#navigation {
font-size: 1.4em;
}
h1 {
font-size: 2.4em;
}
#content {
font-size: 1.2em;
}

What about inheriting ems

This causes the biggest confusion for a lot of web designers and is why a lot of people revert back to using pixels. Take the following example:

#content {
font-size: 1.2em;
}
#content p {
font-size: 1.1em;
}

Now, a lot of people might expect that the paragraph would display at 11px given what I explained earlier. However, ems are inherited and therefore the initial 10px would render at 12px due to the #content font value but then assuming that the paragraph is nested within the #content element, it would then be scaled to 1.1em of it’s initial value and would therefore actually appear larger than 12px.

In order to get around this I use the following chart: http://aloestudios.com/tools/emchart/ to determine which em size I need to use in order to inherit the correct font size.

So in the above example, you’d need to use the following:

#content {
font-size: 1.2em;
}
#content p {
font-size: 0.917em; /* this will render at 11px */
}

Summary

Using ems can take a little getting used to but if you want to create accessible font sizes then it really is the best solution and once you’ve got the hang of how ems are inherited they’re a powerful tool.

You can even create truly flexible websites by using ems for entire layouts so that they scale with the users default font setting but I’ll save that tutorial for another time.

1. Using Multiple h1′s on the same page

The <h1> tag should be used to markup your heading for the current page and should come at the top of your main piece of content. If you have a document which contains information about Lions in Africa then it would make sense to use your h1 with that text within the element:

<h1>Lions in Africa</h1>

If you then had another piece of content which went into detail about Zebras in Africa then you should have a separate document with that text  as the <h1>

In a situation where you’re only briefly touching on each subject and there wouldn’t be enough content to justify breaking it into separate pages then it would make more sense to have a document structure like this:

<h1>Wildlife in Africa</h1>
<h2>Lions in Africa</h2>
<p>Content about lions in africa</p>
<h2>Zebras in Africa</h2>
<p>Content about zebras in Africa</p>

2. Using the same h1 on every page

Quite often you’ll see websites markup their logo or site title with an <h1> tag. In fact the wordpress theme I’m using for this very blog also makes that mistake (I’m in the process of building a bespoke one which uses headings correctly).The problem with this is that it doesn’t offer users or search engines anything unique as the main heading and would be the same as marking each chapter in a book with the book title rather than something easy to differentiate between each page of the site.

A logo or site title should not be used as the main h1 as this should be reserved for the heading for the actual content but this is a mistake I see regularly and can easily be fixed by ensuring the h1 element is only used to markup the beginning of the main content.

3. Using the heading tag because it matches the font size

This is a common mistake for newbies to web design but is something that I still see from time to time. Web designers who don’t understand CSS properly will sometimes avoid using a particular heading because it doesn’t match the appearance that they’re looking for in their design. Quite often this will be because an h1 is too big for what they want so they might use an h2 or h3.

However, by using CSS it’s easy to style the headings to look however we want so the font size should never be considered when deciding which is the correct heading to use. Which moves us on to the next point nicely…

4. Not using a heading structure

Headings should all follow a clear structure so, an h2 should follow an h1 , an h3 should follow an h2 and so on. This is closely linked to the previous point as I’m sure that this is misused most when people forget that they can easily change the size of the heading with CSS.

For example, the following is a good heading structure:

• <h1>Wildlife in Africa</h1>
  • <h2>Lions in Africa</h2>
    • <h3>A Lions Diet</h3>
    • <h3>Lions Characteristics</h3>
  • <h2>Zebras in Africa</h2>
    • <h3>A Zebras Diet</h3>
    • <h3>Zebra Characteristics</h3>

As you can see from the above example, each subheading follows on from the previous heading. I find it useful to imagine the heading structure in the same way as you would a contents page in a book.

5. Not using heading tags at all

I’ve also seen the opposite happen on webpages, whereby instead of a web developer misusing the heading tags, they simply don’t include any at all.

This is quite often the case when a web designer doesn’t understand the purpose of the heading element but this is an easy problem to fix. All content should be headed up with an h1 tag so adding that to the beginning of the content is a great start.

I’d then also look to break the content into sections. Good content usually follows a theme and explains one point before moving on to the next so if possible I’d always try to introduce h2′s as a minimum and quite often h3′s. For long blocks of content I’d also look to break this down further with h4′s and so on but in most cases it isn’t usually required so whatever suits your content best.

6. Using the heading tag for non-heading content

I’ve seen this used on different occasions, sometimes by accident where newbie’s use it for making content bold or because it matches the style they’re after but I’ve also seen this where designers are deliberately trying to trick search engines into using the words placed within the heading element to rank their page.

The heading tag does help to rank web pages and is one of the main things on a web page that you can use to add emphasis to keywords and phrases. However trying to manipulate the search engines in this way will only have a negative impact as they’ll either dish out a penalty for over abusive sites or the web page in question will be diluting their heading tags so much that it won’t actually achieve it’s objective anyway.

It’s much more beneficial to use heading tags for what they were meant for and to ensure that clear and concise text is used which uses the keyword and phrases that are being targetted within the search engines than over using the tags in places that they weren’t meant to be used.

7. Marking up side boxes and navigation with headings

Headings should only be used to markup content on a page but are often misused to place headings on side boxes and navigation. This leads to the same headings being used across multiple pagesin every instance where these components are used. Not only does this make the content less accessible for things like screen readers but will the website won’t be making the best use of heading elements for search engines and therefore rankings will be suffering as a result.

To fix this problem, simply use the heading tags for the main content on the page and use none semantic elements (<span> and <div>) for marking up content that doesn’t require semantic meaning.

Summary

Once you understand how headings should be used to give proper structure and semantic meaning to an HTML document it comes as second nature to use them correctly.

Do you follow these principles? Do you disagree with any of the above points? Please feel free to comment below.

Cameron Moll has put together an excellent write up on Cufón font embedding over on his blog so if you’re looking for an in depth review and how to set it up then it’s definitely worth having a read of his article.

I’ve had a quick play around with it and am very impressed with how easy it was to set up. When I first had a play around with sIFR it must have taken me a few hours to setup a font rendering how I was expecting it to. However, ten minutes of playing around with Cufón and I had something thrown together which actually worked.

There are a few bugs and issues with Cufón that Cameron’s article goes into but even with those taken into consideration, I’d still be tempted to use Cufón over sIFR purely for the fact that it’s so easy to use and implement.

For more information and to get started with Cufón visit http://wiki.github.com/sorccu/cufon/about

When dealing with content like tables and paragraphs, it’s usually quite easy to decide which element to use for the given circumstance. However, dealing with FAQs is slightly different in that there is no <faq> tag or a <question> and <answer> tag, so a slightly different approach needs to be taken to ensure that the FAQ is given the same semantic treatment as the rest of the page.

I’ve used a couple of different methods over the years for marking up lists.

Heading and Paragraph Method

The first method I used was to use a heading for the question, a paragraph for the answer and then group all the items together by using a surrounding div.

<div id="faq">
<h2>Can I use tables for creating a webpage?</h2>
<p>No, you should use Semantic HTML for the structure and CSS for the presentation</p>
<h2>Which browser should I support</h2>
<p>As a minimum you should support the latest versions of Firefox, Opera and Safari whilst you should also support IE7 and IE6</p>
</div>

This method does work quite well but whilst it provides some semantic meaning, it never quite felt right. The FAQs are in essence a list of items but using headings and paragraphs doesn’t quite convey this meaning.

Definition Lists

So recently, I’ve started using a definition list to markup frequently asked question lists as I feel it gives each item much more meaning and groups elements together much more effectively.

<dl id="faq">
<dt>Can I use tables for creating a webpage?</dt>
<dd>No, you should use Semantic HTML for the structure and CSS for the presentation</dd>
<dt>Which browser should I support</dt>
<dd>As a minimum you should support the latest versions of Firefox, Opera and Safari whilst you should also support IE7 and IE6</dd>
</dl>

I feel much happier using a definition list for FAQs as it groups the items much better than using a non-semantic div element. Definition terms are then used for the question and the definition description is used for the answer which I feel groups each pair of items much better than any other method.

You could then quite easily use CSS to style this accordingly to give a clearer understanding visually to your definition list. For example:

* {
margin: 0; padding: 0;
}
body {
font: 100%/1.5 "lucida sans", verdana, arial, helvetica, sans-serif;
padding: 10px;
}
h1 {
font-size: 1.4em;
}
#faq {
font-size: 0.8em;
border: solid 1px #999;
padding: 0.5em;
}
#faq dt {
background-color: #CCC;
padding: 0.3em;
font-weight: bold;
}
#faq dd {
padding: 0.5em 0.3em 1em;
}

Summary

As FAQs are quite a subjective topic, there are bound to be numerous different ways of presenting this kind of information. I’ve seen them represented using tabular data and even just using paragraphs styled differently using CSS but personally I feel the two options above are much tidier and semantically better solutions with the definition list being my preferred option.

What do you think?

Whilst reading Peter Gasston’s Broken Links blog, I came across the following HTML quiz.

• Take the HTML Element Quiz

There’s 91 elements altogether… how many can you name?

It’s harder than it looks but have a go and please feel free to let me know how you did in the comments below.

Within this part, I’ll explain how you can use CSS to alter the display of these elements to help with the presentation.

Block elements

As I explained in the previous part, block elements by default will fill 100% of the available width and will automatically force a new line.

However, in some circumstances it makes semantic sense to use a block element even though the appearance of this isn’t quite right and in these situations we can use CSS.

For example, menu items are a list of links and therefore we should use an unordered list to display them. For example:

<ul>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Services</a></li>
<li><a href="#">Portfolio</a></li>
<li><a href="#">Contact</a></li>
</ul>

Which is great but what if we want to display these in a horizontal navigation bar?

We need to alter the default display so that each list item can be displayed inline.

* { padding: 0; margin: 0; }
li { list-style-type: none; display: inline; }

This works great but what if you want to add a width or height to a list item?

* { padding: 0; margin: 0; }
li { list-style-type: none; display: inline; width: 150px; }

A width or height will not displayed on an inline element so the width on the above code will have no impact. However, there is a solution to this little problem using float’s.

li { list-style-type: none; float: left; width: 150px; }

By floating each list item to the left, it will give the appearance of an inline element and will also by default only take up as much space as is required in the same way as an inline element but will also allow you to style them as if they were block elements. Therefore width and height can be applied to float’s successfully irrespective of whether the element has a default display of block or inline which is the reason why float’s are used so much in web design.

The same principle can be applied to all block level elements and is a useful technique to be aware of.

Inline elements

Inline elements are slightly different as it is much rarer that you’ll need to alter an inline elements display but there are certain circumstances when you may need to do this and it’s perfectly acceptable to do so.

Sometimes I’ll find that I’ve had to use an inline element but need it to fill the whole width and to break onto a new line so changing the element’s display into block is the perfect solution.

The best example of this and the most common in my experience is when dealing with <a> the tag. When dealing with navigation, I may want style a link so that it appears more like a button but obviously a width cannot be applied directly to an inline element and therefore there’s no way of setting the width of the link to completely fill it’s container without changing it’s display.

Take the HTML code in the example above and apply a background colour to the link like so:

* { padding: 0; margin: 0; }
li { list-style-type: none; float: left; width: 150px;}
a { background-color: #CCC; }
a:hover { background-color: #000; }

This works well but only applies the effect to the text. Even if you were to apply a width to the , it won’t have any effect due to it being an inline element.

However, if we change the display value of the to display block, it will open up a whole new set of options.

* { padding: 0; margin: 0; }
li { list-style-type: none; float: left; width: 150px;}
a { background-color: #CCC; display: block; }
a:hover { background-color: #000; }

This will now force the element to completely fill it’s parent’s container which we’ve already specified as being 150px and will also allow much more flexibility when styling this element.

For example, you could now apply the following CSS to the HTML we first started out with and create all kinds of navigational menu’s that wouldn’t be achievable without changing the display value.

* { padding: 0; margin: 0; }
body { font-family: verdana, arial, helvetica, sans-serif; font-size: 75%; }
li { list-style-type: none; float: left; width: 150px; margin-right: 2px;}
a { background-color: #CCC; display: block; padding: 2px; text-align: center; color: #000; }
a:hover { background-color: #000; color: #FFF; }

There’s many possibilities and effects you can achieve by simply changing the display of an element and we’ve only really covered two of the most common uses here but the same principle applies to all elements so understanding the basics of the block and inline elements is essential in getting the most from your code.

Block elements

Block elements take up the full width of the page and are naturally displayed on a new line. Block elements can not be nested within inline elements.

Examples of block elements

• <div>
• <h1> … <h6>
• <p>
• <table>
• <ul>, <ol>, <dl>
• <li>, <dt>, <dd>
• <form>
• <blockquote>
• <pre>
• <address>
• <fieldset>

Inline elements

Inline elements only take up as much width as is required to display the element and will not force a new line.

Examples of inline elements

• <span>
• <img>
• <a>
• <strong>
• <em>
• <br>
• <input>, <textarea>
• <abbr>
• <acronym>

Not displayed

Some HTML tags are not displayed and should usually be placed within the head of the document.

Examples of none displaying elements

• <meta>
• <style>
• <script>

Block and Inline elements: Part two

Validate HTML

I’ve said it hundreds of times, if the HTML code that’s being read by the browser isn’t valid then it’s highly unlikely that what you’ll see will be consistent across all the standards compliant browsers.

More experienced web developers will generally design a site and then test at the end to ensure that there’s no tiny little glitches that have been missed. However, for beginners it is imperative that they test their site as they’re developing. The W3C Markup Validator is a vital tool for any developer and should be used during development to ensure that there aren’t hundreds of issues to fix once a site has been built. Fixing problems as they appear is much easier than trying to rework all your HTML code at the end of a project.

Validate CSS

Once you’ve ensured that your HTML is valid, it’s time to check that the CSS you’ve created is also valid with no spelling errors. It’s easily done and missing out a } or ; can have huge implications on your layout. You can check your CSS at http://jigsaw.w3.org/css-validator/ and is something I’d definitely recommend doing.

Needle in a Hay Stack

So you’ve validated the site but it’s still not quite appearing how you’d expect it to in one or more browsers. This is usually the situation that people find themselves in at the end of a project when they’ve built a site and are browser testing. They have lots of HTML and CSS and something is slightly out of place but there’s so much code that it’s almost impossible to know what to change. The ideal situation would be to have tested in each browser during development but starting again is pretty much out of the question at this stage. So how can I isolate that single bit of code amongst hundreds of lines of HTML?

Firefox Web Developer Tool bar

Firstly, for people using Firefox, the Web Developer Tool bar Extension is a priceless plug-in that can save a great amount of time. Outlining block level elements is probably the feature I use the most as you can instantly see where the borders of elements are and the spacing of these elements including the padding and margins although using the display topographic information can be just as useful.

Outlining Body Elements

But my problem is in Internet Explorer, I hear you cry. I’m sure there are other tool bars available for all browsers by now but I prefer a simpler approach when debugging.

Using CSS I apply the following:


div {
border: solid 1px red;
}


This will outline all divs within the page on all browsers so I can easily see where the edges of divs meet. This is extremely useful if you’re unsure whether paddings and margins are being applied or unsure what is forcing a div out of position. Exactly the same principle can be applied to other elements as well. However, you should be careful as this does add an extra couple of pixels to either side of the element it’s applied to so may knock your design out slightly, as long as you’re aware of this though then it can be useful in spotting the problem.

Isolating a Problem

If using the outlining body elements method didn’t manage to get you any closer to solving the problem don’t worry, there’s still an easier way to find out what the problem is without going through each individual part of the page and tweaking the HTML only to find that you still haven’t found the problem.

Well coded websites are usually divided up into separate sections. Whether this is by using div’s or by using id’s within body elements is irrelevant but most pages I deal with will have clear areas of code that are clearly defined.

Please note: At this stage, I’d recommend making a copy of your page as you’ll be removing lines of code from your page. Speaking from experience it only takes an accidental close of your HTML editor or a power cut to lose hours or days worth of work.

Once you’ve made a copy, start by removing large areas of your page. Start with areas that you’re pretty sure aren’t responsible for the problem. If the problem seems to be within your footer, try removing the header and then refresh the page. If the problem is still there, remove the navigation and so on until you’re left with just a few lines of code. Quite often I’ve found that a problem has been caused by an area of the page that I’d never have expected it to be and only by following this process of eliminating code have I tracked down where the issue is.

Now that you know that the problem is being caused by this area of the page it’s time to delve into the CSS and see what part of the CSS is causing the issue.

It may be useful to apply background colours to the individual styles you have left in your page. This can sometimes highlight a problem quite obviously with the padding and margins which may have been overlooked during an earlier stage. It may also show that there’s a problem with a mixture of block and inline elements which is quite common so this step makes those issues easier to spot.

I’d then suggest removing a complete CSS style and seeing what happens. If the problem is still there then try another CSS style. It shouldn’t take too long before you find which CSS style is causing the problem. Once I’ve highlighted the style that’s causing the problem, I’ll start removing one value at a time from this style. For example, remove padding and margins from this style, refresh the page and see if that solves the problem?

Eventually you’ll have tracked any problems down to one or two styles that may be conflicting with each other or that a certain browser doesn’t render quite as expected (I’m looking at IE when I say that) and a fix can be put in place.

Summary

Learning fixes for HTML and CSS problems will come with experience and initially you may need to ask for advise, but having the knowledge to be able to track down where a problem lies in the first place is certainly a skill that is easy to come by if you understand the process.

Do you debug HTML and CSS differently? Do you have a more efficient method? Please feel free to leave any comments.

HTML 4.01 Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">


HTML 4.01 Transitional

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">


HTML 4.01 Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">


XHTML 1.0 Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


XHTML 1.0 Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


XHTML 1.0 Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">


http://dev.w3.org/cvsweb/~checkout~/html5/html4-differences/Overview.html