HTML Intermediate Tutorial
HTML Intermediate Tutorial
Hello This is the intermediate tutorial starting off from where ___Godlike___ left off...
HTML is all about applying meaning to content. Whereas most HTML tags apply meaning (p makes a paragraph, h1 makes a heading etc.), the span and div tags apply no meaning at all, which might sound about as useful as a foam hammer, but they are actually used quite extensively in conjunction with CSS.
They are used to group a chunk of HTML and hook some information on to that chunk, most commonly with the attributes class and id to associate the element with a class or id css selector.
The difference between span and div is that a span element is in-line and usually used for a small chunk of in-line HTML whereas a div (division) element is block-line (which is basically equivalent to having a line-break before and after it) and used to group larger chunks of code.
[HTML]<div id="scissors">
<p>This is <span class="paper">crazy</span></p>
</div> [/HTML]
div and especially span shouldn't actually be used that often. Whenever there is a sensible alternative that should be used instead. For example, if you want to e***asize the word 'crazy' and the class 'paper' is bold, then the code might look like this:
[HTML]<div id="scissors">
<p>This is <strong class="paper">crazy</strong></p>
</div> [/HTML]
This is also from another website so no credits go to me
It is very important (if you want the largest number of readers to be able to access your pages) that you keep in mind the basic fact of Web authoring Don't become so emotionally attached to your page layout that sight of it in a browser with a default font different than yours (or on a screen smaller than yours) will cause palpitations. It is ok, certainly, to be that attached to your content, but this is a different thing altogether. Working with the Web for any length of time will either teach you this lesson, or you will quit working with the Web.
In addition to keeping this basic idea in mind always, here are some more specific thoughts to ponder:
Some computer users, due to cost and other considerations, use text-only browsers. By definition, they can't see your images, of course. Text browsers may also have trouble with tables, so be careful about using tables for layout. Older versions of some browsers didn't display tables at all. The newer incarnations can display them, but they might not be lined up just right. Frames, understandably, cause text browsers a lot of difficulty as well.
But writing with text-only browsers in mind not only means you are looking out for those unable to afford color monitors. It also means that people who turn off the images in their browsers to speed up page loading will not be able to access your content, either. Not to mention those ahead-of-the-curve types with reader-software installed on their laptop so that they can "listen" to the Web as they drive. People with different kinds of disabilities, too, require special programs (such as text-to-speech) that may work better in a text-only mode.
Even users with the same version of the same browser may see very different versions of your pages. Some people use laptops with small screens, setting their default fonts small so they don't have to scroll so much. If you specify an even smaller font, your words may very well be illegible to these readers. Conversely, folks with vision problems might very well set their default font rather large—when you make it display even larger, they may be down to a few words per screen. Colors can also cause unexpected problems. Users with color-blindness or perhaps just different color preferences may set their default background color to something you would consider odd. Using different colored fonts on your pages might make text unreadable on some backgrounds.
Don't forget, too, that users can resize their browser windows if they like, scrunching up or spreading out your carefully calibrated design.
All of the foregoing is not to say that you shouldn't design pages that are aesthetically pleasing to you. Have a few pages in your directory that are fun to make and look at, too, as places to try out wild ideas and display weird colors and graphics. But when you're trying to convey information to others, try to keep in mind at least an idea of the variety of circumstances under which your pages might be seen. Try to make sure they're understandable as well as visible in as many different environments as you can.
You can find more information at the Anybrowser pages, and some good general points on accessibility are discussed in the Web Design Group's accessability. The Center for Applied Special Technology offers Bobby, which will check your pages for their accessibility to people with disabilities. If this all sounds like being a good Web citizen, well, that's what it is. As well as another segue to my last big picture area, where I'm putting thoughts that didn't seem to fit anywhere else.
HTML that works may not be "good" HTML. This is true because what works in one browser may not in another, or in another version of the same one. This is a difficult concept to grasp, especially if all you ever see is Explorer. And if you plan only to construct a page or two for limited personal use, it's probably not too important that you try. But if you get into this new kind of publishing in a big way, hoping your pages will become famous throughout Web-land, you should at least be aware of what is and isn't proper.
To have your coding checked out for propriety, you can have your pages validated. Validation generally means checking for compliance with HTML standards. There are several of these validation programs available, and some editors also automatically do some validation.
A few general hints might be all you want or need to know on this subject, though. For one thing, try to use tags that convey the meaning of what you are trying to convey, rather that just the appearance. This is where the argument between <em> and <i> (and <strong> and <b>) comes in. The two types of tags are called either logical/structural or physical/presentation. All the web experts I've read on this subject prefer the first kind of tags over the second. <i> and <b>—physical/presentation tags—specify specific fonts, whereas <em> and <strong>—logical/structural—let the browser decide how to display the marked text. If an italic or bold font is not available, it may be programmed to do something else to the text, like change its color. Or if the browser is one that "reads" the content (as in a device for the visually impaired, or for people driving their cars) a description of how the text looks wouldn't be relevant; but the meaning of e***asis can be conveyed by the "voice" of the reader.
That said, however, it seems that simple tags like these display just fine in the major browsers. And if you look at the code for my pages, I have always used <b>, and divide my time about evenly between <em> and <i>. And the HTML police haven't been kicking in my door. But I feel that I would be remiss on a page such as this if I didn't at least mention this issue. Certainly, when you're typing "raw" HTML, <b> comes out a lot faster than <strong>, and it's perfectly ok to use it. But if your editor puts in the latter, at least now you'll know what it means.
XHMTL, the current standard, requires some other, minor, differences from older HTML standards. The most important are:
Tags you see in Websites
This part will tell you what they mean and do...
<!DOCTYPE>
Definition
The doctype declaration should be the very first thing in an HTML document, before the <html> tag.
The doctype declaration is not an HTML tag; it is an instruction to the web browser about what version of the markup language the page is written in.
The doctype declaration refers to a Document Type Definition (DTD). The DTD specifies the rules for the markup language, so that the browsers can render the content correctly.
<!--...-->
The comment tag is used to insert a comment in the source code. A comment will be ignored by the browser. You can use comments to explain your code, which can help you when you edit the source code at a later date.
You can also store program-specific information inside comments. In this case they will not be visible for the user, but they are still available to the program. A good practice is to comment the text inside scripts and style elements to prevent older browsers, that do not support scripting or styles, from showing it as plain text.
<center>
Definition (By Me)
Centre Texts like
The <link> tag is most used to link to style sheets.
Like the centre tag this is also supported by major web viewers
ISO Language Codes
The HTML lang attribute can be used to declare the language of a Web page or a portion of a Web page. This is meant to assist search engines and browsers.
According to the W3C recommendation you should declare the primary language for each Web page with the lang attribute inside the <html> tag, like this:
[HTML]<html lang="en">
...
</html>[/HTML]
Hope you enjoyed this tutorial and it may not be as long as the other tuts but is still as helpful
HTML is all about applying meaning to content. Whereas most HTML tags apply meaning (p makes a paragraph, h1 makes a heading etc.), the span and div tags apply no meaning at all, which might sound about as useful as a foam hammer, but they are actually used quite extensively in conjunction with CSS.
They are used to group a chunk of HTML and hook some information on to that chunk, most commonly with the attributes class and id to associate the element with a class or id css selector.
The difference between span and div is that a span element is in-line and usually used for a small chunk of in-line HTML whereas a div (division) element is block-line (which is basically equivalent to having a line-break before and after it) and used to group larger chunks of code.
[HTML]<div id="scissors">
<p>This is <span class="paper">crazy</span></p>
</div> [/HTML]
div and especially span shouldn't actually be used that often. Whenever there is a sensible alternative that should be used instead. For example, if you want to e***asize the word 'crazy' and the class 'paper' is bold, then the code might look like this:
[HTML]<div id="scissors">
<p>This is <strong class="paper">crazy</strong></p>
</div> [/HTML]
This is also from another website so no credits go to me
Image Maps are a good tool when you wish to use a graphical navigation approach. If you have a chart, or a map, or wish to use a graphical toolbar, then image maps are your solution. Be careful not to overuse Image Maps, or to use an image map when it is not really necessary. Maps are usually larger graphics, thus they take longer to download. Also, some users might have images turned off, or may be using a text browser. It is a good idea to have alternate text links for those users who don't display graphics.
There are two types of Image Maps, Client Side and Server Side. With client site image maps, the coordinates are defined in the HTML code. With server side image maps, the coordinates are stored in a text file on the web server. The server communicates the coordinates to the browser. Client side image maps are easily the most common.
Today, there are several image map creation utilities that it is becoming almost unnecessary to learn the code. Many of these utilities will map the image for you, and other programs, such as Macromedia's Dreamweaver, allow you to define the coordinates in the program, and it generates the HTML code for you. MapEdit for Windows is a good image map program.
There are two types of Image Maps, Client Side and Server Side. With client site image maps, the coordinates are defined in the HTML code. With server side image maps, the coordinates are stored in a text file on the web server. The server communicates the coordinates to the browser. Client side image maps are easily the most common.
Today, there are several image map creation utilities that it is becoming almost unnecessary to learn the code. Many of these utilities will map the image for you, and other programs, such as Macromedia's Dreamweaver, allow you to define the coordinates in the program, and it generates the HTML code for you. MapEdit for Windows is a good image map program.
My bit
Now as the other paragraph said "Macromedia's Dreamweaver"
Now as the other paragraph said "Macromedia's Dreamweaver"
Definition
Code:
Although a hybrid WYSIWYG and code-based web design and development application, Dreamweaver's WYSIWYG mode can hide the HTML code details of pages from the user, making it possible for non-coders to create web pages and sites. One criticism of this approach is that it has the potential to produce HTML pages whose file size and amount of HTML code is larger than an optimally hand-coded page would be, which can cause web browsers to perform poorly. This can be particularly true because the application makes it very easy to create table-based layouts. Some web site developers criticized Dreamweaver for producing code that often did not comply with WC3 standards, though recent versions have been more compliant. Dreamweaver 8.0 performed poorly on the Acid2 Test, developed by the Web standards project. Adobe has focused on support for standards-based layout in recent and current versions of the application, including the ability to convert tables to layers. Dreamweaver allows users to preview websites in locally-installed web browsers. It also has site management tools such as FTP/SFTP and WebDav file transfer and synchronization features, the ability to find and replace lines of text or code by search terms and regular expressions across the entire site, and a templating feature that allows single-source update of shared code and layout across entire sites without server-side includes or scripting. The behaviours panel also enables use of basic JavaScript without any coding knowledge, and integration with Adobe's Spry AJAX framework offers easy access to dynamically-generated content and interfaces. Dreamweaver can use third-party "Extensions" to extend core functionality of the application, which any web developer can write (largely in HTML and Javascript). Dreamweaver is supported by a large community of extension developers who make extensions available (both commercial and free) for most web development tasks from simple rollover effects to full-featured shopping carts. Dreamweaver, like other HTML editors, edits files locally then uploads them to the remote web server using FTP, SFTP, or WebDAV. Dreamweaver CS4 now supports the subversion version control system.
-.- Boring Notepad FTW!
No back to my part
Dreamweaver is supposedly easier to make websites in but frankly I think even Word kicks it butt
Writing For All Browsers
It is very important (if you want the largest number of readers to be able to access your pages) that you keep in mind the basic fact of Web authoring Don't become so emotionally attached to your page layout that sight of it in a browser with a default font different than yours (or on a screen smaller than yours) will cause palpitations. It is ok, certainly, to be that attached to your content, but this is a different thing altogether. Working with the Web for any length of time will either teach you this lesson, or you will quit working with the Web.
In addition to keeping this basic idea in mind always, here are some more specific thoughts to ponder:
Some computer users, due to cost and other considerations, use text-only browsers. By definition, they can't see your images, of course. Text browsers may also have trouble with tables, so be careful about using tables for layout. Older versions of some browsers didn't display tables at all. The newer incarnations can display them, but they might not be lined up just right. Frames, understandably, cause text browsers a lot of difficulty as well.
But writing with text-only browsers in mind not only means you are looking out for those unable to afford color monitors. It also means that people who turn off the images in their browsers to speed up page loading will not be able to access your content, either. Not to mention those ahead-of-the-curve types with reader-software installed on their laptop so that they can "listen" to the Web as they drive. People with different kinds of disabilities, too, require special programs (such as text-to-speech) that may work better in a text-only mode.
Even users with the same version of the same browser may see very different versions of your pages. Some people use laptops with small screens, setting their default fonts small so they don't have to scroll so much. If you specify an even smaller font, your words may very well be illegible to these readers. Conversely, folks with vision problems might very well set their default font rather large—when you make it display even larger, they may be down to a few words per screen. Colors can also cause unexpected problems. Users with color-blindness or perhaps just different color preferences may set their default background color to something you would consider odd. Using different colored fonts on your pages might make text unreadable on some backgrounds.
Don't forget, too, that users can resize their browser windows if they like, scrunching up or spreading out your carefully calibrated design.
All of the foregoing is not to say that you shouldn't design pages that are aesthetically pleasing to you. Have a few pages in your directory that are fun to make and look at, too, as places to try out wild ideas and display weird colors and graphics. But when you're trying to convey information to others, try to keep in mind at least an idea of the variety of circumstances under which your pages might be seen. Try to make sure they're understandable as well as visible in as many different environments as you can.
You can find more information at the Anybrowser pages, and some good general points on accessibility are discussed in the Web Design Group's accessability. The Center for Applied Special Technology offers Bobby, which will check your pages for their accessibility to people with disabilities. If this all sounds like being a good Web citizen, well, that's what it is. As well as another segue to my last big picture area, where I'm putting thoughts that didn't seem to fit anywhere else.
Proper HTML
HTML that works may not be "good" HTML. This is true because what works in one browser may not in another, or in another version of the same one. This is a difficult concept to grasp, especially if all you ever see is Explorer. And if you plan only to construct a page or two for limited personal use, it's probably not too important that you try. But if you get into this new kind of publishing in a big way, hoping your pages will become famous throughout Web-land, you should at least be aware of what is and isn't proper.
To have your coding checked out for propriety, you can have your pages validated. Validation generally means checking for compliance with HTML standards. There are several of these validation programs available, and some editors also automatically do some validation.
A few general hints might be all you want or need to know on this subject, though. For one thing, try to use tags that convey the meaning of what you are trying to convey, rather that just the appearance. This is where the argument between <em> and <i> (and <strong> and <b>) comes in. The two types of tags are called either logical/structural or physical/presentation. All the web experts I've read on this subject prefer the first kind of tags over the second. <i> and <b>—physical/presentation tags—specify specific fonts, whereas <em> and <strong>—logical/structural—let the browser decide how to display the marked text. If an italic or bold font is not available, it may be programmed to do something else to the text, like change its color. Or if the browser is one that "reads" the content (as in a device for the visually impaired, or for people driving their cars) a description of how the text looks wouldn't be relevant; but the meaning of e***asis can be conveyed by the "voice" of the reader.
That said, however, it seems that simple tags like these display just fine in the major browsers. And if you look at the code for my pages, I have always used <b>, and divide my time about evenly between <em> and <i>. And the HTML police haven't been kicking in my door. But I feel that I would be remiss on a page such as this if I didn't at least mention this issue. Certainly, when you're typing "raw" HTML, <b> comes out a lot faster than <strong>, and it's perfectly ok to use it. But if your editor puts in the latter, at least now you'll know what it means.
XHMTL, the current standard, requires some other, minor, differences from older HTML standards. The most important are:
- Non-empty elements must have an end tag. This applies to <p>, the most commonly not closed element in older HTML. So each paragraph should be begun with a <p> tag and should end with a </p> tag. I have tried to get Dreamweaver to update all my non-closed <p> tags, but there might still be some in these pages. But do as I say, not as I used to do!
- Empty elements must be closed. The two most commonly used of these elements are <br>, <img>, and <hr>. This is the way this should be done: <br /> and <hr /> and <img src="xxx.gif" alt="xxx" /> . Notice that there are spaces in between the letters of the element tags, or attributes, and the closing bracket.
- All elements should be in lower case. Again, I will ask Dreamweaver to update all my old caps tags (which my original editor, AOLPress, did by default) but it may miss some.
Tags you see in Websites
This part will tell you what they mean and do...
<!DOCTYPE>
Definition
The doctype declaration should be the very first thing in an HTML document, before the <html> tag.
The doctype declaration is not an HTML tag; it is an instruction to the web browser about what version of the markup language the page is written in.
The doctype declaration refers to a Document Type Definition (DTD). The DTD specifies the rules for the markup language, so that the browsers can render the content correctly.
<!--...-->
The comment tag is used to insert a comment in the source code. A comment will be ignored by the browser. You can use comments to explain your code, which can help you when you edit the source code at a later date.
You can also store program-specific information inside comments. In this case they will not be visible for the user, but they are still available to the program. A good practice is to comment the text inside scripts and style elements to prevent older browsers, that do not support scripting or styles, from showing it as plain text.
<center>
Definition (By Me)
Centre Texts like
This
This HTML tag is supported by all major web viewers
<link>
The <link> tag defines the relationship between a document and an external resource.The <link> tag is most used to link to style sheets.
Like the centre tag this is also supported by major web viewers
ISO Language Codes
The HTML lang attribute can be used to declare the language of a Web page or a portion of a Web page. This is meant to assist search engines and browsers.
According to the W3C recommendation you should declare the primary language for each Web page with the lang attribute inside the <html> tag, like this:
[HTML]<html lang="en">
...
</html>[/HTML]
Hope you enjoyed this tutorial and it may not be as long as the other tuts but is still as helpful
I think we put some intermediate stuff in the advanced section... Apologies to everyone
Similar Threads
- 2Last post
- 2Last post
- 3Last post
- 0Last post
- 0Last post