À propos du site merle-blanc.net, notes

Notes

Obtention des entités HTML : Le texte des pages de ce site a été d'abord saisi normalement au clavier sous Word 5 pour MS-DOS, puis les lettres accentuées (codées selon le jeu IBM-DOS) ont été converties en entités HTML à l'aide de la fonction de remplacement automatique de caractères de ce traitement de texte. Celui-ci est plus commode pour un tel emploi que les différentes versions de Word pour Windows (ou que les autres éditeurs de texte disponibles dans cet environnement). Il permet en effet de créer, pour automatiser complètement de tels remplacements sur tout un jeu de caractères, des macros indépendantes du document, donc utilisables sur des fichiers de texte non formatés (pages HTML). De tels fichiers sont en outre gérés plus simplement par Word pour DOS que par Word pour Windows.
Par ailleurs, quelques caractères apparemment normaux perturbent le fonctionnement des robots indexeurs de certains moteurs de recherche. Ils sont alors transcrits ici sous forme d'entités HTML : ? pour le point d'interrogation (?) par exemple. [retour]

Déclaration du jeu de caractères : Il est en principe inutile de déclarer le jeu de caractères ISO-8859-1, puisque c'est celui qui est généralement utilisé par défaut. Il est également en principe inutile de déclarer un jeu de caractères quelconque si on utilise des entités, puisque celles-ci sont normalement reconnues dans tous les cas. Il devrait ainsi suffire, pour assurer la compatibilité avec les divers navigateurs, d'utiliser soit des entités, soit les caractères ISO-8859-1, sans déclarer en en-tête de jeu particulier. Les précautions prises ici sont donc clairement redondantes. Mais la redondance des précautions est un moyen classique de réduction des risques. [back]

Codes de mise en page : Le blanc de bas de page est obtenu en ajoutant, après la dernière commande significative, deux codes de changement de ligne (balise <br>). Le code de toutes les pages de ce site se termine donc ainsi :
<br><br></body></HTML>
Les marges sont obtenues en plaçant le contenu des pages dans des tables définies par un code du type :
<center><table width="95%" border=0>
[...]
</table></center>
où [...] représente le contenu, correctement encadré par les balises <tr>...</tr> (définition d'une ligne dans la table) et <td>...</td> (définition d'une cellule dans la ligne). L'espace inter-colonnes est obtenu, s'il y a lieu, par création d'une cellule vide au moyen du code <td width="1%"> </td>. La largeur des deux cellules correspondant aux colonnes est alors définie de façon appropriée (ici "47%") pour que la largeur totale soit égale à celle choisie pour la table (ici "95%", soit 95% de la largeur de l'écran, indépendamment de la résolution). Le centrage de la table a évidemment pour but de créer des marges égales à droite et à gauche. Pour plus de détails, vous pouvez examiner, voire importer, le code source d'une page dont la présentation vous intéresse. Vous y trouverez peut-être la balise <object>...</object> à des endroits où elle semble inutile. Je l'avais initialement insérée chaque fois que la procédure de validation du W3C le demandait. Mais le robot du W3C semble avoir été corrigé sur ce point, et j'ai essayé depuis de supprimer cette balise où elle n'était pas requise. [retour]

Compromis entre les résolutions d'écran : La plupart des pages de ce site seront visualisées de façon plus agréable à une résolution de 800×600 pixels tout en conservant une présentation acceptable à la résolution de 640×400 pixels. Quelques éléments (vignettes cliquables par exemple) seront cependant peut-être plus lisibles à cette dernière résolution. Aux résolutions de 1024×768 pixels et plus, beaucoup d'éléments apparaîtront sans doute trop petits, et les lignes de texte trop longues (sauf en présentation sur deux colonnes) pour une lecture facile. Mais c'est là un défaut général de ces résolutions, qui doivent être évitées à moins de disposer d'un très grand écran (au moins 17 pouces) pour rétablir une ergonomie visuelle normale. La difficulté du compromis entre résolutions est illustrée par la page index consacrée à Brest 2000, la seule qui soit formatée en largeur absolue (pour pouvoir positionner le texte par raport à un fond de page à bordure). Cette page s'affiche parfaitement à la résolution de 800×600pixels, mais déborde le cadre d'un écran de 640×400 pixels. Un défilement horizontal reste donc nécessaire dans ce cas, mais seulement pour positionner une fois pour toutes l'affichage sur la colonne de texte en anglais ou sur la colonne de texte en français. Aux résolutions les plus hautes, la marge de droite apparaît un peu trop large mais la page reste lisible, avec un meilleur confort sur grand écran. [retour]

Fenêtres (frames) : En dehors des problèmes de compatibilité avec diverses résolutions d'écran, l'un des inconvénients de cette présentation est que seule l'adresse de la fenêtre principale est affichée sur la ligne d'adresse du navigateur et accessible à la fonction add bookmark de celui-ci. Il est donc impossible de créer des signets pour les pages individuelles d'un site présenté en fenêtres. La même impossibilité s'applique aux pages ou sites extérieurs auxquels on accède en suivant les liens que comporte un tel site. [retour]

Erreurs Javascript : L'effet le plus bénin d'une erreur de programmation Javascript est l'affichage, en lieu et place de l'effet recherché, du texte du script lui-même en surimpression sur la page, qui se charge par ailleurs à peu près normalement et dont les liens restent fonctionnels. Le second stade est l'ouverture d'une fenêtre d'alarme comportant un message du genre :
Javascript error on line 56:
http://tel_site is not a number
Il faut alors cliquer sur un bouton OK pour fermer la fenêtre et la suite se déroule plus ou moins normalement. Au troisième stade aucun lien ne fonctionne sur la page affichée, pas même le bouton de retour, et la seule possibilité est de fermer le navigateur. Au quatrième stade, cette dernière fonction elle-même est inaccessible et il ne reste plus qu'à arrêter et/ou relancer l'ordinateur. Diverses variantes de ces effets peuvent se produire, telles que par exemple un blocage complet du système accompagné de l'affichage du code Javascript à l'exclusion de tout autre contenu de la page. Un cas particulièrement fréquent est celui où le navigateur se trouve aux prises avec un fichier pourvu du suffixe .js et dont il ne sait pas quoi faire. Un Javascript, enregistré dans un fichier-source séparé, a dans ce cas été appelé sur la page par un code tel que :
<script src="le_fichier_source.js"></script>
Certains navigateurs ne reconnaissent pas implicitement le code Javascript ou le suffixe .js. Pour qu'ils puissent se comporter en pareil cas comme attendu, il aurait fallu écrire, comme l'exige la norme HTML :
<script type="text/javascript" src="le_fichier_source.js"></script>
D'une manière générale, ni les navigateurs, ni leurs moteurs d'interprétation de scripts ne réagissent de façon identique aux erreurs de programmation HTML ou Javascript. Netscape 3, par exemple, tolère des erreurs d'ouverture/fermeture des balises HTML que d'autres navigateurs ne supporteraient pas et admet que des valeurs non strictement numériques de paramètres (telles que la largeur relative width="95%") soient écrites sans guillemets, ce que les normes HTML interdisent. Le moteur Javascript du même Netscape 3 semble en revanche plus intolérant que celui d'autres navigateurs aux erreurs de ce genre. Pour ne pas afficher la fenêtre d'alarme sus-mentionnée il aurait sans soute requis que http://tel_site soit écrit "http://tel_site". Il ne suffit donc pas, pour s'assurer qu'un code Javascript est correct, de le tester avec un seul navigateur, et surtout pas avec la dernière version, qui peut avoir reçu des fonctionnalités nouvelles et spécifiques. Alors que le service de validation du W3C (comme d'autres services analogues) permet de vérifier, indépendamment de tout navigateur, la parfaite conformité aux normes du code HTML, je ne connais malheureusement pas de service comparable pour le code Javascript. En l'absence d'une telle vérification, le plus sage est de s'abstenir d'utiliser ce dernier, d'autant qu'un certain nombre d'internautes le désactivent sur leur navigateur par mesure de sécurité. [retour]

Sites surchargés : Sans doute ces sites ont-ils été conçus par des publicitaires habitués à produire ces prospectus richement illustrés qui inondent nos boîtes aux lettres et finissent dans la poubelle sans un regard. Mais il est peu coûteux de jeter un bout de papier à la corbeille, et même d'y jeter d'abord un coup d'oeil à tout hasard. Il suffit peut-être que 2 ou 3% des destinataires aient ce dernier réflexe pour que l'investissement (le gaspillage) publicitaire soit rentabilisé. Les choses sont bien différentes pour un site web. Il est parfaitement intolérable d'attendre 10 minutes ou plus le téléchargement d'une page parce que la publicité en domine le contenu, d'autant plus si l'on doit pour cela payer des communications téléphoniques. Et quand un site vous a gelé à plusieurs reprises votre ordinateur par des erreurs javascript, on le met en liste noire et on ne s'y connecte plus. Les multiples agences qui du jour au lendemain s'autoproclament spécialistes de la communication en ligne tombent régulièrement dans ces pièges et n'ont visiblement rien compris aux spécificités d'Internet. Le cimetière des "startups" est d'ailleurs là pour en témoigner. [retour]

Bonnet d'âne : Mérité par le site d'un quotidien publié en Bretagne et par ses sites satellites, pour la lenteur du téléchargement. L'un de ces sites est dédié à la voile, et j'aurais dû lui consacrer un lien dans mes pages sur Brest 2000. Je ne l'ai pas fait, faute d'avoir pu, malgré plusieurs essais, accéder à ce site dans des délais raisonnables pour vérifier son contenu. Bonnet d'âne mérité par le site musical du même groupe de presse, qui requiert l'installation spécifique d'un "plug-in" fort peu répandu, en plus des Real-Audio et autres Quick-Time qui peuvent vous avoir été imposés par ailleurs. Pendant un temps, la page d'accueil de l'édition en ligne du quotidien refusait même de s'afficher en entier avec certains navigateurs, rendant inaccessibles les liens vers le reste du site. [retour]

Bonnet d'âne (bis) : Mérité par le site principal d'un des établissements du service public audiovisuel français. Dans mon environnement logiciel, que je n'ai ni les moyens, ni le temps, ni l'envie de changer à seule fin d'accéder à ce site, les boutons à cliquer du menu à droite des différentes pages sont irrémédiablement masqués par la barre de défilement vertical, même si on choisit une faible résolution pour forcer l'apparition d'une barre de défilement horizontal. Le formulaire d'envoi de courrier sur la page d'accueil ne fonctionne pas, mais le site n'offre pas d'annuaire des adresses électroniques des personnes ou services de la maison auxquels on pourrait avoir envie d'écrire. En septembre 2000, les fichiers sonores que le site envoie n'étaient déjà plus reconnus par le plug-in que j'avais dû installer spécialement quelques mois plus tôt pour pouvoir écouter ce site. Ledit plug-in était pourtant toujours recommandé sur certaines pages du site, concuremment avec un autre que j'ai aussi mais qui ne fonctionne pas non plus (problème de version ?). Certaines pages comportent une erreur de programmation Javascript dont l'effet bloque le fonctionnement de mon ordinateur. S'il y a d'autres erreurs, ce blocage m'a empêché de les découvrir. [retour]

Cookies : Dans mon cas particulier, les sites qui recourent à des avalanches de cookies en sont pour leurs frais, car j'ai configuré mon système de telle sorte que ces cookies soient automatiquement effacés de mon disque dur, en même temps que l'historique des connexions et d'autres traces potentiellement indiscrètes, à la fin de chaque session. Mettre en place ce genre de routine est malheureusement plus difficile dans d'autres environnements logiciels, en particulier les plus récents des systèmes destinés au grand public. Et ce n'est sans doute pas un hasard. [retour]

"... ni aucun dommage à l'environnement ..." L'ensemble de ce paragraphe a évidemment pour but principal de tourner en dérision à la fois la censure et une certaine forme d'activisme politiquement correct, particulièrement répandu dans les pays anglo-saxons. Pour un site qui présente notamment des documents originaux issus de la chasse photographique, l'affirmation que les animaux concernés n'ont pas été maltraités (ni en fait sérieusement dérangés) n'est cependant pas totalement triviale. Certains auteurs fort connus de documentaires commerciaux sur la vie animale, notamment marine, ont souvent porté beaucoup moins d'attention à ce genre de scrupules qu'à la recherche d'images vendables. En outre, il n'est bien entendu pas totalement vrai qu'aucun dommage n'ait été causé à l'environnement. Si certains des lieux où ont été prises mes photos ne sont accessibles qu'au prix d'une longue marche, j'ai d'abord dû pour m'y rendre emprunter des voitures, des avions et des bateaux à moteur. Et la chimie photographique n'est pas toujours totalement inoffensive. En l'état actuel des techniques, aucune activité humaine n'est en fait totalement respectueuse de l'environnement. Peut-être en paieront nous le prix plus tôt que nous ne le pensons. [retour]

Adresses du site : L'adresse en nom de domaine propre du présent site peut aussi s'écrire http://www.merle-blanc.net, http://www.merle-blanc.org ou http://www.merle-blanc.com. Les adresses directes utilisées pour ce site chez free.fr pendant quelques mois (http://jlf0.free.fr, http://jlf0.online.fr, http://merle.blanc.free.fr, http://merle.blanc.online.fr) donnent maintenant accès à des pages de redirection. La version initiale du site était accessible à http://altern.org/jlf ou http://www.altern.org/jlf et c'est toujours l'adresse électronique correspondante qui est utilisée pour le courrier. [retour]