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 contribuez à 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>
HTML en soi n'offre pas de possibilité d'incorporer sans couture le contenu d'un document dans un autre.
La vraie inclusion dynamique d'un document dans un autre (même dans un différent code de caractères) est possible avec l'élément OBJECT, mais comme peu de navigateurs sont capables de comprendre ceci, il n'est pas envisageable de compter là dessus, du moins pour un contenu essentiel. La même chose est valable pour IFRAME.
Il y a deux façons répandues d'inclure un fichier dans un document html sans utiliser les cadres (frames) : le prétraitement et les inclusions du coté serveur.
Parmi les techniques de prétraitement, on trouve le préprocesseur C, d'autres méthodes génériques de manipulation de texte et plusieurs processeurs spécifiques au HTML. Vous pouvez consulter une belle liste de préprocesseurs HTML sur <http://www.idocs.com/wmr/software/html+preprocessors/>.
Attention de ne pas produire du code source non portable. Par ailleurs, le document HTML ne peut être validé qu'après le prétraitement. Ainsi le cycle typique 'Edition, Vérification, Envoi' devient 'Edition, Prétraitement, Vérification, Envoi'. (Ici, 'Vérification' comprends toutes les étapes que vous pouvez franchir pour prévisualiser vos pages; et 'Envoi' fait référence au moment où vous publier réellement vos pages sur le Web).
Une technique de prétraitement bien plus puissante et polyvalente est d'utiliser un processeur SGML. (tel que SP package) pour générer votre code HTML. Le code ainsi généré peut être vérifié automatiquement.
Exemples d'inclusions coté serveur : Server Side Includes (SSI, supporté par Apache, NCSA, et d'autres serveurs Web) et la technologie Active Server Pages de Microsoft (ASP, supportée par MS IIS). Le traitement se déroule au moment même où les documents sont consultés. Un exemple type d'inclusion ressemble à :
<!--#include virtual="/chemin/jusqua/monfichier.htm" -->mais le mieux est de consulter la documentation de votre propre serveur http, car de nombreux détails peuvent varier entre les différentes implémentations. Toute l'instruction est remplacée par le contenu du fichier spécifié.
Utiliser les inclusions coté serveur (un outil potentiellement puissant) simplement pour insérer des documents statiques tels que des en-têtes ou des pieds de pages a un impact sur la vitesse d'accès et sur la charge de travail du serveur et devrait être évité sur les serveurs encombrés. Cependant si vous tenez à procéder ainsi, le mieux est de pouvoir conserver les pages résultantes en mémoire cache (par exemple, avec "XBitHack full" pour Apache; ou en réglant correctement les propriétés de réponse avec ASP). Cette FAQ ne peut se permettre de donner plus de détails mais ce lien devrait vous être utile : http://www.mnot.net/cache_docs/
La validation du code html des inclusions n'est possible qu'après le traitement par le serveur (par exemple, en utilisant un validateur en ligne qui rappatrie le document depuis le serveur).
Enfin, prenez garde que si le document à inclure contient un texte brut arbitraire, alors il pourrait être judicieux de s'assurer de la conversion des caractères spéciaux (tels que '&' ou '<') en entités (telles que '&' ou '<').
En HTML, les caractères peuvent être représentés de trois façons :
En théorie, ces représentations sont aussi valables les unes que les autres. En pratique, la commodité de création et la compatiblité limitée des navigateurs complique le problème.
Rappelons que HTTP est un protocole garanti '8 bit clean', ce qui signifie que vous pouvez envoyer en toute sécurité des caractères codés sur 8 bits ou même plusieurs octets en supposant que le navigateur reconnaisse le code.
Pour l'instant, il n'y apparamment aucune bonne raison de choisir &entité; plutôt que &#nombre;, donc utilisez le plus pratique.
Si vous pouvez manipuler des caractères 8-bits en toute compatiblité, cela marche aussi. Et c'est probablement beaucoup plus aisé pour écrire dans des langues fortement accentuées telles que le français. Prenez des précautions si vous créez vos documents sur des plates-formes non ISO-8859 (comme les Mac ou les Psion); il vous faudra vérifier que votre technique de transfert delivre des documents correctement codés au serveur. Utiliser les représentations &bidule permet évidemment d'éviter de tels problèmes.
Avec des tables de codes comme le grec ISO-8859-7, le cyrillic russe koi8-r et le chinois, japonais et coréens (CJK), l'utilisation de caractères codés est la seule technique largement acceptée. C'est à dire que vous ne pouvez pas vous contenter de taper simplement le caractère.
Bien que non couvert par HTML 3.2, les navigateurs supportent presque tous cette méthode. C'est une option valide dans les spécifications de HTML 4; vous pouvez utiliser le Valideur HTML en ligne de WDG disponible sur <URL:http://www.htmlhelp.com/tools/validator/> qui supporte HTML 4 et qui comprend les différents types d'encodage de caractères.
Le support des caractères codés par les navigateurs peut dépendre de la configuration et des polices disponibles. Dans certains cas, des programmes supplémentaires appelé 'helpers' ou 'add-ins' peuvent fournir des polices virtuelles aux navigateurs.
Les programmes de type 'add-in' ont été utilisés dans le passé pour supporter les références numériques aux tables de codes 15 ou 16 bits telles que Chinese Big5 ou Chinese GB2312.
En théorie, on devrait pouvoir inclure non seulement les caractères codés mais aussi les références numériques aux caractères Unicode, mais la compatibilité des navigateurs est généralement moyenne. Les références numériques à la table de caractères spécifiée ('charset-specified') peuvent parfois marcher, mais ce comportement est mauvais et ne devrais pas être utilisé. Les entités ne sont pas non plus exemptes de soucis mis à part les caractères HTML significatif tels que <, & ...
Les versions récentes des deux navigateurs les plus répandus supportent la plupart de ces caractéristiques. La proportion de navigateurs marginaux s'atténuant rapidement, il devrait maintenant être enviageable d'utiliser les nouvelles fonctionnalités de HTML 4. Vous pourrez trouver à ces adresses, une bonne documentation sur ces options :
Les marqueurs ne sont pas sensibles à la casse, donc c'est égal. C'est principalement une question de style. La plupart des gens préfèrent les lettres capitales pour faire ressortir les balises.
Le nom des attributs peut aussi être minuscule ou majuscule, au choix.
Cependant, certaines valeurs d'attribut sont sensibles à la casse. Par
exemple, <OL TYPE=A> et <OL type=A> ont
le même effet, mais <OL TYPE=a> est différent
des deux. (Accordons-nous sur la terminologie : Dans cet exemple, OL
est l'élément, TYPE est le nom de l'attribut, et
A et a sont les valeurs de l'attribut. La balise (ou
le marqueur) est <OL TYPE=A>.)
Les entités comme sont parfois désignées
à tort comme des marqueurs. Elles sont toutes sensibles à la casse.
Par exemple, É et é sont deux
différentes entités valides et &NBSP; est invalide.
Il est à noter que XHTML 1.0 (une reformulation de HTML 4.01 en tant qu'application XML 1.0) requiert que les éléments et les noms d'attributs soient en minuscule.
Enfin, le dernier aspect concerne la compression. En effet, les utilisateurs de modem par exemple, ont grand intérêt à ce que les pages qu'ils visualisent soient bien compressables car la plupart des normes de transmission par modem essaie de compresser les données avant de les transmettre. Vous vous demandez certainement quel est le rapport avec la casse des marqueurs.... Et bien, un document se compressera d'autant mieux que les caractères qu'il contient sont similaires. Donc comme il y a généralement une majorité de minuscules dans un document, si les marqueurs sont aussi en minuscule, ça fait encore plus de caractères semblables, et c'est plus compressible. Notez que l'impact de cette remarque est très limitée, le fait d'utiliser des marqueurs en minuscule ne fait gagner que quelques pourcents de compression.
HTML ne dépend pas de la taille de l'affichage. Normalement le texte revient à la ligne quand il rencontre la fin de l'aire d'affichage. (Il faut noter que la fenêtre dans laquelle s'affiche le navigateur est souvent plus petite que l'écran.)
Les lignes préformatées (texte à l'intérieur des
balises <PRE>) ne devraient jamais dépasser 70 caractères
sauf si la nature du contenu ne permet pas de faire autrement. Des lignes plus
longues obligeront à se déplacer horizontalement. Les lecteurs
détestent toucher à la barre de déplacement horizontale,
sauf quand ils peuvent comprendre que la nature du contenu l'imposait.
Les images ne peuvent revenir à la ligne, donc vous devez faire plus attention. Il semble que 400 ou 500 pixels est une largeur maximale raisonnable. En effet, au dessus de 600 pixels une partie non négligeable d'utilisateurs devra faire défiler la page horizontalement. Gardez aussi à l'esprit que tout le monde n'utilise pas son navigateur en plein écran!
On pourrait ajouter que les utilisateurs de WebTV, (même s'il s'agit d'une quasi secte:), ne peuvent afficher des images plus larges que 544 pixels sans les comprimer. D'autres appareils peuvent se révéler encore plus limitatifs.
L'utilisation de tableaux comme mise en page, spécialement quand la largeur des cellules est fixe, est la cause la plus fréquente qui empêche les pages Web de s'adapter aux dimensions de l'affichage. Ceci est expliqué en détails sur <URL:http://www.dantobias.com/webtips/tables.html>.
Il y a plusieurs possiblités.
D'abord, vous pouvez avoir quelques lignes de codes incorrectes. Les navigateurs varient dans leur capacité à deviner ce que vous avez voulu dire. Par exemple, Netscape est bien plus tatillon pour les tableaux qu'Internet Explorer; ainsi une page avec quelques cellules de tableau incorrectes peut sembler bien formée dans IE mais ne pas s'afficher du tout dans Netscape. La réponse au problème se trouve dans "Comment vérifier les erreur?". (En fait, même les tableau imbriquées correctement décrits peuvent ne pas s'afficher correctement dans Netscape. Allez voir la réponse à "Peut-on imbriquer des tableaux à l'intérieur d'autres tableaux?" pour voir ce que vous pouvez faire à ce sujet).
Ensuite, il se peut que vous ayez une page HTML valide que différents navigateurs interprêtent différemment. Par exemple, dans les spécifications, il n'est pas dit clairement ce que doit donner une suite de caractères . Certains navigateurs les associeront pour rendre un espace simple, tandis que d'autres donneront une suite d'espace.
Enfin, votre serveur peut envoyer des types MIME incorrects pour certains de vos fichiers. Internet Explorer ignore les types MIME fournis par le serveur, donc ça marche parfois quand le serveur est mal configuré. Les autres navigateurs analysent correctement le type MIME fourni par le serveur en révélant ainsi une mauvaise configuration du serveur.
Voir aussi les réponse à "Pourquoi mes hyperliens fonctionnent mal ou ne se chargent pas?" and "Pourquoi mes images ne s'affichent pas ou ne se chargent pas?"
Si Microsoft Internet Explorer affiche votre document normalement, mais que les autres navigateurs affichent votre code source HTML brut, alors il est très probable que votre serveur web envoie le document avec "text/plain" comme type MIME. Votre serveur Web a besoin d'être configuré pour envoyer ce type de fichier avec le type MIME "text/html". Voir la réponse de Pourquoi mon lien vers ce fichier affiche un gros tas de caractères à la place? pour plus de détails.
Ceci est une "fonctionnalité" de l'utilisation des cadres. Le navigateur affiche l'adresse du plan de découpage, plutôt que des documents dans les cadres. (Voir la réponse à la question "Comment spécifier une combinaison précise de cadre plutôt que les documents par défaut?")
Cependant, ce comportement peut être contourner facilement par l'utilisateur. De nombreux navigateurs permettent à l'utilisateur d'ouvrir un lien dans une nouvelle fenêtre, d'ajouter dans les favoris (bookmarks) un lien ou un document dans un cadre... Ainsi, il n'y pas de méthode fiable pour empêcher un utilisateur de connaitre l'adresse d'un document précis.
De plus, empêcher les utilisateurs d'ajouter dans les favoris un document précis ne peut qu'éveiller leur hostilité.
En fait, la seule façon qui existe de masquer l'adresse d'un document est d'utiliser un script CGI qui envoie le document quand il le veut bien. Ainsi, le document n'a pas d'adresse, puisque c'est un CGI qui l'envoie.
La méthode courante est d'utiliser un tableau à deux colonnes avec vos liens dans la colonne de gauche, et le contenu de votre page dans la colonne de droite. Ceci est souvent combiné avec une image de fond qui crée une bande colorée sur la gauche, derrière les liens. L'image de fond peut se répeter pour faire une mosaïque verticalement, mais pour éviter qu'elle ne se répètent horizontalement, l'image doit être extrèmement large (par exemple, 1600 pixels).
Une variation de cette technique (qui minimise la plupart des problèmes
dans l'utilisation des tableaux pour mettre
en forme) utilise un tableau monocellulaire avec un alignement à
gauche : ALIGN="left. Seuls les liens entre dans le tableau qui
flotte sur la gauche. Le contenu du document retourne à la ligne pour
remplir l'espace qui reste à droite et en-dessous du tableau.
Avec CSS, on peut éviter entièrement l'utilisation des tableaux comme mise en page. Les liens de navigation et le contenu principal de la plage sont placés à l'intérieur de balises DIV différentes, et CSS intervient pour positionner ces élèments DIV l'un par rapport à l'autre. La feuille de style peut utiliser une image de fond plus petite qui se répète verticalement et qui est alignée sur la gauche. Par exemple:
body { color: black; background: white url(foo.gif) repeat-y left }
Plus d'information sur les feuilles de styles en cascade (Cascading Style Sheets) peut être trouvée sur http://www.htmlhelp.com/reference/css/
Pour terminer, une barre de navigation peut être implémentée avec des cadres. Cependant, les cadres amènent des problèmes qui sont à éviter, si possible.
Voir la réponse à la question "Comment inclure un fichier dans un autre?" pour des suggestions qui vous aideront à maintenir un contenu ordinaire (comme des liens de navigation) à travers tous les documents de votre site.
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.