All rights reserved.
Cette liste des questions les plus fréquemment posées est tenue à jour par WDG et a été mise à jour pour la dernière fois le 15 Juillet 2000. (La présente traduction date de Janvier 2001). Elle peut être trouvée aux adresses suivantes :
La traduction en hollandais de ce document est disponible également :
La présente traduction française se trouve sur :
Si vous souhaitez contribuer à cette FAQ, merci d'envoyer un message à <darin@htmlhelp.com>. Toutes les personnes qui ont participé à cette FAQ sont listées à la fin.
N'hésitez pas à contacter le traducteur pour signaler une imprécision, une erreur de traduction, une faute de français que vous pourrez trouver dans ce document : <cedrik.rousseau@insa-rouen.fr>
1. Se lancer
La recommendation en cours est XHTML 1.0, qui est une reformulation de HTML 4.01 en tant que qu'application de XML 1.0. HTML 4.01 est une mise à jour avec des corrections mineures de HTML 4.0. HTML 4 étend HTML 3.2 en incluant le support pour les cadres, l'internationalisation, les feuilles de styles, les tableaux avancés et plus encore. Les nouvelles balises introduites par HTML ne sont pas encore supportées par tous les navigateurs, mais la plupart peuvent s'utiliser en toute sécurité avec les navigateurs ne les reconnaissant pas.
Recommendations sur HTML 4:
Recommendations sur HTML 3.2:
Informations sur certaines versions propriétaires de HTML:
Il existe de nombreux outils. A vous de trouver celui qui s'adapte le mieux à vos besoins, vos habitudes... Vous pourrez trouver des lists d'outil de création HTML sur:
Gardez à l'esprit que en général, un outil qui vous demande peu de connaissance HTML donnera un fichier médiocre en sortie. En d'autres termes, vous pouvez toujours faire mieux à la main, si vous prenez le temps d'apprendre un peu HTML.
A l'intérieur de l'exemple de HTML, remplacez d'abord le caractère "&" par "&" à chaque fois. Remplacez aussi le caractère "<" par "<", et le caractère ">" par ">" de la même façon.
Les prochaines Questions et Réponses abordent plus généralement la représentation de divers caractères dans des pages HTML.
La réponse à la question précédente traitait le cas particulier du signe supérieur ">", du signe inférieur et du et-commercial "&". En général, la façon la plus sure de faire du code HTML est d'utiliser le code US-ASCII 7 bits et d'exprimer la partie supérieure du code 8 bits en utilisant des "entités" HTML. La réponse est à consulter dans " Que dois-je utiliser, &nomdentité; ou &#nombre; ?".
Travailler avec des caractères 8 bits fonctionne également très bien dans la plupart des cas réels: Unix et MS-Windows (en utilisant la table de caractères Latin-1) et aussi Macintosh (avec quelques réserves).
Les caractères disponible sont ceux de la norme ISO-8859-1, listés sur <URL:http://www.htmlhelp.com/reference/charset/>. Sur le Web, ce sont les seuls caractères suportés de manière universelle. En particulier les caractères 128 à 159 utilisés dans MS-Windows ne font pas partie de la table de code ISO-8859-1 et ne seront pas affichés comme les utilisateurs de Windows pourraient s'y attendre. Ceci inclut les tirets longs, les chevrons, le symbole trademark, les points des listes à points, etc. Pour ces caractères, ni le vrai caractère ni l'entité &#nnn; ne sont corrects. (Voir le dernier paragraphe de cette réponse pour en savoir plus).
Sur les architectures dont les codes de caractères utilisés en interne ne sont pas ISO-8859-1, comme MS-DOS ou Macintosh, il peut y avoir des problèmes: vous pourrez avoir à utiliser des méthodes de transfert de texte qui convertissent entre le code propre à la machine et ISO-8859-1 (par exemple, Fetch pour Mac), ou convertir séparemment (par exemple, GNU recode). Utiliser un code ASCII 7 bits avec des entités évite ces problèmes et cette FAQ est trop petite pour couvrir les autres possibilités en détail. Les utilisateurs de Mac pourront se reporter aux notes de l'adresse internet précédente.
Si vous faites tourner un serveur web sur une machine dont le code de caractères interne n'est pas ISO-8859-1, tel qu'un Mac ou un gros serveur IBM, c'est le travail du serveur de convertir les documents texte en code ISO-8859-1 avant l'envoi sur le réseau.
Si vous souhaitez utiliser des caractères hors du répertoire ISO-8859-1, vous devez utiliser HTML 4 plutôt que HTML 3.2. Regardez la recommendation HTML 4.01 sur <URL:http://www.w3.org/TR/html4/> et le site de Babel sur <URL:http://babel.alis.com:8080/> pour plus de détails. Une autre source intéressante pour l'internationalisation se situe chez <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/charset/>.
Ca n'est jamais incorrect de mettre les valeurs attributs entre guillemets, et de nombreux gens recommendent de mettre des guillemets autour des valeurs attributs bien que les guillemets soient techniquement optionnels. XHTML 1.0 nécessite que toutes les valeurs attributs soient entre guillemets. Comme les précédentes spécifications HTML, la version 4 permet aux valeurs attributs de rester nues dans de nombreuses circonstances (par exemple, quand la valeur ne contient que des chiffres et des lettres). Allez voir <URL:http://www.w3.org/TR/html4/intro/sgmltut.html#attributes> pour les règles exactes.
Soyez prudent quand vos valeurs d'attribut contiennent des guillemets anglais; par exemple quand vous voulez un texte alternatif comme "Le "Roi du spectacle" prends un arc" pour une image. Les humains peuvent comprendre où la citation se situe, mais les ordinateurs ne peuvent pas. Vous devez coder la valeur attribut de façon spéciale pour que le premier guillemet intérieur ne termine pas la valeur trop tôt. Il y a deux approches:
Ces deux méthodes sont correctes en regard des spécifications, et sont supportées par les navigateurs actuels (moins bien par les premiers navigateurs). La méthode la plus prudente serait de réécrire le texte de façon à ce qu'il ne contienne plus de guillemets, ou de changer les guillemets du texte en apostrophe, ainsi: ALT="le 'Roi du spectacle' prends un arc".
Une déclaration de commentaire démarre avec "<!", suivi par aucun ou plusieurs commentaires suivi par ">". Un commentaire commence et finit par "--" et ne contient évidemment pas la chaine "--" à l'intérieur. Cela signifie que les expressions suivantes sont des commentaires syntaxiquement correctes:
Mais quelques navigateurs ne supportent pas complétement la syntaxe, ainsi nous recommendons que vous suiviez cette règle simple pour composer des commentaires valides et compatibles:
Un commentaire HTML commence avec "<!--", finit avec "-->" et ne contient pas "--" ou ">" dans le corps du commentaire.
Allez voir <URL:http://www.htmlhelp.com/reference/wilbur/misc/comment.html> pour une source d'information plus complète..
La structure d'une URL définit une hiérarchie similaire à celle des répertoires dans un système de fichier. Les différentes parties d'une URL sont séparées par des barres obliques "/". La dernière partie de l'adresse (i.e, après la dernière barre oblique) est semblable à un fichier. Les autres parties ressemblent aux sous-répertoires.
Une adresse relative omet une partie de l'information nécessaire à localiser le document référencé. La partie non mentionnée sera interprétée comme étant la même que pour le document de base qui contient l'adresse relative. Ceci réduit la longueur de l'adresse nécessaire pour référencer les documents liés, et permet aux arborescences de documents d'être accessibles par d'autres protocoles (par exemple, fichier, http ou ftp) ou d'être déplacés sans rien changer aux URL incluses dans les documents.
Avant que le navigateur ne puisse utiliser une adresse relative, il doit étudier l'adresse relative pour produire un chemin absolu. Si le chemin relatif commence avec une double barre (par exemple, //www.htmlhelp.com/faq/html/), alors il héritera seulement du type de protocole. Si l'adresse relative commence avec une barre unique, alors il héritera en plus de l'adresse du réseau.
Si l'URL relative ne commence pas par une barre (par exemple, menu.html, ./menu.hml ou ../html/), alors il s'agit d'un chemin relatif calculé ainsi:
Quelques exemples aident à rendre les choses plus claires. Si le document de base est <URL:http://www.htmlhelp.com/faq/html/basics.html>, alors
all.html et ./all.html
Il est à noter que c'est le navigateur qui calcule les adresses relatives, pas le serveur. Le serveur voit seulement l'adresse absolue résultante. Enfin, les adresses relatives réfèrent à la hièrarchie de l'URL et non celle du système de fichiers du serveur, veillez donc à ne pas les confondre. (par exemple, /doc.html ne renvoie certainement pas au même document dans les deux hièrarchies, un fichier à la racine du site ne se situant sans doute pas à la racine du disque dur.)
Pour un débat complet sur les formes correctes des URLs, voir <URL:http://www.w3.org/Addressing/>.
La structure des URL définie une hiérarchie similaire à celle d'un système de fichiers et ses sous-répertoires. Les différentes partie d'une URL sont séparées par des barres obliques "/". La dernière partie (celle après la dernière barre oblique) est donc semblable à un fichier et les autres parties ressemblent à des sous-répertoires.
En calculant les adresses relatives (voir la réponse à la question précédente), le navigateur commence par enlever tout ce qu'il y a après la dernière barre dans l'adresse du document courant. Si l'adresse du document en cours se termine par une barre oblique alors il n'y a rien après. En enlevant cette barre finale, alors la dernière partie de l'adresse n'est pas nulle. Ainsi enlever la barre oblique change l'URL; l'URL modifiée fait référence à un document différent et le calcul des adresses relatives sera affecté.
Par exemple, la dernière partie de l'adresse http://www.htmlhelp.com/faq/html/ est vide; il n'y a rien après la barre finale. Dans ce document, l'adresse relative all.html fait référence à http://www.htmlhelp.com/faq/html/all.html (un document existant). Si la barre oblique finale est omise, alors la dernière partie de l'adresse modifiée http://www.htmlhelp.com/faq/html est "html". Dans ce document non existant, l'adresse relative all.html renverrait http://www.htmlhelp.com/faq/all.html (un autre document qui n'existe pas)
Quand ils reçoivent une requête avec une barre oblique finale absente, les serveurs web ne peuvent ignorer la barre manquante et envoyer simplement le document malgré tout. S'ils faisaient ça, toutes les adresses relatives du document seraient défaillantes. Normalement, les serveurs sont configurés pour envoyer un message de redirection quand ils reçoivent une telle requête. En réponse au message de redirection, le navigateur fait une nouvelle demande, avec l'adresse correcte cette fois, et alors le serveur envoie le document demandé. (Le navigateur ne peut corriger l'adresse de lui même; seul le serveur peut savoir s'il manque une barre oblique finale).
Ce processus de correction d'erreur montre que les adresses sans barre oblique finale marchent quand même. Cependant, ce processus gâche du temps et des ressources réseau. Si vous mettez la barre finale quand c'est nécessaire, alors les navigateurs n'auront pas besoin d'envoyer une seconde requête au serveur.
Il y a une exception quand vous faites référence à une adresse avec un simple nom d'hôte. (par exemple, http://www.htmlhelp.com). Dans ce cas, le navigateur devinera que vous voulez l'index principal ("/") du serveur et vous n'avez pas à inclure la dernière barre oblique. Cependant, beaucoup considérent qu'il est de bon goût que de l'inclure quand même.
Pour un débat complet sur les formes correctes des URLs, voir <URL:http://www.w3.org/Addressing/>.
De divers logiciels sont disponibles pour trouver les erreurs dans vos document web automatiquement. Les valideurs HTML sont des programmes qui analysent les documents HTML en se basant sur une définition formelle de la syntaxe et qui renvoient la liste des erreurs. Valider est important pour se donner les meilleures chances d'être compatible avec les navigateurs inconnus (comme les navigateurs exotiques ou ceux qui n'ont pas encore été écrits).
Les vérificateurs HTML ("linters") sont également utiles. Ces programmes vérifient les document pour des problèmes de portabilité spécifiques comme ceux causés par un marqueur invalide ou les bugs des navigateurs usuels. Les vérificateurs peuvent parfois accepter des documents invalides et rejeter des valides.
Tous les valideurs sont fonctionnellement équivalents; même s'ils fournissent des comptes-rendus de formes différentes, ils trouveront les mêmes erreurs étant donnée une même entrée. En revanche, les différents vérificateurs sont programmés pour regarder différents problèmes, donc leurs comptes-rendus varient sensiblement de l'un à l'autre. Ils n'en sont pas inutiles pour autant mais ne doivent pas être confondus avec les vrais valideurs HTML.
En vérifiant les erreurs d'un site pour la première fois, il est souvent utile d'identifier les problèmes communs qui reviennent de façon répétée. Réglez ces problèmes partout où ils apparaissent (avec un processus automatisé, si possible), et repartez du début pour identifier et régler les problèmes restants.
Pour la vérification des erreurs dans le code HTML, il est également bien de tester si les liens hypertextes sont toujours valides. Il existe plusieurs testeurs de lien disponibles pour différentes plates-formes qui tenteront de suivre tous les liens d'un site et renverront la liste de ceux qui ne fonctionnent pas.
Vous pouvez trouver une liste de tous les valideurs, vérificateurs et testeurs de liens sur <URL:http://www.htmlhelp.com/links/validators.htm/>. L'utilisation d'un valideur basé sur SGML tel que le WDG HTML Validator <URL:http://www.htmlhelp.com/tools/validator/> ou le W3C HTML Validation Service <URL:http://validator.w3.org/> est spécialement recommandée.
D'après les standards HTML, chaque document HTML commence avec une déclaration DOCTYPE qui spécifie quelle version de HTML il utilise. La déclaration DOCTYPE est avant tout utile aux outils basés sur SGML tels que les valideurs HTML qui doivent connaitre la version de HTML utilisée afin d'analyser la syntaxe du document. En général, les navigateurs ignorent les déclarations DOCTYPE.
Allez voir sur <URL:http://www.htmlhelp.com/tools/validator/doctype.html> pour des informations sur la façon de choisir la bonne déclaration DOCTYPE.
N.B.: La section d'identifiant public de la déclaration DOCTYPE est sensible aux majuscules/minuscules. Quelques versions sont connues pour insérer "-//w3c//dtd html 4.0 transitional//en" en minuscule plutôt que le correct "-//W3C//DTD HTML 4.0 Transitional//EN".
Pour des rajouts ou des oublis dans cette FAQ, merci de contacter <darin@htmlhelp.com> (en anglais) ou <cedrik.rousseau@insa-rouen.fr> (en français)
Toutes les informations ici présentes ont été compilées à l'origine par les membres du Web Design Group, principalement Arnoud "Galactus" Engelfriet, John Pozadzides, et Darin McGrew. La traduction hollandaise de cette FAQ a été réalisée par Rijk van Geijtenbeek, tandis que la traduction française à été faite par Cédrik Rousseau dans le cadre de l'UV traduction de FAQ du département ASI de l'INSA Rouen.
Des compléments ont été apportés par Boris Ammerlaan, Martin Atkins, Lori Atwater, Alex Bell, Stan Brown, Roger Carbol, Alex Chapman, Jan Roland Eriksson, Jon Erlandson, Mark Evans, Peter Evans, Alan Flavell, Rijk van Geijtenbeek, Lucie Gelinas, Bjoern Hoehrmann, Tina Marie Holmboe, Cliff Howard, Thomas Jespersen, Peter Jones, Nick Kew, Jukka Korpela, Simon Lee, Nick Lilavois, Neal McBurnett, Glen McDonald, Dan McGarry, Ken O'Brien, Timothy Prodin, Steve Pugh, Liam Quinn, Colin Reynolds, Kai Schätzl, Doug Sheppard, Sue Sims, Toby Speight, Warren Steel, Ian Storms, Peter Thomson, Daniel Tobias, and Diane Wilson.
Merci tout le monde
Home, Reference, FAQs, Tools, Design, Feature Article, BBS, Links
Copyright © 1996-1999.
All rights reserved.