Considérations sur le HTML 3.2 dernière mise à jour : 24 février 2000 — sommaire général La version 3.2 du « HyperText Markup Language » a fait les beaux jours du « World Wide Web » en offrant un standard dans la mise en page des documents textes & images publiés sur le web. Grâce à des tags idoines, le HTML 3.2 permet même d'inclure du JavaScript dans ses pages, ainsi que des applets Java, des films et du son, du streaming RealVideo ou QuickTime, et plein d'autres choses qui s'appuient sur les plug-ins des navigateurs. Aujourd'hui beaucoup parlent du HTML 4, qui étend le 3.2 en lui rajoutant feuilles de styles et rigueur. Mais pourquoi se ruer vers une technologie émergente, au mépris de son aînée, alors que celle-ci est déjà si riche et si mal employée ? L'état de la majorité des sites écrits en 3.2 ne laisse rien augurer de bon quant à leur passage à la version 4… 1. La syntaxe 1.1. Grammaire et orthographe en français Souvent catastrophiques sur le web. 1.2. Ponctuation en français En français on doit utiliser les guillemets chevrons < « > et < » > au lieu des guillemets anglo-saxons < “ > et < ” >, que du reste personne n'utilise ; on préfère généralement les bons vieux guillemets de machine à écrire < " >. Pfff. En typographie française on doit jouer avec les espaces : fines, simples, cadratins et demi-cadratins se glissent entre points-virgules, deux-points, tirets, guillemets, points d'exclamation et d'interrogation… On n'a pas sur le web autant de choix, mais on pourrait quand même se fendre d'espaces insécables pour agrémenter les textes ! Sans parler des tirets < — > que tout le monde remplace par des traits d'union < - >… Se reporter à la page sur les caractères spéciaux. 1.3. Respect des normes du W3C On rencontre énormément de sites dans lesquels les <TABLE> sont encastrées dans des tags de styles comme <SMALL>, ou avec des tags qui se chevauchent au lieu d'être imbriqués… Et les accents ! Actuellement de plus en plus de webmasters et de logiciels laissent leurs accents tels quels sans prendre la peine de les coder en HTML ! Si encore ils précisaient l'encodage qu'ils utilisent par un <META HTTP-EQUIV="content-type" CONTENT="text/html; charset=iso-8859-1">, par exemple ! Mais non, ils croient qu'ils sont seuls au monde. Déjà qu'ils oublient le <!DOCTYPE ...>… Et ce n'est pas forcément dû qu'aux webmasters. Des logiciels comme Microsoft FrontPage pondent du code lamentablement incorrect… Notez que le code issu de FrontPage est parfaitement compréhensible par Microsoft Internet Explorer et seulement par lui ! Je vous laisse tirer vos propres conclusions… Qu'attendent les webmasters pour coder correctement le simple HTML ? Hélas, ils préfèrent plaquer sur leurs sites mal écrits des techniques sophistiquées qu'ils maîtrisent souvent mal… 2. Les frames Mal employées dans la majorité des cas. On sait par exemple, que mettre du texte non formatté (au lieu de l'encapsuler dans des tables) dans une frame, provoque des débordements hideux quand la fenêtre est trop petite ou la police trop grosse. Croyez-vous que ça fasse réfléchir les webmasters, même professionnels ? Pensez donc. Après tout les visiteurs n'ont qu'à acheter des écran 20 pouces. 3. Le JavaScript La plaie du web. Les apprentis webmasters sont tout contents de découvrir un langage de scripts très prometteur, et du coup ils l'utilisent à tout va. Au lieu de gaver le visiteur de fenêtres pop-up, ils feraient mieux de vérifier leur HTML ! voire leur orthographe… Le JavaScript côté client est une horreur totale. Totalement buggé dans Netscape sur Mac, fonctionnant à peu près avec Internet Explorer sur PC, en pratique il alourdit surtout la navigation. Les sites qui imposent l'usage du JavaScript client pour des choses qui pourraient être faites en dynamique côté serveur, devraient être mis à l'index. Je ne donnerai qu'un exemple : le site de la SNCF, qui devint onze fois plus lent — et inaccessible à certains — le jour où ils passèrent au JavaScript. Les sites où le JavaScript est réellement un plus sont assez rares, et toujours intelligemment conçus. 4. Java Les applets Java côté client ne sont pas différentes de ce qu'on télécharge avec les plug-ins. Par conséquent on ferait bien d'en limiter l'usage à l'essentiel. Mais que voulez-vous, les frimeurs sont partout… Cela dit, vu que les applets Java ne sont pas forcément interprétées par le navigateur, elles sont d'un certain point de vue moins « nocives » que le JavaScript ! 5. Flash Le chouchou. Flash permet d'avoir des animations vectorielles légères et complexes, qui s'appuient sur un plug-in et non le navigateur (donc peu de risques de bugs). En plus les sources de ce plug-in vont bientôt être rendues publiques… bref, que du bon. Pourtant, certains sites accueillent le visiteur par un méprisant « Flash n'est pas installé chez vous. Désolé, vous ne pouvez pas entrer sur notre site ». Si une telle entrée en matière est compréhensible pour les sites qui reposent entièrement sur les spécificités de Flash, cela devient en revanche totalement idiot pour des sites qui auraient très bien pu être écrits en HTML 3.2. Un bon webmaster prévoit tous les cas : le visiteur a le plug-in Flash installé sur sa machine le visiteur a le plug-in Flash, mais il n'est pas reconnu : possibilité d'entrer manuellement sur la version Flash le visiteur n'a pas installé Flash : faire éventuellement une version du site en JavaScript le visiteur n'a ni Flash ni JavaScript (si, si, ça existe ! de nombreuses PME ont à peine le matériel nécessaire pour gérer les frames…) : faire une version du site allégée Il faudra toujours prévoir une version allégée. Rien de plus néfaste pour l'image d'un site que de se montrer trop présomptueux ou trop gourmant en techniques. On utilisera donc systématiquement les pendants des tags <FRAMESET>, <SCRIPT>, <EMBED> : <NOFRAMES>, <NOSCRIPT>, et <NOEMBED>. 6. Les techniques côté serveur Le JavaScript, Java, PHP, les Extensions FrontPage (ASP), quand elles sont maîtrisées, sont des techniques redoutables pour gérer des sites en dynamique côté serveur. (on laissera peut-être dé côté les ASP FrontPage, qui buggent souvent le code résultant…) Toujours se poser la question de ce qu'on peut faire côté serveur avant de se résoudre à s'appuyer sur des techniques client. Note : RAW HTWL n'est pas une technique client, sans être pour autant une technique serveur. L'action du logiciel sur le site prend place avant même la publication, ce qui permet d'utiliser les macros sans avoir à monter un serveur. 7. Les cookies En vertu de tout ce qui précède, inutile de dire ce que j'en pense… Restons poli. 8. Poursuivre la navigation dernière mise à jour : 24 février 2000 — retour au sommaire général considérations sur le HTML 3.2 référence du HTML 3.2 quelques pièges du HTML 3.2 les caractères spéciaux reconnus par RAW HTWL les macros prédéfinies de RAW HTWL