banner
Welcome to HTML.co.uk, the number one resource for all news, information, and happenings regarding HTML.

Updates: HTML.co.uk has just been relaunched. Subscribe to our RSS Feed to stay on top of HTML news and techniques.
May
9th

Meta Elements Part 3: Dublin Core Metadata

Author: Editor | Files under HTML Tutorials
Tags for this article: , , , , ,

An international group of experts, united under the name Dublin Core Metadata Initiative, has developed a general system for Meta elements. Through which it is not only possible to express information about HTML documents, but also pictures, films, dates, and even physical objects. The system is easy to use and takes into consideration all the important information that can be conferred about an internet document. The Meta elements from Dublin Core have also been greeted warmly by the W3 consortium, who use them heavily with their RDF project.

Dublin Core primarily defines 15 attributes, or so-called elements, which can be assigned values. Additional sub-elements allow for special Meta elements. You will find a full list and description of the elements under the DCMI Meta data terms. The Dublin Core standard proposes some instructions for suitable schemata, including for media types, language abbreviations and information regarding the date.

The specification expressing Dublin Core in HTML/XHTML Meta and link elements describes how you should use certain Meta elements in your HTML file: The element name should be placed in the name attribute of the Meta tag, while the associated value should be placed in the content attribute. You can optionally enter the corresponding data format in the scheme attribute.

An Example:

<head profile=http://dublincore.org/documents/dcq-html/>
<link rel=“scheme.DC” href=http://purl.org/dc/elements/1.1>
<link rel=“scheme.DCTERMS” href=http://purl.org/dc/terms/>
<meta name=“DC.title” content=“SELFHTML: Meta elements”>
<meta name=“DC.creator” content=“Thomas Grady”>
<meta name=“DC.subject” content=“Meta elements”>
<meta name=“DC.description” content=“established Meta elements in HTML today”>
<meta name=“DC.publisher” content=“Thomas Grady”>
<meta name=“DC.contributer” content=“Ryan Howard”>
<meta name=“DC.date” content=“2008-5-8” scheme= “DCTERMS.W3CDTF”>
<meta name=“DC.type” content=“Text” scheme= “DCTERMS.DCMIType”>
<meta name=“DC.format” content=“text/html” scheme= “DCTERMS.IMT”>
<meta name=“DC.identifier”>
content=“http://www.html.co.uk/21/meta-elements-part-2.html”
scheme=“DCTERMS.URI”>
<meta name=“DC.source”
content=”http://www.w3.org/”
scheme=“DCTERMS.URI”>
<meta name=“DC.language” content=“en” scheme=“DCTERMS.RFC3066”>
<meta name=“DC.relation” content=http://dublincore.org/ scheme=“DCTERMS.URI”>
<meta name=“DC.coverage” content=“London” scheme=“DCTERMS.TGN”>
<meta name=“DC.rights” content=“All rights lie with the author”>
</head>

Explanation:

For programmes like search engines you can specifically define that your document is using the Dublin Core specification for embedding Meta elements in HTML.

With Meta elements, that belong to a certain public system, the name of the Meta element will be presented to the system as a short description. This prefix is DC for the 15 most commonly used elements with Dublin Core, and you must note DCTERMS for the sub-elements and schemata. The element name, or data format description, follows separated by a period. To clearly verify that all Meta elements with this prefix belong to the Dublin Core system, links are provided to the so-called naming space for Dublin Core. That way the uniqueness is ensured, even if other Meta data systems also operate with the same abbreviations.

With <meta name=“DC.title” content=“Title”> you can enter a title for the file, similar to the title element in HTML.
With <meta name=“DC.creator content=“Name”> you can reference the file’s original
creator.
With <meta name=“DC.subject” content=“Text”> you can specify the file’s topic.
With <meta name=“DC.description” content=“Text”> you can give a short description of the file’s content.
With <meta name=“DC.publisher” content=“Name”> you can enter who is responsible for the file’s publication. This can be the author themselves, or a publishing house, or a relative of a dead author.
With <meta name=“DC.contributor” content=“Name”> you can enter the co-authors or people who, next to the author, are responsible for the file’s content (such as translators, graphic designers, musicians etc).
With <meta name=“DC.date” content=“date”> you can enter when the file has been published. The date should adhere to a prevalent time and date format. You can specifically state, using the attribute= “DCTERMS.W3CDTF”, that the time entry adheres to such a system.

With <meta name=“DC.type” content=“Type”> you state the type of content you are making the Meta tags for. The following types are allowed:
Collection: If the content is a directory with links to sub-domains and the Meta elements are intended to describe the directory’s content.
Dataset: If the information is contained within a data set, such as a table.
Event: If the content is for an occurrence at some point in time, such as an exhibition or wedding.
Image: if the content is a visual representation, such as a photo, film, sketch or animation.
InteractiveResource: If the purpose of the site is based on interaction with the user, such as a registration form, embedded Java applet, or chat site.
PhysicalObject: If the site’s content concerns any physical object. Because this isn’t possible with HTML files, it makes little sense to specify it here. IF it is a visual representation of an object, choose image, choose text if it is a textual description, and sound if it is a sound description or effect.
Service: if the site performs a service, such as an online banking service.
Software: if the content offers software, for example, downloadable software and the Meta elements reference the software.
Sound: if the content is primarily acoustic, for example an embedded MP3 file or a streaming radio station.
Text: if the content is text oriented – regardless if it concerns literature, jokes, news scientific text or any other type of text.
Use the attribute scheme=“DCTERMS.DCMIType” in order to clearly specify that you are using these predefined types.

With <meta name=“DC.format” content=“Type”> you can state the file’s data format or media type. You can enter a MIME-Type for a value. The MIME-Type for HTML is text/html. You can make it clearer that the information concerns a media type in accordance with the official scheme using the scheme= “DCTERMS.IMT” attribute.

With <meta name=“DC.identifier” content=“value”> you can enter a unique number or address for the file. With websites, for example, this is the original URI. With the addition of scheme= “DCTERMS.URI” you make it clear the value is a valid URI.

With <meta name=“DC.source” content=”Source”> you can name the source from which the current file is drawn from or based on. In the example above we use a website as the source. However, you could name an offline publication or title. That would be the case if, for instance, the HTML file came from a book. If the source stems from an URI, then you can accentuate that with the scheme=“DCTERMS.URI” element.

With <meta name=“DC.language” content=“Language” you can enter the language in which the HTML file is written. A language abbreviation according to RFC 3066 is expected as a value for content.

With <meta name=“DC.relation” content=“Source”> you can enter what relation the current file has to any other projects it might belong to. The word in content should describe what type of relation.

With <meta name=“DC.coverage” content=“Text”> you can enter a geographical reference, or reference a point in time, for the file’s content. For geographical entries it can either be the location, longitude and latitude, a region, and the time reference can either be a date, or an age. We use a city name from the Ghetty Thesaurus of Geographical names as an example. The data format is noted as scheme=“DCTERMS.TGN”.

With <meta name=“DC.rights” content=“Text”> you can enter information regarding the file’s copyrights. You may also enter a URI where the exact legal conditions are specified. If you choose to reference a URI, then note the scheme=“DCTERMS.URI” attribute to ensure it is clear the value is a URI.

Take Note:

You do not have to use all of the Dublin Core Meta elements. It’s no problem if you only note the elements that make sense. Even noting the data formats with the scheme attribute is not completely necessary, but it is still recommended as long as the schemas exist.

Although the Dublin Core represents a well known and carefully worked through Meta data system, the practical uses of such Meta elements appear minute at first glance. The leading search engines completely ignore them, as a reaction to their previous misuse. So the use of Dublin Core Meta data is envisioned more where processing programmes can trust the Meta elements. Such Meta elements are well suited for the internal governing of large web sites, dynamically generating content directories, or internal website search functions, for example.


May
9th

Meta Elements: Part 2

Author: Editor | Files under HTML Basics, HTML Tutorials
Tags for this article: , , , ,

This section is a continuation of the previous section on Meta Elements. Here we will go over multilingual Meta elements, Meta element profiles in separate files, and a scheme for Meta elements.

Multilingual Meta Elements

You can notate multiple Meta elements of the same type and only differentiate between them by language. Keywords, or short descriptions, especially, can be written in multiple languages.

Here is an Example:

<head>
<meta name= “keywords” lang= “en-us”content= “vacation, Greece, sunshine”>
<meta name= “keywords” lang= “en” content= “holiday, Greece, sunshine”>
<meta name= “keywords” lang= “fr” content= “vacances, Grèce, soleil”>
</head>

The example shows the same keywords being defined in American English, British English, and French. The attribute lang is used in order to define the language. An abbreviation for the language is allowed as a value, for example, en for English, fr for French, es for Spanish, it for Italian, and so on.

Take Note:

The lang is one of the universal attributes in HTML. If you work in XHTML, then you will have to add the xml universal attribute like so: xml:lang.

A profile for Meta elements in a separate File

You can enter an external profile or formula for Meta elements, which you then follow. It could be a well known public profile, with certain internet addresses as its homepage. But it is also possible to enter your own profile with your own Meta definitions.

An Example:

<head profile= http://example.org/profile.html>
<meta name= “Category” content= “A.1.B.”>
</head>

Explanation:

In order to draw in a profile, you need to notate the profile attribute in the introductory <head> tag. Enter the URI for the profile file as the value. It is not prescribed how exactly this profile should look. Typically, a HTML file is entered that lists and defines the Meta attributes in a table. The W3 consortium would prefer to think of the entered address as a unique global name. In this manner, web browsers or search engines that already recognise the corresponding profile, do not need to read anything, as they already know how the following Meta elements should be interpreted according to the profile.

In this example we define a profile that is saved at the http://example.org/profile.html internet address. We assume that a Meta attribute, with the name category, is defined in this profile. This attribute can be used with <meta name= “category” content= “…”>

Take Note:

You cannot actually outsource the Meta elements themselves, only the scheme the elements follow.

A Schematic for Meta Elements

So that your Meta elements can be automatically processed, the values that notate the content attribute of a Meta element should be written in an established format – assuming of course a fitting format exists. You can enter such a scheme with help of an additional attribute.

An Example:

<head profile= “http://example.org/profile.html”>
<meta name= “Type” scheme= “MIME-Type” content “image/svg+xml”>
</head>

Explanation:

A profile is given, that is loaded onto the http://example.org/profile.html internet address. We assume that an attribute with the name Type exists in the profile. This attribute can be characterised in a Meta element with name= “Type”. The scheme attribute presents the attempt to give the reading software instructions on how values, belonging to the content attribute, should be read. In the example, the scheme= “MIME-Type” attempts to tell the software the value for content is a MIME Type.

Take Note:

This way of linking to a scheme is not strictly defined. The problem, which the scheme instructions should solve, actually arises from the scheme attribute itself. Modern Meta data profiles, such as the Dublin Core, do not only define attributes, but also give descriptions for possible schemata at the same time. We will go over the Dublin Core in more depth in our following section.


May
8th

General Information regarding Meta Elements: Part 1

Author: Editor | Files under HTML Tutorials
Tags for this article: , , ,

You can notate various types of useful information for web servers, web browsers and search engines using Meta elements. Meta elements can include information regarding the file’s author and content. They can also include HTTP orders, such as automatically forwarding to another address, for example.

Meta elements are not designed for personal commentary on the source text of a HTML file. Commentaries already exist for such information.

Since the HTML standard version 4.0, no one writes concrete Meta elements, instead they only define the fundamental construction of a Meta element. The W3 consortium is working on a language entitled Resource Description Framework, for standardising Meta elements. More information regarding the Resource Description Framework is found on the consortium’s website.

Be sure to note a Meta tag in the HTML file’s header for every Meta element. It is no problem whatsoever to notate multiple Meta tags.

Examples:

<head>
<meta name=“author” content=“John Smith”>
<meta http-equiv=“expires” content=“Sat, 01 Dec 2007 00:00:00 GMT”>
</head>

Explanation:

A Meta element exists in a standalone tag named Meta. Every Meta tag has two attributes. The attribute is either the name or http-equiv, while the second is always content. The two attributes produce typical configuration data of the type “attribute=value”. In the above example, the name was given the attribute “author”, while the content was given the value “John Smith”. In the second Meta example, the attribute named expires was given the value Sat, 01 Dec 2007 00:00:00 GMT. However, in the second example the attribute was defined with a http-equiv.

Attributes that are defined with name, are directed primarily towards reading client programmes, as in web browsers, but also towards search engine robots, which scan websites to feed their search engine data base.

On the other hand, attributes that are defined with http-equiv, were originally thought out for web servers. The idea behind it is when the web server receives the request from a web browser to transfer a HTML file, the web server first reads the Meta tags and information defined with http-equiv, before sending the file to the browser. This makes it possible for the file author to influence the communication between the web server and web browser. However, instructions of this type rarely achieve their desired effect, because most web servers do not read the data before sending the file to the browser. So it is then the web browser’s responsibility to interpret Meta instructions, such as the HTTP header.

Take Note:

Unfortunately, many people misuse Meta elements. Because most Meta elements have no apparent effect on the screen and are also involved with search engines, there are many ambitious people who feel they can somehow tweak with the Meta elements to get their site at the top of a search engine’s search results. After website developers used paradoxical and misleading Meta elements, the major search engines decided to no longer give any special attention to Meta elements. They instead place value on content and calculate the relevance of the site in terms of how many foreign sites link to it. Therefore, a homepage will not become successful through misleading Meta elements. A clean homepage includes the reasonable use of Meta elements.

If you work in the XHTML standard, then you must characterise the Meta elements as content less. To do so, notate them in a standalone tag in this form: <meta name=“Attribute” content=“Value” />.

Description, Author, Keywords, and Date

The Meta elements described here are the most prevalent, and they are read by nearly every search engine. Today’s popular search engines even still take them into consideration to a certain degree. The information is still important, especially for internal search programmes that need to rely on the accuracy of Meta elements.

You can notate your authorship, briefly describe the content, specify keywords and the date of publication. The short description, especially, is displayed by many search engines in the search results. It is therefore wise to include these Meta elements in all relevant HTML files and produce them just as carefully as you would the full bodied text to be displayed in the web browser.

An Example:

<head>
<meta name=“description” content=“this description should appear to a user when finding this website as a search result.”>
<meta name=“author” content=“Jim Jones”>
<meta name=“keywords” content=“HTML, meta information, search engines, HTTP protocol”>
< name=“date” content=“2008-5-8”>
</head>

Explanation:

With <meta name=“description” content=“description text”>, you determine the description text.

With <meta name=“author” content=“Author Name”>, you show who the HTML file author is.

With <meta name=“keywords” content=“list of keywords”, you determine the file’s tags or keywords for a search engine. A user, who searches using the same keywords as the ones specified in the Meta element, should have this website appear as a preferred result. Separate the keywords with a comma. A keyword can consist of two separate words or one word. However, entire sentences, or even half sentences, do not belong here, because that is what the descriptive text you notate using the name= “description” is for.

With < name=“date” content=“the date”>, you enter when the file was published. The time entry should follow a specific formula. In this case it begins with the year, 2008, followed by the month, May, and finally the date, the 8th. We have still only scratched the surface of Meta elements, but in the interest of organisation, we have decided to separate the tutorial of Meta elements into multiple parts. The next section follows after this one.


May
7th

The HTML File Title

Author: Editor | Files under HTML Tutorials
Tags for this article: , , ,

Every HTML file must include a title. This is especially important for the following reasons:

  • When the web browser opens the page, the file title will be shown on the page’s title headline.
  • When the web browser opens the page, the file title will be shown in the web tabs.
  • The file title will be used by the browser for setting bookmarks.
  • The file title will be shown in the web browser’s list of previously visited sites.
  • The file title serves as an important piece of information for many online search engines. If the file appears as a search result, then search engines often present the file’s title as a clickable link.

An Example:

<head>
<title>Tutorial for HTML Beginners</title>
</head>

Explanation:

The title is notated inside the file head in the ground framework of a HTML file. The <title> tag introduces the information regarding the title. Then the title’s text follows. The title entry is closed with the ending </title> tag.

Take Note:

The title should not be too long. We will go over descriptive file designations in a separate section on meta elements.

All the rules for the character set, special characters and HTML unique characters, apply for the title as well.


May
7th

Good HTML Style

Author: Editor | Files under HTML Basics, HTML Tutorials
Tags for this article: , , ,

There are not definitive guidelines for “proper” HTML. But there are rules on how a valid HTML document should look. It is definitely recommendable to orient yourself with the W3 consortium’s HTML language standards. The W3 consortium has since also recognised that their work does not only consist of elaborating on technical specifications, but also in communicating these specifications to normal laymen users, who lack an extensive background in programming. If you intensely and regularly produce websites, then it is worth checking in on the consortium’s website periodically for the latest happenings and developments.

The W3 consortium also offers a service for HTML authors, with their so-called validator, that checks how correctly HTML files are produced. If your website is reachable online, then you can simply enter the address into the validator to check the website’s syntax.

In terms of what is classified as “good HTML style”, it really is better to begin with what should not be done under any circumstances.

Do not write for specific browsers

If you wish to place data online, then you should use more than one web browser to test your data. Use the prevalent Firefox and Internet Explorer browsers, in multiple versions if at all possible, and also try to use a third browser such as Safari or Opera. If you have the possibility to test on multiple platforms (Windows, Mac OS, Linux), then do so. And maybe even view your website on a handheld computer or with glasses, so that everything looks blurry.

Of course, no one can prevent you from writing HTML that is only correctly viewed by Internet Explorer. But if you upload such sites online, then you should know that you are only damaging your own image.

Do not write for certain screen resolutions.

Extorting specific widths by using interlocked tables and blind pixels has since become so widespread in the web, that some website designers do not even know regular HTML produces text that automatically adjusts to the browser’s window size. There is no point in completely corrupting and forcing minimum widths. Tables with multiple columns and the corresponding content require only a certain width. If you ask the question of whether you should “optimise” your website for a 1024 or 800 resolution, then you are asking the wrong question. Many users surf with multiple windows open and continuously open links in new windows. These windows are then often not displayed in full screen mode. Many users also have programs open that fundamentally take up a portion of the screen and are always displayed, such as instant messaging programmes. All these users do not make the extra effort to show your site in with the maximum screen size. Do not bother with the maximum value screen size resolution. You can require a few hundred pixels (a very inexact amount) for the width, but that is all.

Use tables and frames only sparingly and instead opt for width and height values in percentages. Absolute pixel values only make sense when the first column of a blind table is supposed to be located on a colour background picture split in two. Otherwise, you should not occupy yourself with such notions. Just because it looks good for you, doesn’t mean it looks good for others, in fact, it could even appear very bad.

Do not use HTML elements for purposes they are not designed for

Especially do not use the logical and semantic HTML elements for certain formatting effects. For example, some people use the blockquote element in order to indent paragraphs, only because most browsers display text within the <blockquote>…</blockquote> as an indented paragraph. However, the blockquote element is purely conceived for quotes and should only be used as such.

People are more frequently using tables and headings in a sloppy manner. Headings are not there to make text big and fat, but instead to mark a logical hierarchical relationship between the blocks of text. Tables should be used to view table data and not for any layout purposes. If you wish to format or position text in a certain way, then you should use style sheets.

Use honest and meaningful linking text

This rule generally applies: the link destination should include what the link promises. This means that when constructing a link, the link text should neither promise too much, nor too little. For example, if you offer information about a piece of software, without offering the opportunity to also download it, then it is unfair to link to the information and suggest the user may immediately download the software.

In HTML, links can be set up at any desired location in the text. However, if you read a text, where every second word is a link, then you will clearly realise this disturbs the reading flow. The links continually draw the same amount of attention and prevent the reader from actually understanding the text’s content. This makes it even more important for links inside the text to be clear and not pose any riddles.

Therefore, only enter a link inside text when the link text makes sense. And structure the sentences, which contain the link, in such a way that the link is also meaningful.

For example, do not write:
“For further information click here.”

But instead:
Additional information is also available”.

Use Graphics correctly

If you are not in the middle of producing a huge art exhibition in HTML, then you should first keep your distance from large graphics files. Think about how many users will not be thrilled over the long loading times with the files that you produce for the web.

Instead, use smaller, better placed graphics. 16 colours often suffice, instead of 256 or even 16.7 million. That makes the graphics much smaller.

On the other hand, you should not at all do without any graphics. Pure text on the computer monitor is more tiring to read than on a handheld book, for example. That’s why you should try to structure long texts as richly as possible and with a lot of variation. Graphics are one means of doing so.

Small icon sized graphics are ideal. The load quickly, and you can reference loads of them without a second thought.

Small graphics can also assume certain corporate identity or orientation functions. The advantage of using such graphics more than once, is that the browser need only load them once and then keep them saved.


May
6th

Separating Information and Organising the File

Author: Editor | Files under HTML Basics, HTML Tutorials
Tags for this article: , , , ,

HTML stands for Hypertext Markup Language. The user should be able to navigate through information they find interesting. For those who are interested in investigating this subject more closely, we will provide a detailed examination of hypertext in another segment.

With the hypertext information layout, it is necessary that the information is separated into smaller and closed units of information, which are interlocked with each other in an understandable and clear manner.

If, for example, you wanted to display your favourite football club online, then you would need the typical homepage with links to subordinate pages. Each of the subordinate pages should also include a link back to the homepage. You could easily use a subordinate page for the club’s standings, history, roster or schedule, for example. The roster page could then link to other subordinate pages for individual players. With such a subsidiary of a subsidiary page, it is wise to have a link going back the next highest page, as well as a link to the main page. More intersecting links from the standings page to the goal scorer’s page, for example, are also quite reasonable. A network of information then results. Additional links should then help complement the navigational possibilities. In many instances, it is also reasonable to offer so-called guided tours, or a succession of pages that the user can comfortably skim through. Regardless of which project you are undertaking: you should always keep in mind the notion of structure and linking that we explored here.

What we describe here as a page or subsidiary page, should also be a HTML file in a web project. Do not be overwhelmed by the amount of resulting files. The clear structuring of information should always remain the highest priority.

We will examine methods of linking more closely in a separate section and also provide more tips for producing web projects later on.

File Organisation

With every somewhat large project you will soon quickly realise how many HTML, graphics and all kinds of files you end up amassing. In order to keep everything in view, you should either consider a clever filename scheme or create separate subdirectories sorted by topic or area. If you wish to release your project online, then you will have to find out beforehand if you have the right or possibility to load subdirectories onto the web server, where you eventually plan to upload the project. Because in this case you will have to produce the same directory on the server computer as you produced locally, in order for all the references and links to function correctly.


May
6th

Conventions for Filenames

Author: Editor | Files under HTML Basics, HTML Tutorials
Tags for this article: , , , ,

Most server computers in today’s internet have either a Unix or Unix led operating system. Unix distinguishes between upper- and lowercase in filenames. Anyone who produces their web project in a Windows environment, for example, can become bitterly disappointed when their locally functioning graphic references and links suddenly no longer work after being uploaded onto the server computer. One reason for such a case would be if the destination link is written in lowercase in the HTML file, while the Windows system has transferred the file names in uppercase.

In such a situation there is almost no other option, aside from renaming the files on the server computer using FTP commands, or to adjust the links and graphics references so that the referenced destinations are found correctly. If you work with a system where upper- or lowercases in the file name only make a graphical, not internal difference, such as Windows, then it is best to only produce document names in lowercase. It is also best to write everything in lowercase for links and graphics references.

Filenames in terms of Compatibility

If you are producing your web project solely for internet use, then you have to make sure the files will be accepted by the server computer. With modern Unix systems, as most web servers use them, filenames of up to 256 characters long are accepted. The “_” character is allowed as a special character, otherwise all special characters should be avoided. Question marks “?” and stars “*” should definitely be avoided, because these characters have a special meaning with nearly all systems.

File Endings

Here the general rule holds true: stick to the usual and standard file endings unconditionally. The web server must determine, based on the file ending, which MIME type it sends the browser. And the browser decides how to treat the file depending on the MIME type.

  • Typical HTML files either include the ending .htm or .html
  • HTML files containing server side endings possess the .shtml and .shtm endings
  • HTML files with PHP sections have the ending .php
  • While HTML files with ASP sections have the ending .asp

Default File Names with Web Servers

Most of today’s web servers see one or multiple file names as the file for the “Home site”. Most of the time the home page has the name index.html or index.htm, but sometimes it also uses welcome.html or welcome.htm or default.html or default.htm. Some providers allow you to choose your own filename as the default filename.

Default filenames have the advantage of making it so the web addresses becomes shorter, as they no longer require any other HTML file names. Many web addresses simply consist or http://www.example.org/ or http://www.example.org/directory/ – without any other information regarding a specific HTML file. A certain HTML file is nevertheless uploaded when loading the web address, because the filename is already saved by the web server as a default filename.

You may ask your provider if they offer default filenames for directories, and if so, then which. Construct your project in such a way that your home page has one of these filenames and that the subordinate pages refer back to it.


May
6th

Referencing in HTML

Author: Editor | Files under HTML Basics, HTML Tutorials
Tags for this article: , , ,

As we know, HTML files consist purely of text. Nevertheless, many websites contain graphics, background graphics, multimedia elements, java applets, flash animations and more. In HTML, such elements are noted in the form of a reference to a specific data source. Even a link to your own website, or another site, is only executable if you name the link destination. Referencing is required in HTML for all these purposes.

There are also places in complement languages such as style sheets or JavaScript, where other data sources must be referenced.

The rules for referencing always stay the same. The reason for this is the central and universal web address system, which functions independently of the syntax from single operating systems and allows one to exactly specify any web address they desire.

Referencing with complete URIs

You must reference with fully complete URIs if you are not referencing data sources from you own website.

A URI (universal resource identifier) is something like http://www.html.co.uk/ or http://www.html.co.uk/12/defining-colour-in-html.html. Both web addresses are also simultaneously URLs (uniform resource locaters). And then there are also – in order to make the confusion complete – so-called URNs (uniform resource names). The last is conceived for distinctly naming data sources that do exist, yet are not accessible online through any known internet protocol. A URI describes both URLs and URNs, where URIs and URLs are typical web addresses, behind which concrete data is contained. URIs and URLs are also technically the same. However, in standard HTML the talk is of URIs.

Examples of URIs:

http://www.html.co.uk/

http://www.html.co.uk/about

http://www.html.co.uk/category/html-tutorials

http://www.example.com:8000/blah/

http://www.example.org/cgi-bin/search.cgi?expression=referencing

Explanation:

A complete URL consists of an internet protocol designation, for example either http or ftp, followed by a colon. Afterwards – depending on the protocol – additional information concerning the network name can be included. This designation is enclosed within two forward slashes “//”. Most addresses do not include such designations, which is why the two forward slashes simply stand there without any content in between.

The online address for the host’s computer, where the data source is located, follows thereafter. This can either be a domain name or a numerical IP address. The domain name in the above example is html.co.uk. The www before is typical for the internet and web servers can adjust the pre-setting for sub domains. A so-called port number can follow the domain name after a colon. This is always necessary when the data source isn’t reachable over the standard port of the entered protocol, such as http, but instead via another port. Port numbers are seldom used, but it is still good to know about them.

Then the local path designation to the data source follows. Regardless of the operating system – directory paths are always separated with a simple forward slash. It is the task of the server software, located on the computer, to correctly produce the path designation. As a result, you need not worry about what operating system the computer you are accessing is running.

One can access as many files and data sources as desired from the computer. The only requirement is that they are accessible from the protocol entered, such as http. Files are not necessarily the only accessible data. With a “#” followed by a name, one can access a specific destination anchor within a HTML file. We will describe later how to define such destination anchors. URIs can also be the execution of CGI scripts with parameters, like in the above search.cgi?expression=referencing example.

Characters, that aren’t contained within the ASCII table code or have a meaning in URIs (such as the forward slash, colon or percent character), must be masked within an URI. This occurs by entering a “%” with the hexadecimal value for the character.

Take Note:

The descriptions above are directed towards HTML learners and make no claims whatsoever to completeness. The concept of URIs is much more complex than has been presented here. If interested in learning more, you can read here for more information on URIs in a World Wide Web context, or here to learn more about the general syntax of URIs.

Reference to a base URL relatively with absolute path designations

You can opt for this form of referencing if the desired data source is located on the same host computer, and if it is accessible via the current protocol and the standard port. This sounds more complicated than it is. Within the complete URI http://www.html.co.uk/category/html-tutorials, the /category/html-tutorials part is an absolute path designation relative to the base http://www.html.co.uk URI. You can work with such path designations within your own website and domain or sub-domain.

An Example:

/
/index.htm
/index.htm#about us
/background.gif
/presentation.pdf

Explanation:

The first forward slash following the base URI stands for the internet service’s root directory. Typically it is not the same as the actual root directory on the computer or hard drive, from which the data is extracted. With web servers, for example, one can determine which actual directory the web directory should correspond to. Everything can follow after the base URI that we just discussed above.