HTML
les trucs d'Asp Explorer

évite les bouloches
sous réserve d'acceptation du dossier
retarde le vieillissement naturel de la peau
maxi-absorbant
n'abîme pas les mains
avec de savoureux morceaux de chaton
sans visite médicale ni questionnaire de santé
Protège vos #couleurs
crédit gratuit
avec les petits élastiques
recommandé par de grandes marques de machines
désinfecte et désodorise entre les octets
pour un site web brillant et soyeux comme au premier jour
si c'est trop petit pour vous
augmentez la taille de la fonte par défaut
ou voyez un ophtalmo


Voilà un bon moment maintenant que je traine mes guêtres dans l'univers merveilleux du HTML, et nombre de pages ai-je composé, plus ou moins réussies. Afin de vous éviter quelques erreurs dans lesquelles je me suis fourvoyé, voici divers conseils, trucs et remarques plus ou moins pertinentes que je vous livre gentiment et de mon propre gré, essentiellement pour soulager mon guide HTML qui commence a être lourd.

  1. Choisissez judicieusement votre fond et votre texte
  2. Diatribe contre le JAVA
  3. Du bon usage des tableaux
  4. A propos des formats d'image
  5. Faire une galerie d'images en évitant de passer pour une buse
  6. HEIGHT et WIDTH, c 'est pas pour les chiens
  7. Attention à la taille des homepages...
  8. ... et le truc de la disquette
  9. Les liens automatiques
RETOURNER AU GUIDE
"DO IT YOURSELF"

Le fond compte autant que la form.

Comme vous le savez, le tag <BODY BACKGROUND="trucmuche.jpg"> permet de choisir un fond pour votre page. Moyennant quoi, ladite page ne sera pas forcément lisible. Trois règles sont à observer.

Tout d'abord, il faut un contraste entre le fond et le texte. Mais ce doit être un contraste de LUMINOSITE et non un contraste de couleurs. Par exemple, si vous écrivez en vert sur fond rouge, même si vous n'êtes pas daltonien, vous aurez du mal à lire, et ça vous fera vite mal aux yeux et à la tête. Pour la petite histoire, c'est normal. Votre cerveau (je pars du principe que vous appartenez à l'espèce humaine) est ainsi faite que le traitement des couleurs et le traitement des formes se font dans deux zones séparées. Et la lecture, désolé, c'est de la reconnaissance de formes. Il est facile de lire du rouge clair sur vert sombre, mais c'est uniquement en raison du contraste de luminosité (gris clair sur gris foncé, c'est exactement pareil). Avec un vert et un rouge de même luminosité, c'est migraine assurée.

Deuxième point, qui est clair et qui est foncé? Si vous écrivez en clair sur fond sombre, ou en sombre sur fond clair, ce sera lisible de la même manière. Cependant, si votre page est destinée à être lue sur un écran d'ordinateur, vous aurez avantage à préferer l'écriture claire sur fond foncé, c'est plus reposant pour les yeux. Inversement, si votre oeuvre est destinée à l'impression, le foncé sur fond clair (de préférence blanc) économisera la cartouche d'impression des utilisateurs trop neuneus pour sauvegarder en mode texte et imprimer dans wordpad (Vous notez au passage que c'est ce que j'ai fait avec cette page. Mais non, mais non, je ne vous prend pas pour des neuneus).

Troisième point, un truc a savoir : beaucoup d'utilisateurs débranchent l'option "télécharger automatiquement les images" de leur browser, pour aller plus vite, et ils ont raison. Donc, dans le <BODY>, mettez un BGCOLOR d'une teinte voisine de celle de l'image de fond. J'ai souvent visité des sites écrits en blanc sur blanc, donc illisibles, parce que je n'avais pas chargé l'image de fond marron foncé. Notez que si une telle aventure un jour vous arrive, vous pouvez vous en sortir en sélectionnant (avec la souris) le texte incriminé, qui se mettra alors en couleurs inverses. Mais c'est pas pratique, convenons-en.


Le JAVA est une abomination, tu le banniras de ta page tel le pêcheur impie de ta maison.

Le principe du JAVA est le suivant : dans la page HTML, une balise force le browser à charger un programme appelé "applet java", et à l'exécuter. L'avantage du JAVA est qu'il est portable, c'est à dire qu'un programme conçu sur un ordinateur d'un certain type tournera de la même façon sur un autre ordinateur. Autre avantage du JAVA, il est orienté-objet. La programmation-objet est un concept inventé dans les universités américaines il y a une vingtaine d'années. Personne ne sait exactement quel intérêt on peut tirer de la programmation-objet, mais c'est très à la mode chez les informaticiens, essentiellement parce que c'est effroyablement compliqué. Par exemple, dans un langage normal (comme le BASIC), pour saisir deux nombres au clavier, faire l'addition et afficher le résultat à l'écran, on fait ainsi :

	BEGIN
	INPUT "entrer le premier nombre : ";A
	INPUT "entrer le deuxieme nombre : ";B
	C=A+B
	PRINT "le resultat est : ";C
	END
Maintenant, croyez-moi ou pas, mais le même programme dans un langage orienté-objet (le C++ par exemple) nécessitera une bonne demi-heure de programmation, de débuggage, de recherche dans la documentation et de casse-tête, et prendra pas moins de vingt lignes avant de daigner faire ce pour quoi il est conçu, et encore le fera-t-il mal. Et bien figurez-vous que le JAVA, c'est pire encore. Le moindre bout de java nécessite que l'on ouvre plusieurs fichiers, que l'on charge des librairies spécialisées, et bien sûr, une fois sur deux, ça ne marche pas.

Et tout ce travail est-il justifié? Est-ce qu'un programme en JAVA tourne plus vite ou mieux qu'un homologue en C++ ou même simplement en BASIC? Disons le tout net, non. Le JAVA est un langage désespérément, indécrottablement, majestueusement LENT. Il est lent au point qu'on a été obligé de sortir des processeurs dédiés pour qu'il daigne bouger ses fesses, ce qui est un comble pour un langage sensé être portable. Pour vous donner une idée, disons qu'un programme en BASIC (un langage considéré comme très lent) sur amstrad CPC (un ordinateur 8 bits qui date du siècle dernier) tournera facilement deux ou trois fois plus vite qu'un applet JAVA faisant exactement la même chose sur un pentium II a 300 MHz. Mais là où le programme BASIC "pèsera" 20 ko, l'applet JAVA en occupera facilement plus de 100. Car en plus, les applets JAVA sont des bouts de fichier ENORMES. Mettons que 300 ko soit la limite "acceptable" de ce qu'un internaute normal (un internaute avec un modem et qui paye ses factures à France Telecom) aura la patience de télécharger, sachez que ce volume de code permettra tout juste de faire tourner un casse-brique ou un tetris laid et banal, qui aurait déja fait rire à l'époque de l'atari ST.

J'exagère? Si vous concevez un site à caractère commercial, apprenez que le seul fait de passer d'un site "tout HTML" à un site possédant des applets JAVA divisera le chiffre d'affaires de la page par deux! Les internautes n'ont tout simplement pas la patience d'attendre, devant leur écran inerte, que l'applet daigne se charger, puis que l'interprêteur du navigateur se lance (une dizaine de secondes au moins), puis que le programme se décide enfin à afficher quelques zigouigouis et autres logos-qui-tournent sans intérêt. Les internautes sont comme les téléspectateurs (ce sont souvent les mêmes du reste), quand rien ne se passe à l'écran, ils zappent, ils changent de crêmerie.

Enfin, sachez que pour des raisons de sécurité évidentes, le JAVA ne permet pas d'accéder au système de fichier de l'ordinateur-client.

Bref, aucun intérêt.


Et pris de fureur, Moïse jeta à bas les tableaux, qui se brisèrent en mille fragments.

Si vous aimez placer des tableaux dans vos pages, ma foi, je ne peux que vous en féliciter. Ils permettent un formattage précis des textes et des images et de limiter les variations d'aspect que l'on peut observer d'un browser à l'autre. Mais ceci a un prix, qui est le suivant :

UN TABLEAU NE S'AFFICHE QUE LORSQUE SON CONTENU EST ENTIEREMENT CHARGE!

Kéniaveudire? C'est simple. Lorsque vous chargez une page "normale", sans tableau, avec des textes et des images, ils s'affichent à mesure qu'ils sont chargés. Ainsi, vous pouvez lire le début du site pendant que le reste se télécharge, en bas, bref, vous avez de la lecture pour patienter. Mais si tout est dans un tableau, il faudra attendre que TOUT soit arrivé pour que vous puissiez contempler la page. Voici quelques temps (ça a peut-être changé), la Swissair avait eu l'idée stupide de ranger la liste complète de ses vols dans un seul tableau, qu'il fallait consulter intégralement avant de pouvoir réserver. Lorsqu'on tentait d'y accéder, on restait donc devant un écran blanc (le suisse est propre, c'est bien connu) pendant un temps indéterminé (mais long, car la swissair a beaucoup de lignes). Je me demande combien de clients excédés ils ont perdu avec leur système.

On peut remédier à cette situation en segmentant la page en plusieurs tableaux. Par exemple, s'il vous prend l'idée farfelue de publier une nouvelle sur le web et que vous ayez avantage à la mettre en tableau, ce sera plus confortable à lire si vous faites un tableau par paragraphe, ou un tableau par chapitre, plutôt qu'un tableau pour le tout. Pensez-y.


Les images, jusicieusement, tu les compresseras.

Or donc en le pays de Canaan, il existait plusieurs formats d'image. Et Dieu voyant ceci dit " Voici qui est bon, mais comment se retrouver dans tout ça? " Alors, pour l'édification des fidèles, voici ici narrée la merveilleuse aventure des formats d'image.
(*) - Sauf si vous êtes une femme (**).

(**) - Sauf si vous êtes lesbienne.
Coment épater la galerie.

Vous voulez faire une galerie d'images. Ne mentez pas, je lis dans vos pensées. Vous avez tous vu une galerie d'images, c'est un classique du web. Il s'agit donc d'une collection d'images que le webmaster propose aux internautes. En général, ça se présente sous forme d'une succession de vignettes taille réduite, représentant en réduction les images en question. Ces vignettes, en langage technique, s'appellent des "thumbnails". En cliquant sur un thumbnail, l'image complète s'affiche.

Mais il y a des gens un peu... enfin bref, il y en a qui font les thumbnails de façon un peu bizarre. Par exemple ils ont une image "trucmuche.jpg" de 100 ko mesurant 600x400 pixels, et ils la mettent en thumbnail dans leur galerie en 150x100 pixels (jusque là, rien d'étonnant), mais ils font ça en utilisant la commande suivante : <IMG SRC="trucmuche.jpg" HEIGHT=100 WIDTH=150>. Résultat des courses, pour que le thumbnail s'affiche, il faut télécharger TOUTE l'image de 100 ko. S'il y a 30 images, on arrive à 3 Mo d'images à télécharger pour voir toute la galerie. Ourph. (Le plus amusant, c'est qu'en général, ces tristes sires présentent leurs thumbnails rangés bien sagement dans... un tableau! Tout pour plaire.)

La manière belle et bonne de faire les thumbnails est d'utiliser un logiciel de retouche d'images pour réduire l'image trucmuche.jpg à la taille 150x100, de la sauvegarder sous un autre nom, comme par exemple "trucmuche_thumb.jpg", et c'est CETTE image qui sera affichée dans la galerie. Car normalement, elle pèsera dans les 10 ko, soient 300 ko de thumbnails à charger pour notre galerie de 30 images, c'est tout de même plus pratique pour le visiteur.


Size does matter.

Quand vous incluez une image dans une page, spécifiez TOUJOURS les paramètres WIDTH=XXX et HEIGHT=YYY dans le tag IMG, même si vous voulez l'afficher dans sa taille par défaut. La raison est la suivante : en général, dans une page mêlant textes et images, ce sont les images qui constituent le plus gros du "poids", et qui sont donc les plus lentes à charger. Et votre navigateur affichera plus volontiers le texte autour des images s'il connait la taille des images avant de les charger, c'est l'évidence même. Sinon, vous devrez attendre que l'en-tête de chaque image (contenant ses dimensions) ait été chargée pour que le texte s'affiche, alors que ça faisait trois plombes qu'il était en mémoire. C'est vraiment du gâchis. Le web est suffisamment lent comme ça, c'est pas la peine d'en rajouter avec des maladresses de programmation.


La règle des 100.

La plupart des problèmes évoqués dans cette page viennent d'une mauvaise appréciation des temps de chargement. Le développeur (vous) fait sa page HTML comme il l'entend, puis la teste (plus par vanité que pour vérifier, soyons honnête). Mais il teste la page qu'il a sauvegardé SUR SON DISQUE DUR. Mettons que vous fassiez une page pesant 500 ko (images, sons et zigouigouis compris) et que vous la testiez. Si votre disque dur délivre du 5 Mo/s (la chose est courante), elle mettra 1/10 de seconde pour se charger. il vous semblera alors que votre page est un modèle de fluidité. "tout va bien", vous direz-vous, et vous placerez la page sur votre site sans vous poser plus de question.

Et pourtant, il y a un énorme problème, qui est que le débit moyen sur le web dépasse rarement les 1 ou 2 ko/s. L'utilisateur, s'il désire charger votre page a 2 Mo/s, devra rester 250 secondes (soient 4 minutes) planté devant son écran. A votre avis, en aura-t-il la patience?

Votre site, c'est comme un restaurant. Les pages sont les plats que vous proposez, et la home page est le menu affiché sur la porte. Le client acceptera bien volontier d'attendre une demi-heure qu'arrive sa "sole aux capres verts à la sauce financière et aux petits oignons", mais il ne tolèrera sûrement pas de faire la queue rien que pour voir le menu.

Donc, quand vous faites votre home-page, évitez de dépasser les 100 ko (images comprises, évidemment). Si le "client" estime que le matériel présent votre site vaut le détour (le fils caché de Leonardo DiCaprio, la vie nocturne de Jean-Paul II, les images de Pamela Anderson habillée, par exemple), il sacrifiera bien volontier quelques minutes de son précieux temps de connection a piquer ce qui l'intéresse. Par contre, il ne restera pas des heures planté devant votre home page, rien que pour le plaisir de contempler votre logo-qui-tourne-et-qui-fait-des-bulles.

Mais ce genre de problème est évité avec le truc de la disquette.


Le truc de la disquette.

Comme je l'ai dit plus haut, un site testé sur disque dur donne une fausse impression de rapidité, les temps de chargement sont un millier de fois inférieurs que sur le web. Mais vous pouvez très simplement simuler la lenteur des connections d'internet, et ce avec une simple disquette. Mais si, souvenez-vous, ces petits carrés de plastique qu'on utilisait avant l'invention du CD-RW.

Il suffit pour cela de sauvegarder votre oeuvre dessus (la disquette), puis de le charger depuis votre navigateur (open file - a:\ ... enfin, je vous laisse faire la manip). Une disquette se vide à la vitesse de 40 ko/s environ, ce qui est certes beaucoup plus rapide qu'internet, mais infiniment plus lent que le disque dur, vous en conviendrez. Ainsi, vous aurez une petite idée de ce que voit un utilisateur extérieur qui se connecte sur votre site, et ce avant même de l'avoir uploadé.


Le lien automatique.

Pour quelque raison, il est possible que vous ayez avantage à envoyer directement vos lecteurs sur une autre page (par exemple, si vous changez de fournisseur d'acces). La chose est aisée en utilisant le tag
<META HTTP-EQUIV="refresh" CONTENT="5; URL=http://www.adresse.zb/monsite.htm">
Le 5 est le nombre de secondes d'attente avant le renvoi automatique vers l'autre page.