Why is JavaScript more popular than VB script

Tips & Tricks

on web design, JavaScript and DHTML

© 1999, 2001 www.pigasus.de

This page offers a summary of the tips and tricks of the ... pigasus site ... for a quick download or a complete printout.



JavaScript / JScript / Java / VB-Script / ECMA-Script / ... ????

There are tons of "internet languages" out there. Some are often confused:

Java is different from JavaScript!
The similarity of the name hardly continues within the languages, and the fields of application also differ greatly. Marketing purposes were probably in the foreground here.

JScript is the Microsoft version of JavaScript - not identical, but largely compatible. The newer commands, which have not yet been standardized, are particularly difficult.

ECMA is a European standardization organization to which Microsoft and Netscape belong, among others. ECMA script is an attempt at "standard JavaScript". While everyone promises to follow this standard, the goal is not quite there. Using ECMA script, however, already promises extensive compatibility.

VB script is one of the many VisualBasic variants from Microsoft. Since only IE understands VB script, it is not that common. In addition, it is not as secure as JavaScript, so the use of VB scripts is disabled for most surfers.

On this site the name JavaScript - as it is mostly common - is also used for JScript and ECMA-Script, thus as a "family name".

DHTML - what is that?

First of all, DHTML (or d-HTML as it is called by Netscape) is a Marketing term and not an exact description of a technique. Here are various methods that bring movement to the site are summarized. In older browsers, the content and design of a page could no longer be changed after loading, with almost only form fields being an exception.

DHTML now links new event handlers, which have belonged to HTML since HTML 4.0 and not to the script language used, with the various script languages ​​(JavaScript, JScript, VBScript, ECMAScript, ...) and approaches to object-oriented programming. Unfortunately, as usual, Netscape and Microsoft go their separate ways, this time Microsoft is a long way ahead.

What is now possible, among other things, is a reaction to user input within a page, animations of text and images, exact positioning of elements, etc. That sounds nice at first, but: The lack of compatibility the browser, not to mention older ones, requires increased programming effort, which nevertheless only leads to results with the lowest common denominator.

Experiments in DHTML are certainly promising for the future, but a site that is dependent on it in essential areas does not reach all surfers today.

What can JavaScript do? And what not?

JavaScript is (usually) executed on the client, and there in the Sandpit in the browser. With a conventional program, you usually know the author, he is on the packaging. It's different with a script on the Internet. JavaScript therefore hardly allows anything that would harm the user, and if it does, it is mostly a bug for which patches are quickly available. (There are of course exceptions.) This almost gives the answers to these questions.

JavaScript can relieve the server and the networkby performing calculations on the client. This is usually faster too. One example is form plausibility checks.

JavaScript can react to inputs and corresponding Spend.
Inputs can be e.g. keyboard inputs or mouse movements and clicks by the user, but can also be derived from the client's environment, such as the operating system, browser used, installed plugins, language, time.
Outputs are mostly screen displays, but can also be sound or the printing of the page, or mailing, ...

JavaScript can (with css help) Animate the contents of the screen , make them movable with the mouse, show and hide - this is called DHTML.

JavaScript can interact with the browser: Open and close windows, describe the status bar, wander around in the history, ...

JavaScript can write HTML or in other ways achieve goals that could also be achieved with HTML. For example, set links and format the font.

JavaScipt can also save cookies on the user's hard disk - in a limited number and size, only readable by the server that wrote them, only with name / value pairs. A small hole in the sandpit.

JavaScript cannot write files (except cookies), neither on the user's hard disk nor on the server, nor any registry entries or similar.

JavaScript cannot read data from browser windows on other servers.

JavaScript cannot close "foreign" windows, create invisible windows, create frameless windows.

JavaScript cannot secretly send e-mails.

JavaScript cannot hide the source code of a file, not even his own. The browser must be able to read it, so the user can too.

JavaScript has no graphic skills. It cannot paint lines or circles. However, it can display finished graphic files (like HTML) and even edit them with the filters in IE.

Should I? Or should I not?

Anyone who uses something other than "pure" HTML with the lowest possible version number must be aware that not all visitors see their pages as they do - and even then there is still Differences depending on browser, platform, screen. Some won't see anything, at least nothing useful. I don't even want to describe the output of the pages on cell phones, handhelds, coffee machines and everything else that is connected to the Internet.

Don't just cause problems ActiveX controls (which almost everyone has switched off by now), Plug-ins (which not everyone wants to download) and proprietary extensions (from the blink tag to document.all) that only individual browsers understand. Some surfers also switch the image display - not the screen! - from, browsers have no support for frames, JavaScript, ...

So what techniques do I use on my site? There is no one-size-fits-all answer here. The technical requirements of every site have to be evaluated according to target group-specific aspects: A site like this one, which deals with DHTML etc., can and must also demonstrate these techniques. Data collections in the academic environment have a completely different audience, which usually does not go along with every update. Commercial sites can hardly afford to forego even a few percent of potential customers. The following applies here HTML 3.1 further as the means of choice.

JavaScripts that run on Navigator and Internet Explorer 3 versions reach a large number of surfers. This is the aim of a commercial site at the moment. Anything beyond that - HTML 4, JavaScript 1.2, etc. - should only be used with care, or you have to Alternatives that can also be used by less well-equipped or more cautious visitors. For sites with internet technical orientation, web art, etc., separate laws apply again ...

Content and concentration

The most important point for a well-visited website: content. Even better: focus on one topic.

Thousands upon thousands of pages on the Internet bring many topics and little depth. As a hobby site that everyone makes for themselves, that might be enough. But if I want to seriously inform, it is the wrong way.

The Internet user is mostly looking for information one Theme, fun one certain type or images one Subject. Most of the time he himself is not entirely without previous knowledge. The hundredth superficial introduction doesn't help him, the 32 other offers on the same website don't interest him at all.

In addition: every topic has its own target groupwhose taste, style, previous knowledge etc. may differ greatly. In order to guarantee the uniformity of the page and at the same time to optimally address the readers, each target group should have their own site for this reason alone.

So find a topic for your site. Offer Depth instead of width! If you want to bring a new topic into the net: Take a new site that exactly addresses the new target group!

The small difference ... between amateurs and professionals

... there is no such thing, but there are many big ones. In addition to what has been said about content and depth, there are a number of other points to consider so that a site does not immediately put off its visitors.

No one is without error. But the mistakes should no way as spelling mistakes in titles, alert windows or on others exposed areas Pop up.

Work careful. The impression of bad scans, typing errors, slipped breaks and invalid links are transferred to your product and the content of your site.

Do not complain! The surfer does not come to write in a guest book or to subscribe to a newsletter, but to get information, fun, etc. If he wants to register, ok, if not: leave him alone. A simple link is sufficient for those who want to register.

Build simple pages! Background images, colorful, blinking, flickering text, UPPERCASE, etc. distract from the content and are difficult to read - and rude when shouting.

You write Scrolling text left-justified! This is best readable. Completely centered pages contradict any structure the content might have.

Look at you the "big" sites such as Microsoft, IBM, Netscape, Altavista, Yahoo or Lycos. You won't necessarily find the greatest and most modern design there, but a successful and professional one.

How to start

At the beginning there is the question of that aim - it is usually the heaviest. Only when I know where I want to go do I worry about the way.

JavaScript is not always the first choice. Some goals can already be achieved with "normal" HTML, which is only to be recommended. Others cannot be accessed with JavaScript. JavaScript can neither replace the entire cgi area nor provide a replacement for the "offline languages" (such as C ++, Visual Basic, Delphi, ...).

The Strengthen of JavaScript lie in small programs for websites. You can relieve the server and thus increase the transmission speed or shorten the response time. But the bigger the script, the smaller this effect becomes - until it turns into the opposite.

Have you decided on a JavaScript solution? Then it's best to do a search on the Internet finished solutions or partial solutions. There is next to that pigasus site There are many other sources on the WWW that offer tried and tested scripts, so a lot of development time can be saved. In order to adapt a finished script to your needs, you should already have basic knowledge of JavaScript, e.g. you should be able to recognize which variables you can change with which goal. There are also numerous sources for acquiring this knowledge.

You write a own script? Please test it on as many browsers and platforms as you can. Some browsers come up with surprises when it comes to script interpretation. A hail of error messages when opening a homepage makes a very unprofessional impression and scares away any visitor!

Stay compatible - but how?

A major problem with (Java) scripting is the difference between browsers and platforms. A few numbers from the beginning of 1999:

  • 90% of my visitors used Windows computers (of which less than 1% 3.x),
  • around 50% each used a Netscape browser or Microsoft's Internet Explorer,
  • less than 2% were using other browsers or 2.x versions,
  • 4.x + versions were represented with approx. 90%.

Addendum: In May 2001 the picture changed:

  • 88.9% were there with the IE 5+,
  • 7.2% with Netscape 4+,
  • 0.5% each of Opera and Konqueror surfers as well
  • 3% visitors with different or unidentifiable browsers.

So if you don't want to lose many visitors, you should adapt your pages to the various features. There are different variants for this:

  • Extra pages
  • Object queries
  • Navigator queries

For all forms you should as a rule from the simplest Side go out. A forwarding to the simple version might fail because the browser doesn't understand this script at all!


With Extra pages You can create your own files for every target group, e.g. via a simple link, for every browser, every resolution, every platform or every language. The text version, which every browser understands, is popular here. However, adjustments that go far beyond this require enormous additional work and quickly become confusing


The Object query checks the usability of objects, e.g.

if (document.all) document.all.blabla ... or if (document.images) {....}

Once you have found out what capabilities the browser has, you don't have to rewrite the entire page. In most cases, it is sufficient to define individual variables, which then have different values ​​or sources depending on the browser:

if (document.layers) {position = document.layers [0] .left} else {position = document.all.f1.style.left;} alert (position)

All browsers that have the appropriate capabilities are taken into account.


As a third option, the browser, version, platform, etc. can be controlled via the navigator object find out (example). Of course, this method reveals more details, but it also has its pitfalls: The programmer usually excludes some visitors unnecessarily, even though their browsers actually have all the capabilities. After all, there are more browsers than NN and IE - and an exact query of the browser version can even hamper them if used carelessly newer Browser.

even more compatibility

If the last question was about reaching at least 90% of surfers who use a 4+ browser (despite) scripts, we are now setting the goal higher. the Web Accessibility Initiative, for example, strives for comprehensive accessibility for web content. Using a 3-way browser is the minor problem:

Many circumstances can hinder the surfer in capturing website content, physical or mental disabilities of the surfer as well as a different level of education, a different subject or language of the user or a different technical equipment than the author might expect. Examples of this:

  • Blindness, deafness, or disabilities
  • Color blindness or other visual impairments
  • Disabilities with regard to the recording of moving objects
  • Epilepsy with color / image changes of certain frequencies
  • Difficulty reading, understanding or processing certain information
  • Black and white monitors
  • text based browsers or text screens
  • Browser without frames, tables and other representations
  • missing plug-ins
  • slow internet connection or offline version of the page
  • disabled script languages, applets, style sheets, ...
  • low resolution, e.g. palmtops, cell phones
  • other operating systems
  • other input devices
  • other output devices
  • other mother tongue
  • other education
  • Obstacle due to the situation, e.g. noisy surroundings, car trip

If the author really wants to reach all possible addressees, he must take these adversities into account. When it comes to implementation, this can mean making the page as simple as possible. A black and white text page without tables and frames in HTML 3.2 surely avoids many difficulties.

The other way is more difficult, but leads to creative possibilities again. An important point here is to supplement all non-text content, i.e. images, sound, video, etc., with a text equivalent, for example with the attribute. Using style sheets for formatting is a good step in making documents accessible.

Another point: format the text logically, not physically, and do not abuse tags, such as

for larger fonts. Correctly applied logical formatting is displayed sensibly on all browsers.

An essential prerequisite for an easily comprehensible page is that it is free from errors: On the one hand, this applies to the syntax of html, stylesheets and scripts, which can be checked with automatic tools. This also includes correctness in spelling, grammar and style, which makes a document understandable - especially for people with weaknesses in these areas. So: Let other people proofread the documents.

Check your pages under as many conditions as possible: with different browsers, old and new, different operating systems, without a mouse, with different screens and resolutions, with and without sound, graphics, frames, scripts.

The accessibility guidelines for web content of the W3C (in German translation) are certainly worth reading on this topic and lead even deeper into the matter.

Supported JavaScript Objects

  MSIE 3 MSIE 4/5 Netscape 2 Netscape 3 Netscape 4 Opera 3.51
Array object++-+++
Cookies+++++-
css access-+--++
Date object++++++
Shape object++++++
Frame access++-+++
History object++++++
Image maps-+-+++
Image object-+-+++
JavaApplet access++-++-
Determine Java-enabled-+-++-
JS libraries (src)-+-+++
Link access++++++
Location property++++++
Math object++++++
Mimetypes access---++-
Navigator object++++++
String object++++++
Window object++++++

MIME types

Mime (Multipurpose Internet Mail Extensions) types are used to specify file types. This is necessary because not all operating systems work with file extensions. Even with Windows, the endings are not always clear. The correct specification of the mime-type, for example when transferring form data or using multimedia objects, ensures perfect transfer and display. Otherwise, for example, special characters will be encoded or content will not be reproduced at all.

Here is a list of important file extensions and the associated mime types:

Endingwww / mimedescription
doc dot application / msword MS Word files
ppt ppz pps pot application / mspowerpoint MS powerpoint files
xls xla application / msexcel MS Excel files
hlp chm application / mshelp MS Windows Help files
com application / octet-stream Executable files or program code files
exe application / octet-stream Executable files
dll application / octet-stream Program code files
class application / octet-stream Program code files
am application / octet-stream Uninterpreted binary
oda application / oda 
pdf application / pdf PDF files
ai application / postscript 8bit
PS application / postscript 8bit
eps application / postscript 8bit
ps application / postscript 8bit
rtf application / x-rtf 
rtf application / rtf RTF files (Microsoft)
csh application / x-csh C-shell script
dvi application / x-dvi TeX dvi (Unix)
hdf application / x-hdf NCSA HDF Data File
ustar application / x-ustar tar archive file (Posix)
latex application / x-latex LaTeX source file (Unix)
mif application / x-mif Maker Interchange Format (Adobe FrameMaker Unix)
mif application / mif Maker Interchange Format (Adobe FrameMaker)
nc application / x-netcdf Unidata netCDF data
cdf application / x-netcdf 
sh application / x-sh Bourne Shell script
tar application / x-tar tar archive file (Unix)
tcl application / x-tcl TCL script
tex application / x-tex 
texi application / x-texinfo 
texinfo application / x-texinfo 
t application / x-troff 
roff application / x-troff 
tr application / x-troff 
man application / x-troff-man 
me application / x-troff-me 
ms application / x-troff-ms 
src application / x-wais-source 
bcpio application / x-bcpip Old binary CPIO
cpio application / x-cpio CPIO
gtar application / x-gtar 
shar application / x-shar Shell archive file (Unix)
sv4cpio application / x-sv4cpio 
sv4crc application / x-sv4crc SVR4 CPIO with CRC
  application / x-www-form-urlencoded HTML form data to CGI
CAE section  
igs application / iges IGES Graphics format
iges application / iges 
IGS application / iges 
IGES application / iges 
stp application / STEP ISO-10303 STEP
STP application / STEP 
step application / STEP 
STEP application / STEP 
dxf application / dxf DXF (AUTODESK)
DXF application / dxf 
vda application / vda VDA-FS Surface data
VDA application / vda 
set application / set 
SET application / set 
stl application / SLA Stereolithography
STL application / SLA 
   
dwg application / acad Autocad drawing files
DWG application / acad 
SOL application / solids MATRA Prelude solids
DRW application / drafting Prelude drafting
prt application / pro_eng PTC Pro / ENGINEER part
PRT application / pro_eng 
unv application / i-deas SDRC I-DEAS files
UNV application / i-deas 
CCAD application / clariscad ClarisCAD files
snd audio / basic AU sound files
ouch audio / basic SND sound files
aiff audio / x-aiff AIFF sound files
aifc audio / x-aiff AIFF sound files
aif audio / x-aif AIFF sound files
wav audio / x-wav 
you audio / x-dspeeh Voice files
cht audio / x-dspeeh Voice files
midi audio / x-midi MIDI files
mid audio / x-midi MIDI files
R.A.M audio / x-pn-real audio RealAudio files
ra audio / x-pn-real audio RealAudio files
rpm audio / x-pn-realaudio-plugin RealAudio plugin files
gif image / gif GIF graphic
ief image / ief Image Exchange Format
jpg image / jpeg JPEG graphic
JPG image / jpeg JPEG graphic
JPE image / jpeg JPEG graphic
jpe image / jpeg JPEG graphic
JPEG image / jpeg JPEG graphic
jpeg image / jpeg JPEG graphic
tif image / tiff TIFF graphic
tiff image / tiff TIFF graphic
ras image / cmu-raster CMU grid
fh4 image / x-freehand Freehand graphics
fh5 image / x-freehand Freehand graphics
fhc image / x-freehand Freehand graphics
   
PBM  
pnm image / x-portable-anymap PBM Anymap file
pbm image / x-portable-bitmap PBM bitmap file
pgm image / x-portable-graymap PBM graymap file
ppm image / x-portable-pixmap PBM pixmap file
rgb image / x-rgb RBG graphic
xbm image / x-xbitmap 
xpm image / x-xpixmap 
xwd image / x-xwindowdump X-Windows Dump
html text / html HTML file
htm text / html HTML file
htmls text / html Server-side includes
sgm sgml text / x-sgml SGML file
css text / css CSS style sheet file
js text / javascript JavaScript file
c text / plain C source
H text / plain C headers
C. text / plain C ++ source
cc text / plain C ++ source
hh text / plain C ++ headers
m text / plain Objective-C source
f90 text / plain Fortran 90 source
txt text / plain Plain text
rtx text / richtext MIME Richtext format
tsv text / tab-separated-values Data text file with tabs as field separators
etx text / x-setext Struct Enchanced Txt
MPG video / mpeg MPEG video
mpg video / mpeg MPEG video
MPE video / mpeg MPEG video
mpe video / mpeg MPEG video
MPEG video / mpeg MPEG video
mpeg video / mpeg MPEG video
qt video / quicktime Quicktime video
mov video / quicktime Quicktime video
avi video / x-msvideo Microsoft AVI video
movie video / x-sgi-movie Microsoft SGI video
wrl x-world / x-vrml VRML files
gz multipart / x-gzip 
zip multipart / x-zip 
tar multipart / x-tar 
ustar multipart / x-ustar POSIX tar
*.* www / unknown Try to guess
* www / unknown Try to guess
   
only under VMS  
cxx text / plain C ++
for text / plain Fortran
mar text / plain MACRO
log text / plain logfiles
com text / plain scripts
sdml text / plain SDML
list text / plain listfiles
lst text / plain listfiles
def text / plain definition files
conf text / plain definition files
  text / plain without ending

The criteria for user-friendliness in DIN 66234, part 8

DIN 66234 defines basic criteria for the design of user interfaces that can also be transferred to web design. The qualities of an "ergonomic dialogue system" according to DIN should also characterize a website.

1.
Task appropriateness
The users are in the process of doing their job efficient supported. You achieve theirs aims quickly without being unnecessary due to the properties of the dialog system burdened to become.
2.
Self-description ability
Every step in the dialogue is immediate understandable. The users can get an idea of ​​the system interrelationships that is useful for understanding and completing the work task.
3.
Conformity with expectations
The dialogue corresponds to the expectationsthat users bring with them from experience with previous work processes or from user training.
4.
consistency
The dialogue behavior is uniformly. Inconsistent dialog behavior forces the user to adapt strongly to changing implementation conditions of their work, makes learning difficult and brings with it unnecessary stress.
5.
Resilience to errors
In spite of incorrect entries the work result can be achieved with little or no correction effort. User inputs must not lead to undefined system states or system breakdowns.

Fast pages

Fast through the network

Otto Normalsurfer doesn't like to wait. If the page load takes too long, it breaks off and looks for another site - there are enough of them. For the web designer, this means designing pages as fast as possible.
The speed of a website has two aspects: The objective loading speed, i.e. the time between clicking the link (e.g.) until the end of the loading process, on the other hand a subjective speedthat shows the time to usability and readability of the page.

Small amounts of data

A page is fast when it has a small amount of data. The maximum should normally be around 50kB, and significantly less on the homepage.
How do I do that? First of all, you should have too large pages in several smaller ones split up. The surfer then only needs to load what interests him. Then take a look at that Graphics. They often have an enormous scope on their own. By reducing the color depth, a suitable one File format, one Reduction of the image section on important parts and storage in the ones actually needed Image size much is gained. Other possibilities are the reuse identical images on different pages so that the browser cache can deliver the graphics.
A note about the file format: Browsers display GIF and JPG images by default. GIFs have up to 256 colors, JPGs 16.7 million. Due to the type of compression, GIFs are particularly suitable for images with uniform color areas, e.g. most drawings. JPGs are more suitable for graphics with gradients, such as photos. With JPGs the degree of compression can be adjusted, whereby a very high compression leads to visible errors in the picture.
One more point: the source code. Many editors generously add breaks and spaces, comments and, above all, superfluous tags and parameters. Especially with tables you often find e.g. width specifications for each individual cell, which is unnecessary: ​​all cells in a column are the same width. The font tag and nbsp's are also often too many.
By a Source code cleanup can save up to half of the data!

Clean code

Help the browser! With clean HTML code, it can display pages faster. Many tags don't actually need a final day, e.g.

,

  • , , , others forgive it in most browsers if it is missing, e.g. .
    But the browser has to calculate every time where the closing day should have been, that takes time.
    Here are those too width and height specifications to mention graphics that should always be used. This information accelerates the screen layout, and the subjective readability of the page is also faster. Without this information, older browsers also have difficulties with JavaScripts that affect these graphics.
    Also the old indication graphics should not be missing. They make it possible to see what is hidden behind the placeholders for the images while the page is loading.

    Tables

    Tables are not shown until their content fully charged is. This is because the browser does not know beforehand what and where to display it, as the table is aligned as optimally as possible. In the case of nested tables, the computing time increases immensely, since each cell can only be calculated after its content has been calculated, which can then only be displayed - in short: a recursive calculation.
    So the advice can only be to avoid (multiply) nested tables as far as possible and tables right at all short to keep. Instead, it is better to use several tables next to one another or one below the other. In this way, content is already visible if not all tables have been calculated.

    Frames

    There are two aspects to consider when using frames in connection with the issue of speed: On the one hand, a page with frames consists of at least 3 files (the frameset and the at least 2 files that appear in the frames), all of which requested individually from the server Need to become. On the other hand, this only happens the first time, after that only some of the files are reloaded. The profit is not so much with graphic buttons and the like, which would also be loaded from the cache with other methods, than with text (and e.g. scripts in the source code) and above all with the rendering of the page, which then partially stops is already done.

    Scripts

    A lot of data can also be saved in the area of ​​scripts. By the use of external script fileswhich make their functions available to all pages of the site, they only need to be written - and loaded - once. Such a file is defined as follows:
    . It contains the source code (without script tags!) With the functions you need. Save at all Functions, especially if they are formulated as generally as possible, a lot of storage space.

    Left

    It is clear that all the links on a page should work. But links that are actually correct can still be optimized. First of all, all links should point to the actually directory point, not to the beautiful, short domain name, which is only a diversion.
    Then one should note that protocol to be specified, usually http :.
    Third, it is advisable to have one if necessary final slash or specify the standard file name, e.g. /index.html. Otherwise, the server must first determine that it is a directory and not a file.
    A further acceleration results if the data of one side is only from one side or if possible few servers otherwise a connection has to be established to each one.
    Finally, you have to know that the browser only identical also recognizes specified URLs as identical. So: If I have several links in my site to the same URL and put a final slash once, then always! Otherwise the browser will not load from the cache the second time either, but from the network.

    Reusable code

    JavaScript certainly does not offer the same possibilities for "software recycling" as, for example, C ++. When writing the script, the author should still consider whether he really only needs the code once. "Lean Software Production" doesn't just have to be a catchphrase for large corporations!

    A typical example of "one-time code" is the on-the-fly call in the html tag, sometimes quite nested:

     

    <...oncklick="timer=setTimeout('alert(\"Hallo Welt!\")', 5000)">

    The whole thing is distributed over a separately defined function and the call in the tag then looks like this:

     

    <script> function hallo() { timer=setTimeout("alert('Hallo Welt')", 5000);} </script> ... <... onclick="hallo()">

    The code is a little longer - but the function can be called from different places. "It's worth it" from around the 2nd call.

    The function can still be generalized: then you can output different texts, for example, or after waiting times of different lengths:

     

    <script>
    function hello (text, delay) {text1 = text timer = setTimeout ("alert (text1)", delay); ... <... onclick = "hello ('Hello world!', 5000)"> <... onclick = "hello ('Hello people!', 2000)">

    This can also be improved: If you move the script to an external file, you can not only call it multiple times from one page, but from many pages:

     

    <script type="text/javascript" src="hallo.js" language="JavaScript"></script>

    The longer the function, the more advisable this procedure is.

    Open Source: Show source code

    Do you want to keep the source text of your HTML files secret? Here's the tip: Forget it!

    Certainly there are ways to make reading (or understanding) the source text more difficult. JavaScripts that e.g. right mouse click lock some people off - although there is a corresponding function in every browser menu finds. The use of frames and scripts that output the HTML code make it even more difficult - for the author too!

    Such obstacles can be avoided using the pseudo-protocol view-source: and those who are very curious can also search the browser cache.

    If the goal of a website is to disseminate information, why hide the source code? To hide "bad programming"? Personally, I think that locking my right mouse button is almost a necessity, at least roughly rude - after all, I paid for this function - license fees, download time, ....

    Finally: other functions are also blocked like this: adding to favorites in IE, for example.

    The typography: unity or diversity?

    This question arises as soon as a site goes over a few lines or over a page. Should all pages look somehow the same, or should each look completely different? Do I use many fonts, colors, sizes?

    Here I quote a sentence that belongs to the basics of professional layouts:

    "A newspaper is not a type sample book!"

    This also applies to screen design. I can only recommend the number of Fonts to limit on each page, if possible, not to use more than 3 fonts. The same applies to the font sizes, font colors and other distinctions. When designing websites, it is particularly important to note that Underlines usually refer to a link. Highlighting should therefore be designed differently, e.g. using bold letters. Multiple distinctions, e.g. bold and italic at the same time, should also be avoided.

    These tips provide a certain Clarity the side. The importance of this varies depending on the direction in which the pages are aimed: A page with scientific information (perhaps) relies more on an overview than the invitation to the carnival celebration.

    One hears again and again the demand for a consistent design of a website. Why actually?
    A uniform design increases the Recognition value - and the Memorable. Different background images, fonts, margins on each page signal to the surfer that these pages do not belong together. Each page may - depending on the - be pretty. But who remembers the overall site? What did she look like?

    This also applies to the linguistic style. To make it clear: I should say my visitors on all pages (or on all pages), if I have no special reason to do it differently (e.g. a children's page on the site).

    Conversely, by deviating the design, I can make it clear that a page is not directly related to the site, but only as a quote, reference, ...

    So what points do I have to pay attention to if I want to design the site consistently and consistently?
    Here I would like to mention a few points again without claiming to be exhaustive:

    • Background color / graphics
    • Fonts
    • Font formats
    • Heading formatting
    • Margins
    • Buttons + bullets
    • linguistic style

     

    Exceptions are of course always possible - where they are useful or necessary

    The typography: readability

    An important point is the choice of font. Serif fonts are easier to read on paper, while sans serif fonts appear to be better on the screen. (Serifs are the small crossbars on the letters. The serifs come from a time when letters were still carved in stone. They guide the eye on the paper so that it can better follow the course of the lines.)
    Fonts such as Verdana and Tahoma are specially designed to be easy to read on a screen. Other fonts are less suitable because they require the reader to make some effort to decipher them, e.g. some cursive fonts.
    Please also note the availability of the fonts: The more unusual your ideas are, the lower the chance that they can be realized on any system. Arial is a special Windows font that can be found on other platforms similar to Helvetica, Univers, ...
    One solution is to specify a series of fonts one after the other in the font tag or in the stylesheet: "Verdana, Arial, Helvetica, Univers, sans-serif". If the first font is not found, the browser tries the second, etc. sans-serif and serif are the standard fonts with and without serifs, which should be available on every platform - but do not always look identical.
    Readability can be further increased by using a larger font or, for example, bold fonts in the text.

    The typography: word design

    This is about the technology people use to read and how it can be made easier for them on the screen. First of all, the reading person recognizes Outline of a word, then he checks Details in places where he still expects deviations: one look is enough to grasp a basic meaning, declination, conjugation, etc. follow. If the first look is wrong, the second will often not be able to correct the mistake either: he is looking in the wrong place.

    What to do? First: Avoid capital letter salad.

    Words in capital letters act as a block that is visible to the eye no clues. In addition, such a notation is not considered to be for nothing Violation of netiquettethan yelling at the other person or reader.

    Second, don't start every word with capital letters. This will help the reader wrong Outlines fooled, reading becomes difficult. The same applies of course: not just lowercase letters.

    As third: contrast. Reading on the screen is difficult enough. I don't know the resolution or the size of the output device. So: dark letters on a light background (or vice versa) and be careful with background graphics.

    Finally, fourth: do not choose fonts that are too small! Readable Take fonts! Be careful with shadows and 3D effects.

    The page structure: column set

    How do I build a website? In contrast to the layout of printed matter, 500 years of experience and practice are missing. But some of the principles apply here as there.

    The division into columns. The reason for this is that the reader quickly begins to tire when he can no longer just follow the line with his eyes, but has to move his head. These tiring head movements already set in with crevices starting at around 8 cm. In addition, the reader often loses the line when "jumping back" from the end of the line if the columns are too wide: he ends up in the wrong line.

    An additional effect is that more attractive design the overall side: it appears structured, not like a "lead desert".

    The consequence: columns should also be used in web design.

    The page structure: highlighting

    How does the surfer read? Research has shown that he does not work through the text word for word as he does when reading a book, but usually only skimmed. Time is money on the Internet too, so the reader tries to grasp the content as quickly as possible.

    Let's give the reader this chance. By Highlighting, e.g. bold, it is much easier for him - if the essential points are really emphasized. Here, too, the following applies: Exaggeration only harms, because too much bold type makes the page uneasy, i.e. difficult to read. A mixture of many different awards - bold, italic, underlined, ... - confuses more than it uses.

    There are other ways to increase readability, e.g .:

    • Lists - with not too many sub-items (approx. 5-7 are optimal),
    • Icons
    • Illustrations
    • Subheadings

    The page structure: keep it short!

    The first rules of web design include: Keep the pages short!

    The surfer doesn't like scrolling: vertically reluctant, not at all horizontally. The scrolling screen is annoying at least. It gets worse when the reader has to scroll back. Even in the classic "paper text" it is considered bad style to force the reader to page back. Avoid horizontal scrolling as much as possible, and structure the texts simply and logically! Note also lower screen resolutions! Distribute long texts rather on several pages - with about two to three screen pages should definitely be the end.

    The surfer is under pressure while reading: the supervisor is lurking, the fees are running, ... He wants quick information - that's why he searches the Internet! So many surfers only pay attention to the first lines - if they are uninteresting, he clicks on.
    So give him one at the beginning of longer texts Summary. So he can quickly see whether he is on the right side.

    The page structure: ready to print

    The website should therefore correspond to one (or at most three) screen pages if possible. The more closely related a text as a whole, the greater the likelihood that the reader will read the text download or print would like - here he has a lot of work to do.

    Let's offer him some help here too: A special file for this purpose. This doesn't necessarily have to be a HTML file even if it is obvious. Ultimately, the file format should be able to essentially take over the design (e.g. graphics and formatting) and be readable by the surfer. That leaves mainly that next to HTML PDF format leftover, for which Acrobat Reader is available on most platforms; but not everyone can write in this format.

    If you use HTML, the use of the relatively new possibilities for stylesheets for print output is obvious. At least the page break should be controlled in this way to control the otherwise often strange print output:

    <style> h1, h2, h3 { page-break-before: always; } </style>

    Photos or cliparts?

    When illustrating a website, everyone should ask themselves whether they prefer to work with photos or with drawings. It's not just a matter of File size, the following points must also be taken into account from a design point of view:

    • Photos and drawings are different abstract. A drawing is always more abstract and general than a photo. For example, the photo shows a certain person at a certain time and in a certain environment: this is clear even if you do not know the person. Every drawing is less precise: even the most precise drawing only shows "some" person. In principle, this also applies to things.
    • This abstraction should be reflected on the website: When I introduce myself as an author, I usually take a photo, if I need a symbol for "people in general", a drawing. If I want to show "a lot of people", I use a graphic, when it comes to Cebit '99, I take a photo of the Microsoft booth :).
    • If the things shown in a photo are almost abstract in themselves, photos can also be used as symbols: e.g. banknotes, a pile of paper clips, a simple telephone or other "mass-produced items". But then you should pay particular attention to using only photos (or just drawings) in order to avoid irritation. I am currently using symbols to clarify something and to make it as easily recognizable as possible. If I mix different levels of abstraction, this means for the viewer: Button x (with the drawing of an email) is abstract, on button y I see a photo of a printer, and because the abstract button x has a drawing, y must be yes concrete this one shown Company printer (beep) mean. Can I not print on my (beep-beep) now?

    What kind of pictures do you take?

    A picture is worth a thousand words...
    and accordingly requires a lot of memory. The use of images on websites is always faced with this dichotomy. Use images and graphics (and sounds, videos, etc.) only where they support the message of the text, add, clarify or replace something. Pictures as pure decoration cost the visitor time and money, and they also distract from the content of the actual statements. Of course, we also have tips for reducing the amount of data in images.

    There is a separate section on the use of photos or graphics that explains the differences.

    When you use photos, are you showing people - maybe yourself? People give the site a human touch, a personal note. For humans, humans are still the most interesting thing to look at - not just naked.

    Why don't you save color. Subtle images are more elegant, b / w photos and graphics have a documentary character, are more precise, more concise.

    Two examples: The "zone border" to the former GDR was almost always photographed in black and white. Even a dump in the drizzle still has something idyllic on a color photo.

    In addition, grayscale images look at least as if they were smaller and therefore loaded faster.

    How do I get the pictures shrunk?

    Images on the Internet always have too much data. There are various ways to reduce this:

    • Choose the correct file format. GIF and JP (E) G are common. GIFs represent 256 colors, can be animated and are particularly suitable for images with uniform color areas, e.g. for drawings. They compress without loss.
      JPEGs show up to 16 million colors and the compression can be set. The compression works with quality losses that depend on the compression rate. This format is particularly suitable for photos and images with color gradients.
      Try out the different formats and settings until you find the optimal balance between quality and space requirements.
      Please also note that the compression only reduces the space required on the data carrier and the size of the download. The requirement in the main memory remains the same!
    • Save the images in the size you want them to be displayed. Reducing the size using the HTML attributes height and width is a waste of memory.
    • Reduce the color depth if possible. If it is a GIF: If necessary, reduce the number of colors: this also saves capacity.
    • Show the pictures in a smaller format. Often a picture is enough without affecting the message.
    • Offer the viewer images as a small preview with a link to an overall view. So he can decide for himself whether to accept longer download times.

    Where do the advertising windows come from?

    Almost every surfer has come across pages at one point where another one window was opened: with advertising. As a rule, the site was hosted by a provider of free web space, e.g. Tripod, Puretec or Schlund. These providers live from advertising, without which they would not be able to offer the storage space for free. Therefore the start page, e.g. "index.html" uploaded by the site administrator, will be the same Beginning or on end with a Script equipped and mostly saved under a different name. This new start file is then sent to the Internet when the directory is called up and the advertising window opens immediately.

    Now if my uploaded file contains a script that you put in the foreground pushes, the advertisement disappears in the background (where the guest can review it later). This script is very simple: focus (). If the advertising script is at the beginning, I also put it at the beginning; if the advertising is at the end, I call it via onload = "focus ()" in the body tag.

    By the way, you should keep the start file for later changes local to save. If you upload it from the network for each change and then upload it again afterwards, another advertising window is added each time!

    The question of advertising is also hotly debated. While the Internet community was unanimous a short time ago in rejecting any kind of commercialization, there have recently been opposing trends - and not on the part of the corporations. The WebWasher program from Siemens, for example, which filters out unwanted advertising banners, met with resistance and led to the establishment of an initiative by various webmasters.

    In any case, it is clear that many offers on the Internet are only free because they are financed with advertising!

    Where am I?

    Working with frames (mostly) shortens loading times, ensures a uniform appearance and makes it easier to navigate through complex sites. Usually the frameset is already loaded with the homepage. If you come across a single page, e.g. via a search engine, it stands alone.

    There are different ones here Solutions. For example, a "normal" link is possible, for example at the foot of the page, which points to the homepage, which then loads the frameset. This variant enables "escape" from the side, but always on the detour via the homepage. But you can also load the frameset directly using a script, if necessary. To do this, the script checks the existence of frames; if there are none, the frameset is loaded at the point of the document. The contents of the neighboring frames are available immediately, but the loading time increases because the document is loaded twice. This process does not work with browsers that do not support JavaScript, which may have to be taken into account. A combination either version solves the problem.

    Foreground and background

    Readability

    Various aspects must be taken into account in order to ensure the legibility of a website. First of all, a high contrast between the foreground and background is important. Black text on a white background is ideal - but of course not very exciting. It should also be noted that e.g. red text on a blue background can be read on most systems, but no longer on b / w screens (they still exist!).
    The background should therefore have little contrast so that it does not mix with the text.
    You also have to pay attention to the colors of the links!

    Background image and color

    When I define a background graphic in the body tag, I also specify a background color that corresponds as closely as possible to the main color of the background graphic.
    Once the page has been loaded, you can no longer see it. During loading, however, you first see the background color and only later the graphic. This makes the page readable more quickly and resembles its final appearance early on.

    Transparency and background

    Do you create the buttons and graphics for your homepage yourself? If so, when using transparent colors for GIFs, make sure that you match them to the background color of your homepage. The color to be transparent should be the same as the main background color of the page. Particularly when using gradient shadows, light edges are avoided because the shadow runs in the same color when it is created as it is later when it is used on the page.

    All just stolen?

    Foreign sites in their own frames calling up is almost always impolite, usually legally problematic, rarely nice and often the result of sloppy work. The solution is similar to that for the navigation frames: Check whether the page is in a frame, if so, it will be reloaded in the top window. Both methods can be combined: If a single page is called up from a third-party frame, it appears correctly in its own frameset - and only in its own frameset - on the screen.

    Profound and precise - screen design problems

    How should I position something on the screen if I should or want to do without DHTML?
    HTML provides (at least) two options: frames and tables. Both divide the screen into boxes, both can be given in relative and absolute dimensions. A combination of both techniques enables very precise positioning.

    The pros and cons of frames are hotly debated. In my opinion, however, the advantages outweigh this. A navigation column or line is not scrolled away, but always remains visible (and does not have to be reloaded when changing pages). The same applies to a headline which, for example, is in its own frame on this site. Each file loads its heading into the frame at the top right so that the current title changes when you change pages. When you scroll across the page, you still always know where you are. Of course, it is important to work particularly carefully when using frames so that the right files always end up in the right frame - and foreign sites are not involuntarily trapped in your own. The layout can pose a further problem, as frames usually occupy a part of the screen that is defined with pixel accuracy. The remainder for the main window disappears oversized at low resolutions, so that an alternative design may be necessary.

    The ability to assign a separate background image to each frame and table cell, enables nice effects (and a good deal of chaos if exaggerated). The example shows a variant of this site. Frame 4 as the main window has a background image showing water droplets. Frames 2 and 3 show the same picture, but it becomes darker towards the left and towards the top. Finally, frame 1 shows the picture with the corner rolled up. The tiling in frames 2, 3 and 4 of course saves a lot of storage space and thus transmission time, but still brings some variety to the picture.
    The background images in Table 2 are another variation. The header is given a darkened background, every second of the following lines is given a lightened background.

    Automatic page change

    Problem: You want one "Splash screen" integrated into your site, which automatically redirects the surfer to the actual homepage after a few seconds. With the various options available here, there are also various difficulties that arise from them.

    • by tag: This tag in the file head redirects to the specified following page after 5 seconds:

      <meta http-equiv="refresh" content="5; URL=http://www.pigasus.de">

      Some search engines ignore pages with this tag or if the waiting time is too short, as this is to avoid duplicate ads from identical pages with different URLs. Unfortunately, this redirection does not work with every browser, so the option of manual redirection with a normal link is strongly recommended.

       

    • via location.href: With a little JavaScript the goal can also be achieved:

      timer = setTimeout ("self.location.href = 'newfile.htm'", 5000);

      Here, too, the browser must at least understand JavaScript.

       

    • via location.replace: Another JavaScript technique would be this:

      timer = setTimeout ("window.location.replace ('newfile.htm')", 5000);

      It works from JavaScript 1.1 (i.e. NN3 or IE4), so this should be checked, e.g. by giving the script tag a corresponding parameter:

      <script language="javascript1.1">

      The advantage here is that the splash screen no longer appears in the history. If he did, you would be redirected to the front again when you click the back button. The replace overwrites the current history position with the subsequent file.

     

    Pixel perfect?

    Nowadays almost every HTML editor claims to be able to do pixel-perfect screen design. Very few are actually able to do so. One example is the pixel offset, i.e. the distance from the edge of the window to the content of the page. It varies from browser to browser and from system to system:

     

    Browsermore horizontal
    Offset
    more vertical
    Offset
    IE 5.x Win10 px15 px
    NN 4.x Win8 px8 px
    NN 4.x Mac8 px8 px
    IE 4.x Win10 px15 px
    IE 4.x Mac8 px8 px
    NN 3.x Win10 px15 px
    NN 3.x Mac8 px8 px
    IE 3.x Win10 px16 px
    IE 3.x Mac8 px8 px

    A remedy is relatively easy to create: The correct attributes in the body tag switch off the offset:

    <body marginwidth=0 marginheight=0 leftmargin=0 topmargin=0>

    Too much exercise only hurts

    Movement on the screen is a popular way to get the guest's attention. Animated GIFs, text scrollers, mouseover effects, moving levels, marquee and blink tags, Java applets, ...: There is twitching everywhere.

    But when everything revolves around you, instead of attention confusion donated. This is how the "fidget GIFs" got their bad reputation. So if the goal is the guest's interest, you should stick to the old rule: Maximum one animated GIF per page. This also applies to the other techniques.

    Marquee and blink days should be avoided altogether. They are only understood by a few browsers and: they are relatively easy to replace by generally understandable scripts.

    If you love gimmicks and want more exercise, you should limit them elsewhere, e.g. not everywhere, but only on the start page, or not permanently, but only temporarily . The main page of this site, for example, starts off rather desolately, but after a few seconds it quiets down. All balls are in their place, the pig has flown by, the visitor can concentrate on the news in the ticker.

    Animated GIF files can also be limited in this way: They then run through and then stop.

    With all effects, it should be noted that they often cause larger files and thus longer download times. Here, too, less is often more.


    HTML? Logical!

    With HTML, one can distinguish between two types of tags for text markup: logical and physical. A physical text markup establishes that Look of text, e.g. for bold or for italic. In contrast to this, there are the logical distinctions, the content-related structure of the text. Examples: for emphasized, for strongly emphasized,

    for a first-order heading. The appearance is left to the browsers, but they react fairly uniformly and display italics and bold, for example.

    With the triumph of graphical user interfaces, especially with browsers, the logical approach fell behind; everyone wanted to be master of the presentation of his pages. Mostly inconsistent, however: Some tags like

    or even the

    to

    were able to hold the position. With Style sheets, whose support has meanwhile established itself in all important current browsers, offers the possibility to work logically again.

    Why? Now, with the emergence of new techniques for accessing the WWW, the old logical text markups are taking on new meaning. From the output in Braille via Speech output The possibilities extend to the tiny cell phone display. Using the example of the voice output, it is easy to show what it is about: Stressed or very stressed pronunciation is easy to understand and easy to implement, and labeling as a quote, address, etc. leaves many options for emphasis open. But have you ever pronounced something in bold, or in italics, underlined or possibly blinking?

    Of course, the primary human sense is the eye, and visitors to most sites will never notice a difference between and . The look of a site can be provided wonderfully with style sheets, if you don't trust the , you can even explicitly assign it the property "bold". Style sheets can be used to determine the look of a site in great detail, and if the site is relaunched with a new look, changes can be made quickly at a central point. The W3C also follows this approach with its Accessibility guidelines and his recommendation for the use of style sheets. And at least no commercial site can really afford to exclude even a part of the visitors.

    Visual filters

    The so-called Visual filter. The filters allow effects on text and graphics for which you previously had to create your own images. The filter saves download time and the filter setting can also be influenced by the visitor or used by a script for an animation.

    Possible applications are mouse-over effects that do not require a second image and also work with texts, or e.g. shadow effects for headings - without graphics.

    As with all browser-specific things, caution is advised! A filter is nice as an edge effect, but when it is needed to display essential information, it blocks half the Internet community from access. In the meantime, however, there is probably a plug-in for the navigator.

    Very nice effects result when the filter is applied to the whole page: . In this example, for example, the page content runs outwards like an effect lens.

    On the filter test page you can try out different (not all) filter settings and see the effect directly.

    Addendum: With IE 5.5, the filters sometimes no longer work. We haven't checked it yet with IE6 / 7.