Docstoc

HTML_Advanced

Document Sample
HTML_Advanced Powered By Docstoc
					HTML Advanced Guide
htmldog.com
The aim of the HTML Advanced Guide is to show how to fully exploit the
features of HTML and how to optimize it for accessibility.

Because the HTML Beginner's Guide and HTML Intermediate Guide take the
standpoint of using the latest standard of HTML (XHTML 1.0+), some aspects
of this guide may be unfamiliar to a lot of people who haven't read through
the Beginner's and Intermediate guides, which is why there is a Standards
Recap page. In general though, the pages in this section assume that you
know the ins and outs of HTML and want to exploit it to its full potential.



Standards Recap
This page is for those who know HTML, but might be unaware of the
standards involved in future-proof XHTML and the philosophy behind the
separation of meaning and presentation.

Separating meaning and presentation
HTML was never meant to be used for presentation, but user-agents
incorporated elements that formatted text and developers found ways to
manipulate layout. With the power of CSS it is now no longer necessary to
style using HTML and meaning (HTML) can now be completely separated
from presentation (CSS).

There are a number of benefits to this - it should greatly decrease file
sizes, it has the flexibility of a central style sheet that applies to the entire
website rather than an individual page and it should also produce pages of
much greater accessibility.

Following this philosophy basically means you shouldn't style anything within
the HTML. Tags such as font or attributes such as bgcolor should not be
used. Even the border attribute inside an img tag is no longer valid in XHTML
1.1. This shouldn't be a problem - there is no styling that can be done in
HTML that can't be done, and done better, with CSS.

It isn't just about taking away the presentation from HTML, the application of
meaning means specific HTML tags should be used when appropriate. For
example, h1, h2 etc. should be used for headings - you should not just use
CSS to make fonts larger.

A good guide is to see if a visual browser, with its default styling, presents
the document well without a style sheet.
Tables should not be used for layout - tables are designed to display
tabular data. This is perhaps the most difficult technique for experienced
HTMLer's to get used to as it completely changes the way the HTML has
traditionally been structured in the past. This approach greatly reduces the
size of the page and, due to the resulting linear code, it becomes much more
accessible.

Read the Layout page in the CSS Advanced Guide for more on this.

Tags
In XHTML all tags should be lowercase and must be closed. For those tags
that do not have closing tags (such as br and img), they must close
themselves with a ' /' at the end (such as <br />). Note that there should
be a space before the forward-slash.

The markup must be well formed, with elements properly nested (for
example, <strong><em>this</em></strong>, not
<strong><em>this</strong></em>).

All documents must have html, head, title and body elements. They must
also start with a document type declaration.

The body of the document should start with p, h1, h2, h3, h4, h5, h6, div,
pre, address, ins or del.

Attributes
All attributes must also be lowercase and their values in quotation marks.

Minimized attributes are not allowed (such as <input type="checkbox"
checked />). Traditionally minimized attributes must be given the value that
is the same as the name of the attribute (such as <input type="checkbox"
checked="checked" />).

The name attribute is no longer valid (except in form elements) and should be
replaced with id.

The target attribute is not a valid attribute. Praise be. It was daft anyway.

The alt attribute in the img tag is compulsory.

Accessibility
The reasons for making web pages accessible to users with disabilities are
quite self-evident. Not only is it moralistic, but it will also benefit our future
as web users grow older and the acuteness of the senses degenerates.
Accessibility isn't just about accommodating people with severe disabilities, it
is about making it easier for a great number of people with minor
(predominantly visual) impairments.

There are increasing legal implications such as the introduction of 'Section
508' in the US that enforces certain accessibility initiatives and in the UK, all
government websites must reach a specified degree of accessibility. How
long until similar legislation is applied to general commercial websites?

If you follow the above practices, your HTML should already be highly
accessible to users with disabilities. There are further initiatives that can
make your web pages even more accessible (for example, see the Accessible
Links and Accessible Forms pages) and it really isn't that difficult.



Accessible Links
This page deals with a number of ways that links can be made more
accessible.

Tabbing
Users who do not or cannot use pointing devices can 'tab' through links, and
as such, links should be in a logical tabbing order. The tabindex attribute
allows you to define this order although if the HTML is linear, as it should be,
a logical tabbing order should automatically fall into place.

Accesskeys
Accesskeys allow easier navigation by assigning a keyboard shortcut to a link
(which will usually gain focus when the user presses 'Alt' or 'Ctrl' + the
accesskey). For users who do not use pointing devices, this is a much quicker
and easier way to navigate than tabbing through links.

It isn't necessary to put accesskeys on all links, but it is a good idea to apply
them to primary navigation links.

<a href="somepage.html" accesskey="s">Some page</a>

     Note
     The trouble with accesskeys is that there is often no way the user can
     find out what they are (unless they look at the source code). JAWS, the
     most popular screen reader out there will read these accesskeys out
     loud, but to take full advantage of them, you will probably want to make
     them more explicit.
     You could apply a method similar to the 'skip navigation' link technique
     (see below), or opt for a separate page explaining the accessibility-
     related functionality of your site, including the accesskeys. A method
     that is growing in popularity is to underline a corresponding letter in the
     link, similar to the method used in the menus of most Windows
     applications.

     See the article in A List Apart for more information at
     http://www.alistapart.com/stories/accesskeys/.

Link titles
It is a good idea to add the title attribute, which will pop up a description of
where the link will take the user, so improving navigation.

If the link is used to execute Javascript, it is also beneficial for explaining
what should (but won't) happen for users that do not have Javascript
functionality.

<a href="#" onclick="opennastypopup()"
onkeypress="opennastypopup()" title="Open a nasty Javascript pop-
up window">Monster</a>

Popups
Talking of Javascript popups, if you will insist on using them, or more likely
someone is telling you to use them, you can make things much more
accessible by using onkeypress as well as onclick. Also, if you include a
normal page in the value of the href attribute of the link and return false
from a function that launches the popup, if the user does not have
Javascript, a normal page will load anyway. For example:

<script type="text/javascript">
    function opennastypopup() {
         window.open("monster.html", "",
         "toolbar=no,height=100,width=200");
         return false;
    }
</script>
...
<a href="monster.html" onclick="return opennastypopup()"
onkeypress="return opennastypopup()">Monster</a>

Adjacent links
Adjacent links should be separated by more than spaces, so that they can be
discerned by screen readers.
This can be done by placing characters in-between links (such as a pipe -
'link | link') or surrounding it by characters (such as square brackets -
'[link] [link]'). It is also a good idea to put navigation links within lists.
These can then be styled with CSS to be displayed however you choose, even
side-by-side (using display: in-line).

Skipping navigation
You should give users of screen readers an opportunity to skip the navigation
and go straight to the content. This is because if your navigation is consistent
(as it should be), a user does not need to go through the same information
on every page, especially if there is a lot of it. You can skip the navigation by
placing a link before it that skips directly to the content.

It might look something like this:

<div id="header">
<h1>The Heading</h1>
<a href="#content" accesskey="n">Skip navigation</a>
</div>
<div id="navigation">
<!--loads of navigation stuff -->
</div>
<div id="content">
<!--lovely content -->
</div>

Obviously, you do not want this link to be displayed in visual browsers, so
you can use CSS to render it invisible.

     Note
     This is a CSS tip, but is specific to 'Skipping navigation'. It involves the
     method to use to render the link invisible.

     The most obvious way would be to use display: none, but as some
     screen readers will pick up on this and not read the link, as intended,
     the 'Skip navigation' link must be displayed.

     It still doesn't have to be visible though - there's no point in showing it
     to visually able users. So instead of having a style containing display:
     none, you can set the width and height of the element to zero (width:
     0; height: 0; overflow: hidden;), which has the same visual effect
     but will be read by screen readers.
Mastering Text
There is still much overuse of the br tag when p should be used for
paragraphs, but it is generally accepted that p tags should be used to
represent paragraphs. By the same logic, there are a number of tags that
should be used to define certain text elements such as quotations,
abbreviations and computer code.

It should be kept in mind that although most browsers will render these tags
in various ways, the important point to remember is that it isn't what each
element looks like, but rather what meaning it applies.

Abbreviations and acronyms
abbr and acronym are used for abbreviations and acronyms respectively.

An abbreviation is a shortened form of a phrase. Very general. An acronym
however is an abbreviation made up of the initial letters (or parts of words)
of the phrase it is representing. So CSS is a valid acronym, whereas HTML
and XHTML are not (if 'Hypertext markup language' was an acronym, it
would be 'HML'. Similarly, XHTML would be EHML).

For optimum accessibility, the phrase that the acronym or abbreviation is
representing should be used in the title attribute.

<p>This web site is about <abbr title="HyperText Markup
Language">HTML</abbr> and <acronym title="Cascading Style
Sheets">CSS</acronym>.</p>

     Note
     For some baffling reason, Internet Explorer, the most common web
     browser, doesn't support the abbr tag. Luckily, a guy called Marek
     Prokop has developed a clever Javascript workaround for this.

     There is a lot of discussion about the use of abbreviation and acronym
     elements. Lars Holst provides perhaps the most detailed insight.



Mastering Tables
So you think you know how to make a table. Sure, you know the table, tr,
td and th tags, you've even got the rowspan and colspan attributes in your
pocket. You can make a really cute little plywood coffee table, but don't you
want to know how to make one of those polished solid wood, glass top dining
tables that can take the weight of an oversized elephant? You do? Oh joy.
The columns strike back
Table rows tend to make table columns look rather stupid. They do all the
work, as the table is built row by row, leaving the columns feeling quite
dejected.

Luckily for those eager columns though, the colgroup and col tags have
come to their rescue.

These tags allow you to define the table columns and style them as desired,
which is particularly useful if you want certain columns aligned or coloured
differently, as without this, you need to style individual cells.

Here is an example of these tags in use:

<table>
    <colgroup>
         <col />
         <col class="alternate" />
         <col />
    </colgroup>
    <tr>
         <td>This</td>
         <td>That</td>
         <td>The other</td>
    </tr>
    <tr>
         <td>Ladybird</td>
         <td>Locust</td>
         <td>Lunch</td>
    </tr>
</table>

The styles of the class 'alternate' will be applied to the second column, or the
second cell in every row.

You can also use the span attribute on either colgroup or col, in a similar
way to rowspan and colspan.

Using it with the colgroup tag will define the number of rows that the
column group will belong to, for example <colgroup span="2"></colgroup>
would group the first two columns. When span is used in colgroup, you
shouldn't then use col tags.

Using span in the col tag is more sensible, and could, for example, be
applied to the above example like this:
<table>
    <colgroup>
        <col />
        <col span="2" class="alternate" />
    </colgroup>
...

This would apply 'alternate' to the last two columns.

     Note
     Oh, but there had to be a catch, didn't there? Here it is: The only styles
     you can apply to columns are borders, backgrounds, width and
     visibility.

     Internet Explorer appears to behave much better than other browsers
     because it takes on board pretty much any CSS property, such as
     color, but, as it turns out, this is only because it acts in a mad wacky
     way. For a detailed explanation of this peculiar anomaly, let Ian Hixie
     explain.

Summary and Caption Interlude
A brief and easy accessibility consideration is to always apply a summary
and caption to the table.

A summary can be applied to a table using the summary attribute in the
opening table tag. This won't be displayed, but can aid in a non-visual
representation of a table.

The caption tag defines the caption straight after the opening table tag. It
will appear above the table by default, but can be placed top, right, bottom
or left with the caption-side CSS property, although IE won't take any
notice of this.

<table summary="The mating habits of locust, showing how many use
protection and how many have a cigarette afterwards">
    <caption>Locust mating habits</caption>
...

Headers, footers and the quest for the scrolling table
thead, tfoot and tbody allow you to separate the table into header, footer
and body. This is particularly useful for large tables and when printed for
example, the header and footer rows should appear on every page.

These elements must be defined in the order thead - tfoot - tbody and
would look like this:
<table>
<thead>
<tr>
     <td>Header 1</td>
     <td>Header 2</td>
     <td>Header 3</td>
</tr>
</thead>
<tfoot>
<tr>
     <td>Footer 1</td>
     <td>Footer 2</td>
     <td>Footer 3</td>
</tr>
</tfoot>
<tbody>
<tr>
     <td>Cell 1</td>
     <td>Cell 2</td>
     <td>Cell 3</td>
</tr>
...
</tbody>
</table>

You can make the tbody element scroll in Mozilla, by applying the style
overflow: auto; max-height: [whatever] to it. You will then see the
header and footer kept in place and a vertical scroll bar to the right of the
body. You should use the max-height property because IE doesn't recognise
it and so it is safer than using the height property, which IE would apply to
every row.

Note: Back to normal browser differences, this time IE doesn't have a clue
when it comes to headers and footers, and although it renders them in the
table, they will not appear at the top and bottom of every printed page, let
alone deliver the scrolling table.

     Note
     Be wary of using scrolling tables. Although they serve a very useful
     purpose, most users aren't used to them and may believe that the data
     presented above the line is the only data available.
Accessible Forms
Forms aren't the easiest of things to use for people with disabilities.
Navigating around a page with written content is one thing, hopping between
form fields and inputting information is another. Because of this, it is a good
idea to add a number of elements to the form.

Labels
Each form field should have its own label. The label tag sorts this out, with
a for attribute that associates it to a form element:

<form>
<label for="yourName">Your Name</label> <input type="text"
name="yourName" id="yourName" />
...

Labels have the added bonus of visual browsers rendering the labels
themselves clickable, putting the focus on the associated form field.

Note: name and id are both required - the name for the form to handle that
field and the id for the label to associate it to.

Field sets and legends
You can group fields, for example name (first, last, middle, title etc.) or
address (line 1, line 2, county, country, postal code, country etc.) using the
fieldset tag.

Within the field set, you can set a legend with the legend tag.

Note: Visual browsers tend to represent field sets with a border surrounding
them and legends breaking the left of the top border.

<form action="somescript.php" >
<fieldset>
<legend>Name</legend>
    <p>First name <input type="text" name="firstName" /></p>
    <p>Last name <input type="text" name="lastName" /></p>
</fieldset>
<fieldset>
    <legend>Address</legend>
    <p>Address <textarea name="address" ></textarea></p>
    <p>Postal code <input type="text" name="postcode" /></p>
</fieldset>
...
Option groups
The optgroup tag groups options in a select box. It requires a label
attribute, the value of which is displayed as a non-selectable pseudo-heading
preceding that group in the drop-down list of visual browsers.

<select name="country">
    <optgroup label="Africa">
         <option value="gam">Gambia</option>
         <option value="mad">Madagascar</option>
         <option value="nam">Namibia</option>
    </optgroup>
    <optgroup label="Europe">
         <option value="fra">France</option>
         <option value="rus">Russia</option>
         <option value="uk">UK</option>
    </optgroup>
    <optgroup label="North America">
         <option value="can">Canada</option>
         <option value="mex">Mexico</option>
         <option value="usa">USA</option>
    </optgroup>
</select>

Navigating fields
Like links, form fields (and field sets) need to be navigated to without the use
of a pointing device, such as a mouse. The same methods used in links to
make this task easier can be used on form elements - tab stops and access
keys.

The accesskey and tabindex attribute can be added to the individual form
tags such as input and also to legend tags.

<input type="text" name="firstName" accesskey="f" tabindex="1" />

For more about this, see the Accessible Links page.



Declarations
This page deals with the how to define a valid XHTML document.

Document type declarations
At the very top of your web pages, you need a document declaration. That's
right, you need it.
Without specifying a doctype, your HTML just isn't valid HTML and most
browsers viewing them will switch to 'quirks mode', which means they will
think that you don't know what the hell you're doing and make up their own
mind on what to do with your code. You can be the greatest HTML ninja ever
to have walked the earth. Your HTML can be flawless and your CSS simply
perfect, but without a document declaration, or a wrong document
declaration, your web pages can look like they were put together by a short-
sighted, one-eyed infant gibbon with learning difficulties.

The document declaration for XHTML 1.0 Strict looks like this:

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

The following is the document declaration for XHTML 1.1, which may seem
preferable, being the latest version of XHTML, but there are a few problems,
which will be explained in just a minute...

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

If you just can't let go of HTML 4 or if you've got some kind of Netscape 4
fetish, you can use XHTML 1.0 Transitional:

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

The only reason you should use this is if you have an unusual need to
accommodate older, rarely used browsers. Transitional XHTML 1.0 allows old
HTML 4 presentational elements that may result in better presentation in
browsers such as Netscape 4 but using such elements will be detrimental to
the efficiency and possibly accessibility of your web pages.

Finally, if you're one of those wacky people who use frames, the XHTML 1.0
Frameset document type declaration looks like this:

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

Note that the DOCTYPE tag is a bit of a rebel and demands to be written in
upper case and adorned with an exclamation mark. It also breaks the rules in
that it is the only tag that doesn't need closing.

Language declarations
You should identify the primary language of a document either through an
HTTP header or with the xml:lang attribute inside the opening html tag.
Although this is not necessary to produce a valid XHMTL document, it is an
accessibility consideration. The value is an abbreviation, such as 'en'
(English), 'fr' (French), 'de' (German) or 'mg' (Malagasy).

The declaration for a document with primarily English content for example
would look like this:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

After declaring a primary language, if you use languages other than that in
your content, you should further use the xml:lang attribute in-line (such as
<span xml:lang="de">HTML Hund</span>).

Content types
The media type and character set of an HTML document also needs to be
specified, and this is done with an HTTP header such as:

Content-Type: text/html; charset=UTF-8

The first part (in this example, the text/html bit) is the MIME type of the
file, and this lets the browser know what media type a file is and therefore
what to do with it. All files have some kind of MIME type. A JPEG image is
image/jpeg, a CSS file is text/css and the type generally used for HTML is
text/html.

The second part of the HTTP header (in this example, the UTF-8 bit) is the
character set.

Perhaps the easiest way to set an HTTP header (or mimic it) is to use an
'HTTP-equivalent' meta tag in the HTML, which would look something like
this:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-
8" />

Slightly more complicated, but preferable (due to it being a proper HTTP
header AND cutting down on HTML), is to send the header by using a
server-side scripting language. With PHP, you might use something like
this:

<? header("Content-Type: text/html; charset= UTF-8"); ?>

If you don't want to (or can't) use a server-side scripting language, you
might be able to go straight to the server with an '.htaccess' file. Most
servers (Apache compatible) can have a small text file with the file name
'.htaccess' that sits in the root directory and with the following line in it, you
can associate all files with the extension '.html' with a MIME type and
character set:
AddType text/html;charset=UTF-8 html

Character sets include 'ISO-8859-1' for many Western, Latin based
languages, 'SHIFT_JIS' for Japanese and 'UTF-8', a version of Unicode
Transformation Format, which provides a wide range of unique characters
used in most languages. Basically, you should use a character set that you
know will be recognised by your audience. Unless you are using a Latin-
based language (including English), where ISO-8859-1 can be used and is
mostly universally understood, you should use UTF-8 because it can display
most characters from most languages and is the safest code to use because
it will work on most people's computers.

You can read more about character sets elsewhere on the web.

     Note
     XHTML should be served by the MIME type application/xhtml+xml.
     That's what it is - an XML application. Unfortunately, most browsers
     don't have the first clue what this is. So it is generally accepted that it's
     ok to use the MIME type text/html. According to the W3C, and further
     highlighted by the Web Standards Project, flavours of XHTML 1.0 may
     be served as text/html, but XHTML 1.1 should not, which is why the
     examples across this site are XHTML 1.0 Strict, assuming a text/html
     MIME type. But you can (and perhaps should) serve the correct MIME
     type to those browsers that accept it with a bit of server-side fiddling.

     This site uses PHP to serve XHTML 1.1 with an application/xhtml+xml
     MIME type to those browsers that understand and render the type (such
     as Mozilla) and XHTML1.0 Strict with the text/html type to other
     browsers (such as IE). The script, placed at the top of the very top of
     every page looks a little something like this:

     <?
     if(stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")){
         header("Content-Type: application/xhtml+xml;
         charset=UTF-8");
         echo('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
         "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">');
     } else {
         header("Content-Type: text/html; charset=UTF-8");
         echo ('<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
         Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
         strict.dtd">');
     }
     ?>

     This checks to see if the browser accepts the application/xhtml+xml
     MIME type and if it does, that MIME type is sent and the XHTML1.1
     document type is written to the HTML. If the MIME type isn't recognised
then the text/html MIME type is sent and the XHTML1.0 Strict
document type is written in the HTML.

Other than peace of mind that you know you're doing the right thing
and preparing yourself for the way to do things in the future, the
immediate benefit of using this method is that Mozilla will treat your
files as XML applications and simply won't work if your XHTML isn't up to
scratch ie, isn't well formed. You can then debug without having to run
the document through a validator.

				
DOCUMENT INFO
Categories:
Tags:
Stats:
views:0
posted:9/28/2013
language:English
pages:15