Building your website… Part 2

Editors note:

I apologize for the use of all the images-I know they don’t look that create against the background of this site, and because they are images you are unable to copy the examples directly. However, the use of images was the only way for me to keep the formatting of the code, so that is how I did it. If there is a demand for it, I will release a code pack with all the examples in it, but they are all so simple that I feel it is unneeded at this point.

---

Here we go again with part 2 of the ‘Building a website…’ series. This articles predecessor, Building a website… Part 1, covered creating a blog at WordPress.com. In this second article in the series I will talk about building a website by utilizing HTML and CSS. I also plan to advise you on the best free editors available for this kind of work, as well as different places that you can host your newly created webpage in order to share it with the world. So onward, comrade, let us delve into the world of HTML!
When I first began writing this article, I was planning on including a somewhat brief history on the internet. However, on reflection, I have decided that it would serve little purpose since anyone reading this article has come here to learn to build a website, and not for a history lecture. That said, let’s go over the basics first:

• HTML stands for Hyper Text Markup Language and is used to create pages that will be rendered to the screen through a medium such as a browser.
• The look and feel of HTML pages is controlled by Cascading Style Sheets, also known as CSS.

Those are the two points that will be elaborated upon in this section of the article.

Before beginning to discuss what is required for a webpage, what is not, and how to write it, there are a few basics about HTML tags that you need to know.

• All HTML tags are enclosed within the less-than and greater-than mathematical signs: < and >
• All HTML tags, whether or not you are writing XHTML, should be followed by a closing tag with few exceptions. Doing so will keep your pages consistent across all browsers.

So let’s take a look at an example:

<strong><em>The italics tag has been deprecated in favor of the emphasis tag, and the bold tag has been deprecated in favor of the strong tag.</strong></em>

There isn’t anything wrong with this example, right? Not quite. In this example we have utilized the <strong> tag as well as the <em> tag. The <strong> tag causes all text between it and the closing tag, </strong>, to become bold. The <em> tag causes all the text between it and its closing tag, </em>, to become italicized. By nesting the <em></em> tags within the <strong></strong> tags, all text between the opening and closing tags will be both bold and italicized. Nesting elements in (X)HTML is common practice and can be done with any number of elements.

Anyways, back to the example. The opening tags, <strong> and <em>, used to make text bold and italic, respectively, were followed at the end of the string with their closing tags, </strong> and </em>, respectively. This is a very important concept that you MUST grasp! Tags such as the <strong> and <em> tags cause all text after the opening tag up to the closing tag to become bold or italic, depending on the tag you use. Had I not put in the closing tag for either <strong> or <em>, every word following the <strong> or <em> tag would be either bolded or italic regardless of what other tag came afterwards, up until the tags were closed.  The exception to this rule is tags that do not have a closing element which will be discussed later. For now though, assume that ALL tags must be followed by a closing tag. Here’s an example illustrating that point:

<strong><em>Here’s my bolded and italic text.</em> And my text is now just bold.</strong>

Or if I had forgotten to close the <strong> tag:

<strong><em>Here’s my bolded and italic text.</em>And my text is still bold.
Next paragraph is still bold because I haven’t closed the <strong> tag yet.
…

Alright, moving on. There are a few different parts that are required for HTML pages. Technically, all this is needed for the most basic page is listed below in figure 1.1. However, we will be doing things a little differently and using XHTML, which is very similar to HTML, with a few small differences. XHTML is very similar to HTML syntactically though, so everything you learn in this guide, even though I will be frequently referring to XHTML instead of as HTML, will be applicable should you choose not to necessarily use XHTML:

• XHTML elements must be properly nested
• XHTML elements must always be closed
• XHTML elements must be in lowercase
• XHTML documents must have one root element

Before going on, I’m sure that you are wondering why use XHTML in the first place? Just mentioning XHTML vs HTML has probably made some of you nervous and maybe even others leave this page because this post is “not what I was looking for.” My reason for introducing you to XHTML is this: XHTML features many syntax rules that are not present in HTML, but are characteristic of good coding habits. Let me explain. HTML is less demanding of the coder than XHTML, plain and simple. XHTML has more rules to follow-like the ones above-that must be followed or else you will not receive the desired result. However-and this is a big however-all the rules for XHTML syntax are both applicable in HTML coding, as well as good programming practice. By forcing you to follow the rules in order to obtain the result you desire, I hope to impose on you good programming habits at an early stage. Believe me; changing your coding style, regardless of the language, just gets more and more difficult as time passes.

Okay, that done, let’s take a look at the first point: XHTML elements must be properly nested. Take a look back at the example we used previously. In HTML you could write code like this:

<strong><em>The italics tag has been deprecated in favor of the emphasis tag, and the bold tag has been deprecated in favor of the strong tag.</strong></em>

In HTML that would be fine. In XHTML, however, you must properly nest elements. Here’s the example cited above written properly in XHTML:

<strong><em>The italics tag has been deprecated in favor of the emphasis tag, and the bold tag has been deprecated in favor of the strong tag.</em></strong>

Notice that the <strong> tag is declared first, then the <em> tag at the beginning of the line. However, at the end of the line the <em> tag is closed first, and then the <strong> tag. Why? Let’s take a look at the next point.

XHTML elements must always be closed:

<strong><em>The italics tag has been deprecated in favor of the emphasis tag, and the bold tag has been deprecated in favor of the strong tag.</em></strong>

Notice how the tag to make text bold, <strong>, is declared first, then the emphasis tag, <em>, used to make text italic, is declared second. When the tags are closed at the end of the line, see how the <em> tag is closed first by using the closing tag, and then the <strong> tag is closed? Here’s a rule you can follow: Once a tag is opened and you are ready to close, close the nearest tag and work your way backwards. In the example above, <em> was declared second, but was closed first because it was nearest to the end of the line. Then <strong> was closed next, and if a third tag had been used it would have been closed after <strong>. In order to write proper XHTML you must adhere to the standard of closing your tags in this way. This is what I mean:

<1><2><3>……..</3></2></1>

See how the fake tags I created are declared in order, and then closed in the opposite order? This is how you should close you tags, regardless of whether or not you are using XHTML.

A note on deprecation:

Congratulations, you have just been introduced to your first XHTML tags, and you now know how to close them as well. Before continuing, I would like to make sure that you understand something: the text between my example tags stated that both the italics and the bold tags (<i> , <b> , respectively) had been deprecated in favor of the emphasis and strong tags (<em> ,  <strong> , respectively). However, you will still see deprecated tags such as <i> and <b> used very frequently despite their deprecation because they will still produce the desired results and because that is what a lot of web developers have been using for years.

<b><i> The italics tag has been deprecated in favor of the emphasis tag, and the bold tag has been deprecated in favor of the strong tag.</i></b>

This would give exactly the same result as the correct XHTML equivalent using non-deprecated tags.  I would advise that you do not to use the deprecated tags. Should you decide to ignore my warning, let me say this: your code will be much more effective, more versatile, and more professional-looking if you decide to use the correct tags, and once the tags stop being supported, then what are you going to do? Go back through all of your webpages and do Ctrl+F to replace them? Maybe, maybe not.

XHTML elements must be in lowercase:

Many HTML coders like to write their code in CAPITAL letters. So going back to the previous example, using caps would look like this:

<STRONG><EM>The italics tag has been deprecated in favor of the emphasis tag, and the bold tag has been deprecated in favor of the strong tag.</EM></STRONG >

In regular HTML, something like this would be fine. Whether or not you use uppercase letters or lowercase letters in your tags makes little difference when coding in HTML, but when writing in XHTML this is syntactically incorrect and should be avoided.

The last point mentioned above will be a brilliant segue into the basic structure of HTML pages, as well as that of XHTML pages.

XHTML documents must have one root element

To understand this, let’s look at the most basic of HTML pages:

Figure 1.1:

As you can see, a basic HTML page is just a series of opening and closing HTML tags, which you learned about earlier. Here’s an example of a basic XHTML page with the fewest number of tags:

Figure 1.2

The basic XHTML page definitely looks more complicated than the basic HTML page, but there is really only one difference: in XHTML you MUST include a <!DOCTYPE…> declaration, and it must always begin on the first line in your document. In HTML you do not need this, although there is some advantage to having a <!DOCTYPE…> declaration even in HTML pages.  Basic HTML documents consist of three main parts:

1. The <html> declaration. This defines the document as an HTML document for the browser, telling it how to display the document.
2. The opening and closing <head> tag. “The head element is a container for all the head elements. Elements inside <head> can include scripts, instruct the browser where to find style sheets, provide meta information, and more.The following tags can be added to the head section: <title>, <base>, <link>, <meta>, <script>, and <style>.” (source: W3schools.com)
3. The opening and closing <body> tag. Between the <body> and </body> tag you will place everything that is to be displayed to the screen.

Basic XHTML documents consist of four parts.

1. The <!DOCTYPE…> declaration which tell the browser what kind of document it is viewing, as well as tells the browser which version of the Document Type Definition (DTD) to use. The DTD specifies the rules for the markup language, so by defining which version of these rules you wish to you, you can be sure that your content will be displayed correctly. As a side note, the <!DOCTYPE…> declaration is actually not considered an HTML element; it is a structure telling the browser which version of the markup you are using.
2. The <html> declaration.
3. The opening and closing <head> tags.
4. The opening and closing <body> tags.

As you can see from this list, the only difference between the required elements of a basic HTML page and those of a basic XHTML page is that of the <!DOCTYPE…> definition at the beginning of the page.

Before continuing and explaining some more HTML tags, I would like to explain a few things about the <!DOCTYPE…> declaration that was explained above. For convenience, I have pasted it below:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN””http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”&gt;

Some of you may have noticed that this looks like two separate elements on two lines. You are incorrect though, and here’s why: It is common practice to put the link to the DTD on the second line of the <!DOCTYPE…> declaration. This is made possible because of the structure of the <!DOCTYPE…> declaration, and cannot be done with other XHTML (or HTML, for that matter) tags.

If you had read through the <!DOCTYPE…> definition, you may have also noticed “Strict//EN” written at the end of the first line. It turns out that this is the actual DOCTYPE for the (X)HTML document, and there are a few different options to choose from. Below is a list with information on the different DOCTYPE’s available, courtesy of W3school.org:

There is also XHTML 1.0 Strict, XHTML 1.0 Transitional, XHTML 1.0 Frameset, and XHTML 1.1. Each of these versions are similar to their HTML equivalents, except that they are used at the beginning of an XHTML document, rather than an HTML document:

Based on this information, choose the best <!DOCTYPE…> declaration for your situation, and while it is not required, give some thought to using a <!DOCTYPE…> declaration in any HTML pages you create.

(X)HTML editors.

For those of you that were hoping I would list some basic (X)HTML commands in this section, I apologize, but how will you try commands if you do not have an editor? Notepad? No, I don’t think so. In this section I will mention my two favorite HTML editors-one is free, one you must buy-that will help you in the coding to come.

Before I do that though, I would like to caution you on using WYSIWYG editors. “What,” you ask, “is a WYSIWYG editor?” First, you should know how to pronounce this word, just because it’s fun. WYSIWYG stands for What You See Is What You Get, and is pronounced “wiz-ee-wig”.

So who shouldn’t you use a WYSIWIG editor? First, a WYSIWYG editor is an editor in which you simply drag-and-drop elements into a page, and the program will convert that page to HTML for you. Let me elaborate. When using a WYSIWYG editor you will be presented with a blank screen. You job is to fill that screen by dragging-and-dropping elements, coloring the pages with the paint bucket, and typing content in. Using a WYSIWYG editor requires little to no (X)HTML knowledge. However, like doing anything the easy way, using a WYSIWYG editor has its drawbacks. One such drawback is that while WYSIWYG editors make creating webpages easy, they also tend to offer less control over the look and feel of the webpage than writing it yourself in (X)HTML would offer; by creating your webpage with a WYSIWYG editor you will have an easier time controlling most aspects of your webpage, but it will be very difficult to fine-tune the page. That said, let’s look at some editors that help write good (X)HTML code:

HTML-Kit. HTML-Kit is a very, very good HTML editor for Windows that comes in both a free version as well as a paid version. The free version is fully-functional though, so unless you are planning on writing a significant amount of HTML code sometime soon, I would recommend the free version.

HTML-Kit features a great interface in which to program, allowing multiple files to be open at once and displayed alongside each other. The interface can be somewhat confusing at first due to the many functions built-in to HTML-Kit-one such feature checks your (X)HTML for syntax errors and can automatically fix them-so if you decide to go with HTML-Kit, play around with it for awhile and don’t give up on it.

EditPlus. EditPlus is an editor for pretty much everything, also for Windows. I apologize to anyone reading this on a Mac, but I Have little experience on a Mac so I cannot recommend an editor for the Mac based on personal experience.

I was introduced to EditPlus earlier this year in a programming class, and decided to try it out. I was surprised when I learned that EditPlus could not only handle writing code in C, Shell, and Perl, but also HTML and a variety of other forms. The variety of formats that EditPlus can handle is what made me want to use it, not because it did, to my knowledge and experience, any certain aspect of ((X)HTML)  coding any better than what I was already using. Additionally, EditPlus is not free, so unless you are planning on writing  code in numerous languages and need an editor that can handle doing so, I would suggest going with HTML-Kit, as HTML is what it specializes in.

It is also relevant to mention that both editors-HTML-Kit and EditPlus-allow you to connect to multiple FTP servers and edit files from them.

Basic (X)HTML commands.

Now that you have a basic understanding of some good programming practice, you know how to open and close tags, and you have an editor to write your code in, let’s get started on some (X)HTML code!

There are many websites that provide excellent articles on basic (X)HTML coding. One of the best is W3schools.com. Clicking the link will take you to the beginning of their extensive series of articles on writing HTML.

W3schools.com also provides an excellent tutorial on XHTML as well, which can be found here.

I will cover only enough basic tags in order to be able to talk about CSS in some detail before ending this article. For more information on HTML and XHTML, follow the links and read the pages from W3schools.com.

Empty tags. In this and the next couple paragraphs I will talk about various different types of (X)HTML code as well as provide examples in order to give you enough knowledge to understand the next topic, CSS.

The first type of tag I would like to discuss is empty tags, which I mentioned at the beginning of the article. Empty tags are tags that do not have a closing element. Empty tags are allowed in HTML, but unless written properly are not allowed in XHTML documents. Here are a few examples of empty tags:

• <br>
• <hr>
• <img>
• <input>

Each of these tags has no closing tag, but unless “closed” will be syntactically incorrect in XHTML documents. So how do you get by this? Add a “ /” (space, followed by the slash character) to the tag! Here’s the list again, converted to a format acceptable in XHTML documents:

• <br />
• <hr />
• <img />
• <input />

Now the <img /> and <input /> tags have a few things missing from them, so here is what they would look like if they were used in an XHTML page:

<img src=”my_image.jpg” alt=”My first image” id=”first_img” />

<input type=”text” name=”text_input” id=”text_input_field” />

Let’s take a look at the <img /> tag a little more closely, first:

<img src=”my_image.jpg” alt=”My first image” id=”first_img” />

The “src=” attribute is used to tell the browser which image to display to the screen. The value that is “passed” to the command, for lack of a better word and because I’ve been programming for too long, must by CaSe SeNsItIvE and also include the file extension-most commonly .jpg, .png, or .gif.The “alt=” attribute is used to print out the text string passed to it in the event that the image is unable to load, whether that be because you put the image name in wrong, or because the webpage viewer has images disabled in his or her browser it matters not.

Now for the <input /> tag:

<input type=”text” name=”text_input” id=”text_input_field” />

The first attribute, “type=”, tells the browser what kind of input this field will be taking. Some values that you can use, besides “text”, include the following list from W3schools.com:

• button
• checkbox
• file
• hidden
• image
• password
• radio
• reset
• submit

Each and every one of these attributes is a valid attribute of the <input type=”” /> tag. Let’s take a look at the first three different types:

• button
• checkbox
• file

Using button, your <input /> tag would look like this:

<input type=”button” name=”button” id=”first_button” value=”Click me!” />

The above code would create a button labeled “Click me!”

Using checkbox:

<input type=”checkbox” name=”checkbox” id=”first_checkox” value=”item1” />

The above code would create a single checkbox that, when clicked, would pass the value “item1” to a script interacting with the page, should there be one.

Using file:

<input type=”file” name=”file_submitter” id=”file_submitter” />

The above core creates what looks like a button, but upon clicking it you will discover that a dialog box opens asking you to select a file. This is used in pages that require you to upload some sort of file.

Besides the “type=” attribute, there was one other attribute that popped up in the button and checkbox examples. That attribute is “value=” and is used to create a label for buttons, a default value for text-boxes, or a value for checkboxes or radio buttons. Note that the “value=” attribute is required for checkboxes and radio buttons.

Another attribute that was on the examples that I have not explained yes is the “name=” attribute. The “name=” attribute is used to identify input within the “<form>” element, and can also be used to select elements in JavaScript. However, this element is not necessarily required.

The last attribute that was on the examples that I have not explained yet is the “id=” attribute, and is extremely important, especially in CSS and JavaScript. The “id=” attribute allows you to give an element a unique ID with which your CSS document or your JavaScript file can identify that element with. ID elements can be any number of characters long, to my knowledge, but should not contain special characters if at all possible, with the exception of the “-“, “_”, and the “.”. As far as I know, using special characters in ID names is not syntactically incorrect, but it is more aesthetically pleasing and easier to read if you do not use them.

ID’s MUST be unique to a single element: in a single (X)HTML document you CANNOT have more than one element with the same ID. For example, this would be incorrect:

<input type=”text” name=”user” id=”username_element” />
<input type=”text” name=”user2” id=”username_element” />

In the above example I have two different text boxes with the same ID. This is unacceptable and will produce an error if you try to do anything with these elements. The best way to overcome this is to use two different ID’s for each element.

But what if you want to apply the same style from a CSS document to each element? Now that you know that you cannot use the same ID for two elements, what is the solution? The solution is to use something called a class attribute instead of an ID. Unlike the “id=” attribute, the “class=” attribute is made to be given to multiple elements. Here’s an example that is perfectly acceptable:

<input type=”text” name=”user” class=”username_element” />
<input type=”text” name=”user2” class=”username_element” />

Now there are various reasons why you would not want to do something this way (getting the value of an element with only the class is difficult, since many elements can have the same class), but it is nevertheless syntactically correct.

Here’s a quick rundown of the principles we just ran through:

• Each ID you use in your (X)HTML document must be unique to a single element.
• If selecting more than one element (very common in CSS) use the “class=” attribute, which allows you to give multiple elements the same class.

Now that you know how to select elements in a document, let’s move on to some basic CSS.

As I mentioned in the beginning of this article, CSS stands for Cascading Style Sheet. CSS documents can be included in the (X)HTML document by adding the <style></style> tags between the <head></head> elements at the top of the document. Here’s an example:

CSS styles are put between the <style></style> tags, where I have the “…” in the above example.

CSS styles can also be incorporated into each element themselves in a document. Here’s an example:

<input type=”text” name=”user” id=”username_element” style=”margin:10px” />

Notice that there is not a semicolon after the “10px” in the above example. To include more than one style attribute in this manner, use the semicolon to separate the attributes:

<input type=”text” name=”user” id=”password_element” style=”margin:10px;color:red” />

The first example would add a 10 pixel margin around the textbox. The second example would add a 10 pixel margin around the textbox, as well as making the text inside the box appear red.

Applying styles to elements in this manner is called applying styles “inline”. Inline styles overwrite any other declarations of style for that element, regardless of where those other styles are defineds. Here’s why: Styles are applied in order of most recently defined. Take a look at the example and see if you can tell which color the text would be in the paragraph:

Those of you that guessed “blue” are correct. Why? Because the style that is applied to an element is decided upon by the most recently defined style, and that style is the one declared on the <p> element.

There is one more way to apply styles to a document with CSS, and that is by linking in a separate document containing your styles. Here’s how to do it:

Note that you do not need the extra lines around the <link /> element, I just put it there for demonstrational purposes. If you wanted to have whitespace, as it is called, there that is fine though, no errors will be produced.

By using the <link /> tag in this way, with the attributes “rel=’stylesheet’”, “type=’text/css’”, and “href=’theme.css’”, you are able to include the styles defined in the document named “theme.css” in your current (X)HTML document. As a quick note before moving on, you can use either quotation marks (“ and “) or single-tick marks (‘ and ‘) to enclose the values of attributes, the decision is up to you. Personally I prefer to use quotation marks.

Okay, let’s go back to the example above. Suppose that, in the CSS document linked to the page with the <link /> element, there was a style declaration that said that the element with the ID “paragraph” was to have the text inside it colored yellow. What color would the text be?

Blue, still blue. Regardless of what we try to define the paragraph element’s text color as, it will not change the fact that the most recently defined style for that element is the one defined alongside the tag, and will not change the fact that the text will turn out blue.

For the sake of making sure that this concept is understood, take a look at the next example and deduce what color the text should be, assuming that the text is still defined as being yellow in the CSS document linked to the page:

Red, the text in the paragraph will now be red because the style at the top of the page is the most recently defined style for that element. What about in the example below, continuing to assume that the text within the paragraph with the ID “paragraph” is being defined as “yellow” in the CSS document linked to the page?

Correct, now the text will be yellow.

Before moving on to an explanation of writing CSS documents, I have a personal recommendation regarding stylesheets: use linked stylesheets. Inline styles are fine for testing the application of certain style attributes, and including your style between the <style></style> tags between the <head></head> elements is fine too, but writing a separate document for your CSS style is the best option.

Here are a few reasons why:

• Inline styles can quickly become hard to read as more and more styles are applied to an element.
• The style for an element must be written each time when using inline style, even if you are applying the same style to multiple elements.
• As the number of styles you are applying grows, putting the styles between the <head></head> element becomes increasingly cumbersome to view, as well as making it more difficult to move back and forth between editing your styles and your (X)HTML.
• Linking a separate document containing all the styles that your page needs looks much cleaner and makes editing styles and the (X)HTML code much easier.
• Linking a separate document (or putting your style at the top of the page between the <head></head> element allows for the use of classes and ID’s to apply styles to elements. No matter how you look at it, inline styles lose here. If you don’t want to take my word for it and use linked documents for your CSS properties, try it out a few times each way and see which is easier.

Writing CSS.

This guide is applicable to both external CSS documents linked in using the <link /> tag, or if you are including the style at the top of your document between the <head></head> element.

-Selecting elements by IDThe first concept I will cover is selecting elements by ID. Let’s go back to the example we had just a few moments ago:

The challenge we are presented with here is to select the element with the ID of “paragraph” and make the text inside the element yellow. Here’s what the CSS document would look like:

Note: CSS documents do not require any special heading, only the file extension .css to be considered a CSS file, and, of course, the proper syntax within the document.

To select an element by its ID, append the special character “#” to the beginning of the name. The style within the following braces will be applied to the element selected above.

• # followed by element ID
• Opening brace: {
• Style attributes…
• Closing brace: }

Indentation of style attributes is not necessary in CSS, but it is good form to indent your attributes to make them easier to read.

-Selecting elements by CLASS

Take a look at this example, in which there are two paragraphs with the same class:

The challenge here is to make the CSS document select both elements with a class of “paragraph” and apply the same style to each. Here’s what a CSS document selecting both elements and making the text green would look like:

To select elements by their class, use the period (.) appended to the beginning of the name. The following code within the braces will then be applied to all elements within the current document that match the class name provided.

• . followed by the name of the class
• Opening brace: {
• Style attributes…
• Closing brace: }

This will cause everything with a class name matching that of the one provided after the period to have the style applied to it as specified between the opening ( {  ) and closing ( } ) brackets.

W3Schools.com also has a very good guide on CSS at their website, discussing everything from CSS syntax to advanced CSS attributes. Check the guide out here.

Some Special Circumstances: (SSC)

Here’s a good question: What if I have three elements, each with a unique ID, and I want to apply the same style to each. Do I need to write the whole name, brackets, style, closing brackets-for each one?

Answer: No, no you don’t. Check out this example:

Suppose we wanted to apply the same style to each of these elements, but still needed them to retain their unique ID’s for some purpose or another. There are two ways that could be done; here is an example along with an explanation of the first method:

In the example above I have defined a style for the elements with the ID of “welcome_message”, “information”, and “mission_statement”. By connecting the ID’s with a comma in between it is possible to assign the same style to multiple elements with the same ID. This can also be done with classes, although there is little reason to do it with classes for obvious reasons.

1. # followed by the first element’s ID and a comma (,)
2. # followed by the second element’s ID
3. If more elements are to be added, add a comma after the second name and repeat as many times as needed.

The second method to accomplish this goal involves changing the (X)HTML code a little:

Notice that the <p> tags now have both an ID and a class, which is also perfectly acceptable and syntactically correct. Let’s take a look at a new example for a stylesheet now:

In the stylesheet excerpt above the unique ID’s of both elements are used to make the text within each element a certain color. Then a margin of 10 pixels is applied to both elements through the application of the class “standard”.

So what if I have the same (X)HTML code as defined above, and the stylesheet below?

You may have guessed it-the text color in both the elements with the ID of “welcome_message” and “mission_statement” will be displayed as green. Think about the rule earlier: “…the style that is applied to an element is decided upon by the most recently defined style.” Looking back at the example stylesheet above, this makes sense because the color green is the most recently defined style for the elements with the class “standard”. This rule has nothing to do with the identifier being a class or an ID:

The color of the text within the paragraph “mission_statement” will be green, but the text within the paragraph “welcome_message” will be black because it was the most recently defined style for that element.

Now what if you want some, but not all, style attributes from a certain class? Suppose we wanted our mission statement and the welcome message paragraph to have a margin of 10 pixels and to have green text. Additionally, the welcome message paragraph should have a border, but the mission statement paragraph does not need a border. How would this be done? Take a look at the example below:

Think about the order of definition for the styles, and what we want. Both the paragraphs with the class “standard” now have a margin of 10 pixels, a black border, and green text. However, the next style declaration says that the paragraph with the ID “mission_statement” should have no border, and since it is the most recently defined style for that element, there will be no border on the paragraph with the ID of “mission_statement”. However, there will still be a 10 pixel border, and the text of the paragraph will still be green. This is because even though there is a second declaration in the stylesheet that influences “mission_statement”, that declaration does not override any other previously defined styles for that element: the only styles that will be overwritten are the ones specified by the most recently defined style. In summary, the most recently defined style for any particular element is the style that will be applied to it, and no style of that element will be overwritten or deleted from that element unless explicitly specified by you.

Style attributes used in the examples explained:

Before finishing up this article I would like to quickly explain the different style attributes I used in my examples so that you can both understand them well, and go on to try them on your own.

• The first and most commonly used in my examples was the “color” attribute. This attribute controls the color of text. The syntax is as follows:color: color;In place of color you are able to put in the name of the color as I did in my examples-red, blue, green, yellow are just some examples- as well as hex codes for the colors. For example, putting #FFFFFF in for color would make the text white. #000000 would make the text black. You can find all kinds of color charts spread across the internet with hex codes for colors.
• The second style attribute used in my examples is that “margin” attribute, which is used to create space around the selected element. This space can be a set number of pixels, em’s (one em is equivalent to the width of the letter M), as well as a percentage of the screen space available. The last attribute available to the “margin” style is “auto”. I have personally had some difficulty with the “auto” attribute, but here’s what it is supposed to do: set the margin automatically so that it is equal on both sides, generally used for centering items in a page or another element.
• The third style attribute I utilized in my examples is the “border” attribute. The border attribute, as I’m sure you have guessed, creates a border around the element it is influencing. Here’s the syntax explained with an example:

This snippet of CSS would create a solid, black border that is 1 pixel wide around the matching element. You can change the “1px” to any width, “black” can be changed to any color or a hex value, and “solid” can be changed to any of the values listed below:

-dotted
-dashed
-double
-groove
-ridge
-inset
-outset

Go ahead and try out the different border styles to see what they look like, or you can head over to the W3schools page on it here.

As a side not for when you are debugging your webpages, applying a border can be a GREAT way to see how large your margin is around an element, how large the element is, or where the element is currently placed.

The plan was to end the article here, but there is one last thing I would like to talk about. Well, sort of two things, but it is an umbrella topic: browsers. I won’t go in to the argument of best browsers here-that’s for another post-so I’ll just come and say it right out: use Firefox when designing web pages. I don’t care if you decide to use Opera or Internet Explorer 4 for everything else, but use Firefox for designing webpages.

I’m sure some of you are screaming in indignation, some of your may be standing on your chair, pointing at the screen and declaring your allegiance to Konqueror or Maxthon, and others of you may have already gone to the download page and started the download. Calm down, sit back down in your chair, and for those of you that have already gone and download Firefox, I congratulate you. I personally do not use Firefox as my main browser-I use Google Chrome-but for designing webpages I always use Firefox. Why? Because, as of right now, Firefox is the most standard-compliant browser on the market, plain and simple.

Another reason to use Firefox is in order to have access to the massive number of addons available to users of Firefox. Some browsers are slowly realizing that addons are a big part of the user experience, and one of the reasons many people use Firefox so much and are accordingly attempting to begin their own addon projects, but Firefox is now and will always be the farthest ahead in this field.

Anyways, your Firefox download should be finishing in a few seconds if it hasn’t already, so go start the installer and install Firefox on your computer. When you’re done, come back, but don’t open this page in Firefox.

I would recommend that you split your screen between this window right about now and your Firefox window, but if you choose to keep this as your main window I won’t be too offended. Regardless of what you do, go to Firefox and click Tools–> Add-ons, or you can go to addons.mozilla.org. I would recommend the latter choice, as the website is easier to navigate than the Add-ons window.  Once the page is loaded, or the window is open, look for the addons I have listed below:

• Firebug (https://addons.mozilla.org/en-US/firefox/addon/firebug/)
• Web developer (Toolbar) (https://addons.mozilla.org/en-US/firefox/addon/firecookie/)
• Firecookie (if you are planning on working with cookies) (https://addons.mozilla.org/en-US/firefox/addon/web-developer/)

Firebug allows you to get a look at the HTML and CSS behind a webpage in realtime, something that is very helpful when working with CSS. The great advantage of Firebug, in my opinion, is that it allows you to change the CSS for the page in realtime, without needing to reload the page. The changes you make to the CSS will not be saved, but this feature is great for finding exactly how much of a margin you need, what kind of border looks best, of the best color background for an element. Firebug also makes it possible to add new CSS elements, as well as remove existing one. All changes are lost when the page is reloaded.

Web Developer’s main strength is in the error console it provides, in my opinion, which notifies you if there is an error in your (X)HTML document, your CSS, or your JavaScript, as well as giving a line number and highlighting the area that is producing the error should you so desire. There are a host of other features included in the Web Developer toolbar though, such as a ruler for measuring on-screen distances as well as many other useful features.

Firecookie is an addon for Firebug that allows you to view and edit cookie name’s and values, and it thus really only useful if you are working with cookies.

Alright then, I think that’s it. Here’s a quick summary of what we talked about:· What HTML is and how it compares to XHTML· Basics HTML pages, as well as basic XHTML pages· Basic CSS· Advances CSS concepts· Editors for writing and working with HTML and CSS· Testing and tweaking your webpage in FirefoxI realize that I did promise to cover websites to host your new site at, but that is too broad a topic to cover alongside the 21 pages of content that I have already written here. The third article in this series, then, will be on hosting websites: blogs as well as places to host your website, all for free because I’m cheap.

Resources: (listed in no particular order)

http://en.wikipedia.org/wiki/HTML

http://en.wikipedia.org/wiki/CERN

http://en.wikipedia.org/wiki/Ted_Nelson

http://ei.cs.vt.edu/~wwwbtb/book/chap13/where.html

http://www.walthowe.com/navnet/history.html

http://www.ibiblio.org/pioneers/baran.html

http://www.davesite.com/webstation/net-history.shtml

http://www.w3schools.com/html/html_head.asp

http://www.w3schools.com/xhtml/xhtml_dtd.asp

http://www.w3schools.com/xhtml/xhtml_syntax.asp

http://www.w3schools.com/xhtml/xhtml_html.asp

http://www.w3.org/QA/Tips/Doctype

http://www.w3schools.com/tags/tag_link.asp

http://www.w3schools.com/tags/att_input_type.asp

http://www.w3schools.com/tags/default.asp

http://htmlhelp.com/tools/validator/doctype.html

http://www.elizabethcastro.com/html/extras/doctypes.html