About URLs

URLs Uniform Resource Locator, or URL, is a fancy name for address. It contains information about where a file is and what a browser should do with it. Each file on the Internet has a unique URL. The first part of the URL is called the scheme. It tells the browser how to deal with the file that it is about to open. The most common scheme you will see is HTTP, or Hypertext Transfer Protocol. It is used to access Web pages. The second part of the URL is the name of the server where the file is located, followed by the path that leads to the file and the file's name itself. Sometimes, a URL ends in a trailing forward slash with no file name given . In this case the URL refers to the default file in the last directory in the path (which generally corresponds to the home page), often called index.html or default.htm. Other common schemes are HTTPS, for secure Web pages; FTP (File Transfer Protocol) for downloading files; Mailto, for sending email; and File, for accessing files on a local hard disk or local file sharing networks. A scheme is generally followed by a colon and two forward slashes. Mailto and News are exceptions; these take only a colon. Notice that the File scheme uses three slashes. That's because the host, which in other schemes goes between the second and third slashes, is assumed to be the local computer. Always type schemes in lowercase letters. Absolute URLs URLs can be either absolute or relative. An absolute URL shows the entire path to the file, including the scheme, server name, the complete path, and the file name itself. An absolute URL is analogous to a complete street address, including name, street and number, city, state, zip code, and country. No matter where a letter is sent from, the post office will be able to find the recipient. In terms of URLs, this means that the location of the absolute URL itself has no bearing on the location of the actual file referencedwhether it is in a Web page on your server or on mine, an absolute URL will look exactly the same. When you're referencing a file from someone else's server, you'll always use an absolute URL. You'll also need to use absolute URLs for FTP sites, or any kind of URL that doesn't use an HTTP protocol. Absolute URLs vs. Relative URLs File name Absolute URL (can be used anywhere) Relative URL (only works in youarehere.html) index.html www.site.com/web/index.html index.html image.gif www.site.com/web/images/image.gif images/image.gif data.html www.site.com/info/data.html ../info/data.html homepg.html www.remote.com/pub/homepg.html (none: use absolute) info.html www.remote.com/bcn/info.html (none: use absolute) Relative URLs To give you directions to my neighbor's house, instead of giving her complete address, I might just say "it's three doors down on the right". This is a relative addresswhere it points to depends on where the information originates. With the same information in a different city, you'd never find my neighbor. In the same way, a relative URL describes the location of the desired file with reference to the location of the file that contains the URL itself. So, you might have the URL say something like "show the xyz image that's in the same directory as this page". The relative URL for a file that is in the same directory as the current page (that is, the one containing the URL in question) is simply the file name and extension. You create the URL for a file in a subdirectory of the current directory by typing the name of the subdirectory followed by a forward slash and then the name and extension of the desired file. To reference a file in a directory at a higher level of the file hierarchy, use two periods and a forward slash. You can combine and repeat the two periods and forward slash to reference any file on the same hard disk as the current file. Generally, for files on the same server, you should always use relative URLs. They're much easier to type and they make it easy to move your pages from a local system to a server. As long as the relative position of each file remains constant, the links will work correctly. One added advantage of relative URLs is that you don't have to type the schemeas long as it's HTTP.

Read More

Deciding between HTML, XHTML, and CSS:

Deciding between HTML, XHTML, and CSS:

While I don't recommend using proprietary extensionssince they leave out part of your audiencethere are a lot of other options. Here are some guidelines.

• The bigger the site, the more important it is that you use CSS and XHTML. The former makes it easy to apply, edit, and update formatting across the entire site; the latter gives your page the structure it needs to make sure it lasts into the future.
• Many companies and government agencies, including the U.S. government, require that your Web page fulfill specific accessibility requirements in order to make their sites available to people with disabilities. In these cases, you should adhere as closely as possible to XHTML strict, with CSS for formatting. And be sure to check the company's or agency's pertinent guidelines for details in your particular case.
• Large commercial sites that want to reach the widest audience may opt for transitional XHTML, taking advantage of some deprecated tags' practically universal support, while banking on XHTML's rock-solid stability. These kinds of sites will very likely shift to the more powerful CSS as their comfort level with it grows.
• Small or personal sites may want to take advantage of HTML's easy-going syntax along with CSS's powerful formatting and an occasional deprecated tag where necessary.
• My personal choice is to use XHTML and CSS and a bare minimum of deprecated tags.

XHTML considered dangerous? There are some who question the move to XHTML. The problem stems from the fact that in order for XHTML to be backwards compatible and work in older browsers, one small concession had to be made: it had to be sent from the server in a way that browsers already understood: labeled as html. The idea was that as browsers evolved, they would eventually be able to understand XHTML pages served as xhtml. Unfortunately, that just hasn't happened. As of mid 2006, Internet Explorer 7, which will most likely assume the #1 browser mantle from IE 6 once it comes out of beta, still cannot understand XHTML files served as xhtml. That means that designers can still not take advantage of XML's strength and even worse, according to Ian Hickson,, that pages written in XHTML and served as html can be more of a hindrance to the push toward standards then a help. He suggests that we should stick with HTML until browsers can serve xhtml. But then, of course, we're stuck with the snake who devours her own tail. Personally, I favor moving towards XHTML and its promise of standardization and power rather than sticking with HTML until some mythical future when browsers will lead the way toward standards. If we all write in XHTML now, it will be in the browser manufacturers' interest to support XHTML. And then we will all reap the benefits that it promises.

Read More

CSS and Browser Support

While XHTML and CSS are a powerful combination, there is one small wrench that has continued to plague Web designers: browser support. While it didn't seem to be much of a problem to add extensions willy-nilly, when it comes down to serious, full support of the specifications, no browser has yet been up to the task. However, it's important to note that they've come a long way.

Netscape 6, completely reformed from its extension-madness days, now boasts good CSS support. Too bad its user base is down to less than 1 percent. Firefox 1.5, the Open Source dynamo which rose from the ashes of Netscape's demise (and was even called Phoenix and Firebird early in its history), has excellent CSS support as does Opera 9, whose user base is expanding by leaps and bounds particularly in the handheld and mobile telephone markets. And Internet Explorer, currently the most used browser, has steadily improved its CSS support, although it still has a number of glaring bugs and what sometimes seem like arrogant and obstinate omissions.

All in all, most users use browsers that support CSS either well, or very well. While the number of users on legacy browsers a few years ago might have given folks pause before contemplating a switch to CSS, that number has dwindled below 5% (some say below 2%) and continues to fall. And even many of these are on Internet Explorer 5.5 whose support, though not stellar, was really not that bad.

In short, there's never been a better time to move confidently over to CSS.

Read More

The Browser Wars

Now imagine what would happen if each hotel and apartment building on Fifth Avenue staked out a bit of Central Park and put a fence around it, limiting access to its own residents. It's bad enough that those of us on park benches can only glimpse in to "exclusive" areas. But, there's also the problem that folks from one hotel can't get to the piece of park that belongs to the other hotel. Instead of a rich, public resource, teeming with roller-bladers, hot dog carts, and strolling elders, the park is divided into small, sterile, isolated lots.

In 1994, Netscape Communications put up the first fences on the Web in the so-called browser wars. In order to attract users, they threw universality to the wind and created a set of extensions to HTML that only Netscape could handle. For example, Web surfers using Netscape could view pages with colored text, photographs, and other improvements. Surfers with any other browser would get errors and funny-looking results. Or nothing at all.

But people liked those extensions so much that they flocked to Netscape's "hotel". By 1996, it had become the most popular computer program in the world. Microsoft started fencing in its own chunk of the Web. Again, to attract users they added non-standard extensions that only Internet Explorer, Microsoft's browser, could recognize.

According to The Web Standards Project, founded by a coalition of top-flight designers disgusted with the increasing fragmentation of the Web, at the height of the browser wars, Web designers were wasting an incredible 25% of their time devising workarounds for proprietary tags, writing multiple versions of pages to satisfy each browser, and simply educating their clients about the impossibility of creating certain effects for all browsers. It was a mess.

Read More

XHTML vs. HTML: What Should You Use?

And now an admission. I liked HTML. I thought it was great that you didn't have to obsess over punctuation. Maybe I'm just lazy, but I honestly believe that the Web's popularity is due in part to the fact that browsers cut us all some slack. It made it easy to write Web pages, and so all of us did. Now, a couple of billion pages later, perhaps it's time to change our ways. Or perhaps not. There are a lot of people out there that will tell you that HTML is evil and XHTML is the only solution. I think that's silly. XHTML is a great improvement over HTML. It's stronger, more flexible, more powerful, more likely to be supported in the future, and can be expanded to fit any need. But I'll tell you something. Sometimes you don't need to fill every need. Sometimes, you just want to publish a simple page without stressing over every last quotation mark. Luckily there is a lot of middle ground. There are actually three standard flavors of both HTML and XHTML. The first, called transitional, allows the use of the deprecated tags. The second, called strict, prohibits the use of any of the deprecated tags. The third flavor, frameset, allows both the use of deprecated tags and the use of frames, which have fallen into such disfavor that I've moved the chapter that describes them out of the book and onto my Web site (. You can combine each of these flavors in varying degrees with CSS. Which combination you choose may depend on several factors. (Keep reading.) Deciding between HTML, XHTML, and CSS: While I don't recommend using proprietary extensions since they leave out part of your audience there are a lot of other options. Here are some guidelines. The bigger the site, the more important it is that you use CSS and XHTML. The former makes it easy to apply, edit, and update formatting across the entire site; the latter gives your page the structure it needs to make sure it lasts into the future. Many companies and government agencies, including the U.S. government, require that your Web page fulfill specific accessibility requirements in order to make their sites available to people with disabilities. In these cases, you should adhere as closely as possible to XHTML strict, with CSS for formatting. And be sure to check the company's or agency's pertinent guidelines for details in your particular case. Large commercial sites that want to reach the widest audience may opt for transitional XHTML, taking advantage of some deprecated tags' practically universal support, while banking on XHTML's rock-solid stability. These kinds of sites will very likely shift to the more powerful CSS as their comfort level with it grows. Small or personal sites may want to take advantage of HTML's easy-going syntax along with CSS's powerful formatting and an occasional deprecated tag where necessary. My personal choice is to use XHTML and CSS and a bare minimum of deprecated tags. XHTML considered dangerous? There are some who question the move to XHTML. The problem stems from the fact that in order for XHTML to be backwards compatible and work in older browsers, one small concession had to be made: it had to be sent from the server in a way that browsers already understood: labeled as html. The idea was that as browsers evolved, they would eventually be able to understand XHTML pages served as xhtml. Unfortunately, that just hasn't happened. As of mid 2006, Internet Explorer 7, which will most likely assume the #1 browser mantle from IE 6 once it comes out of beta, still cannot understand XHTML files served as xhtml. That means that designers can still not take advantage of XML's strength and even worse, according to Ian Hickson, that pages written in XHTML and served as html can be more of a hindrance to the push toward standards then a help. He suggests that we should stick with HTML until browsers can serve xhtml. But then, of course, we're stuck with the snake who devours her own tail. Personally, I favor moving towards XHTML and its promise of standardization and power rather than sticking with HTML until some mythical future when browsers will lead the way toward standards. If we all write in XHTML now, it will be in the browser manufacturers' interest to support XHTML. And then we will all reap the benefits that it promises.

Read More

HTML Embedding Multimedia

                    You can add music or video into your web page. The easiest way to add video or sound to your web site is to include the special HTML tag called <embed>. This tag causes the browser itself to include controls for the multimedia automatically. You do not need to have any ActiveX, Java VM, VBscript or JavaScript to support this <embed> tag.
t's also a good idea to include the <noembed> tag to support browsers which don't recognize the <embed> tag. You could, for example, use <embed> to display a movie of your choice, and <noembed> to display a single JPG image.
Here is a simple example to play embed a midi file:

<embed src="/html/yourfile.mid" width="100%" height="60" > <noembed><img src="yourimage.gif" ></noembed> </embed>

This will produce following result:
You can put any media file in src attribute. You can try it yourself by giving various files.

Attributes:

Following is the list of important attributes for <embed> element.

• align - Determines how to align the object. It takes either center, left or right.
• autostart - Indicates if the media should start automatically. Netscape default is true, Internet Explorer is false.
• loop - Specifies if the sound should be played continuously (set loop to true), a certain number of times (a positive value) or not at all (false). This is supported by Netscape only.
• playcount - Specifies the number of times to play the sound. This is alternat option for loop if you are usiong IE.
• hidden - Defines if the object shows on the page. A false value means no and true means yes.
• height - Height of the object in pixels or en.
• width - Width of the object in pixels or en.
• pluginspage - Specifies the URL to get the plugin software.
• name - A name used to reference the object.
• src - URL of the object to be embedded. This can be any recognizable by the user's browser. It could be .mid, .wav, .mp3, .avi and so on).
• volume - Controls volume of the sound. Can be from 0 (off) to 100 (full volume). This attribute is supported by Netscape only.

HTML - Video Media Types

Flash movies (.swf), AVI's (.avi), and MOV's (.mov) file types are supported by the embed tag.

• .swf files - are the file types created by Macromedia's Flash program.
• .wmv files - are Microsoft's Window's Media Video file types.
• .mov files - are Apple's Quick Time Movie format.
• .mpeg files - are movie files created by the Moving Pictures Expert Group.

Here is a simple example to play a flash file.

<embed src="/html/yourfile.swf" width="100%" height="250" > <noembed><img src="yourimage.gif" alt="yourimage.gif" /></noembed> </embed>

This will produce following result. Select a picture and paint it using virtual bursh.

Background Audio - The <bgsound> Element:

You can use the <bgsound> tag to play a soundtrack in the background. This tag is for Internet Explorer documents only. Other browsers ignore the tag. It downloads and plays an audio file when the host document is first downloaded by the user and displayed. The background sound file also will replay whenever the user refreshes the browser display.
This tag is having only two attributes loop and src. Both these attributes have same meaning as explained above.
Here is a simple example to play a small midi file:

<bgsound src="/html/yourfile.mid" > <noembed><img src="yourimage.gif" alt="yourimage.gif" /></noembed> </bgsound>

This will produce blank screen. This tag does not display any component and remains hidden.
Currently, Internet Explorer can handle three different sound format files: wav, the native format for PCs; au, the native format for most Unix workstations; and MIDI, a universal music-encoding scheme.

HTML Object tag:

HTML 4 introduces the <object> element, which offers an all-purpose solution to generic object inclusion. The <object> element allows HTML authors to specify everything required by an object for its presentation by a user agent
Here are few example:
You can embed a HTML document in an HTML document itself as follows:

<object data="data/test.htm" type="text/html" width="300" height="200"> alt : <a href="data/test.htm">test.htm</a> </object>

Here alt attribute will come into picture if browser does not support object tag.
You can embed a PDF document in an HTML document as follows:

<object data="data/test.htm" type="application/pdf" width="300" height="200"> alt : <a href="data/test.pdf">test.pdf</a> </object>

You can specify some parameters related to the document with the param tag. IE sometimes needs a src parameter to understand the location. Here is an exmaple to embed a wav file:

<object type="audio/x-wav" data="data/test.wav" width="200" height="20"> <param name="src" value="data/test.wav"> <param name="autoplay" value="false"> <param name="autoStart" value="0"> alt : <a href="data/test.wav">test.wav</a> </object>

You can add a flash document as follows:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" id="penguin" codebase="someplace/swflash.cab" width="200" height="300"> <param name="movie" value="flash/penguin.swf" /> <param name="quality" value="high" /> <img src="penguin.jpg" width="200" height="300" alt="Penguin" /> </object>

You can add a java applet into HTML document as follows:

<object classid="clsid:8ad9c840-044e-11d1-b3e9-00805f499d93" width="200" height="200"> <param name="code" value="applet.class"> </object>

The classid attribute identifies which version of Java Plug-in to use. You can use the optional codebase attribute to specify if and how to download the JRE.

Referencing Audio, Video, and Images:

You can reference any external document, regardless of type or format, via a conventional anchor tag:
Here is an example to reference an audio file. Similar way you can refer any world document, PDF file, zip file etc.

If you want to listen music then <a href="/html/yourfile.mid" target="_blank" > Click Here </a>

This will produce following result:
Just like any referenced document, the server delivers the desired multimedia object to the browser when the user selects the link. If the browser finds that the document is not HTML or XHTML but rather some other format, it automatically invokes an appropriate rendering tool to display or otherwise convey the contents of the object to the user.
Browsers identify and specially handle multimedia files from one of two different hints: either from the file's Multipurpose Internet Mail Extension (MIME) type, provided by the server, or from a special suffix in the file's name. The browser prefers MIME because of its richer description of the file and its contents, but it will infer the file's contents (type and format) from the file suffix: .gif or .jpg, for GIF and JPEG encoded images, for example, or .au for a special sound file.

Read More

HTML metatags.

                       HTML lets you specify metadata - information about a document rather than document content -in a variety of ways. The META element can be used to include name/value pairs describing properties of the HTML document, such as author, Expiry Date, a list of key words, author etc.
The <meta> tag is an empty element and so does not have a closing tag, rather, <meta> tags carry information within attributes, so you need a forward slash character at the end of the element.
Metadata provided by using meta tag is a very important part of the web. It can assist search engines in finding the best match when a user performs a search. Search engines will often look at any metadata attached to a page - especially keywords - and rank it higher than another page with less relevant metadata, or with no metadata at all.

Adding Meta Tags to Your Documents:

You can add metadata to your web pages by placing <meta> tags between the <head> and </head> tags. The can include the following attributes:

Attribute	Description
Name	Name for the property. Can be anything. Examples include, keywords, description, author, revised, generator etc.
content	Specifies the property's value.
scheme	Specifies a scheme to use to interpret the property's value (as declared in the content attribute).
http-equiv	Used for http response message headers. For example http-equiv can be used to refresh the page or to set a cookie. Values include content-type, expires, refresh and set-cookie.

NOTE: Core attributes for all the elements are discussed in next chapter.

Meta Tag Examples:

Let's see few important usage of Meta Tags.

Specifying Keywords:

We specify keywords which will be used by the search engine to search a web page. So using following tag you can specify important keywords related to your page.

<head> <meta name="keywords" content="HTML, meta tags, metadata" /> </head>

Document Description:

This is again important information and many search engine use this information as well while searching a web page. So you should give an appropriate description of the page.

<head> <meta name="description" content="Learn about Meta Tags." /> </head>

Document Revision date:

This information tells about last time the document was updated.

<head> <meta name="revised" content="Tutorialspoint, 6/12/2006" /> </head>

Document Refreshing:

You can specify a duration after which your web page will keep refreshing. If you want your page keep refreshing after every 10 seconds then use the following syntax.

<head> <meta http-equiv="refresh" content="10" /> </head>

Page Redirection:

You can specify a page redirection using Meta Tag. Following is an example of redirecting current page to another page. You can specify a duration after which page will be redirected.

<head> <meta http-equiv="refresh" content="10; url=http://www.tutorialspoint.com" /> </head>

If you don't provide a duration then page will be redirected immediately.

Setting Cookies:

You can use Meta Tag to store cookies on client side later information can be used by then Web Server to track a site visitor.

<head> <meta http-equiv="cookie" content="userid=xyz; expires=Wednesday, 08-Aug-00 23:59:59 GMT; /> </head>

If you do not include the expiration date and time, the cookie is considered a session cookie and will be deleted when the user exits the browser.

Setting Author Name:

You can set an author name in a web page using Meta Tag. See an example below:

<head>
<meta name="author" content="Mahnaz Mohtashim" />
</head>

Read More