Préface du traducteur : cette série d'articles originaux contient un total de 8 articles. Elle commence par la vulgarisation des normes Web et décrit comment utiliser Dreamweaver 8 pour créer un Web conforme aux normes. Puisque l'article de l'auteur original est une revue de « Build Your ». Propre site Web conforme aux normes utilisant Dreamweaver 8" (Cet article est un extrait payant), j'ai donc supprimé le contenu de manière appropriée. L'ordre est conforme à l'article original, mais la longueur sera ajustée. Je vous en informe par la présente. Le niveau de traduction est limité, veuillez comprendre.
Si vous lisez cet article, vous êtes probablement déjà intéressé par les standards du Web et êtes très curieux de connaître l'application des standards dans les sites construits avec DW (abréviation de Dreamweaver).
Peut-être avez-vous déjà une certaine compréhension de WS (abréviation de Web Standards), mais vous ne savez pas comment utiliser DW pour écrire du code compatible. Ou vous êtes un utilisateur DW et vous souhaitez vous conformer à WS, utiliser CSS plus largement et créer des documents plus conviviaux. Quel que soit votre type, cet article vous donnera la réponse que vous souhaitez : vous expliquera comment utiliser DW pour gérer WS.
Définition des standards du Web
En ce qui concerne les WS qui nous intéressent tout au long de cet article, prenons d'abord un moment pour clarifier de quoi nous parlons :
les WS sont des spécifications qui guident les langages de développement Web et sont formulées par le W3C. Ces spécifications incluent plusieurs langages, tels que HTML, XHTML et CSS, ainsi que d'autres langages connexes, tels que MathML, qui sont utilisés pour représenter des équations en mathématiques. Lorsque vous avez des besoins particuliers, vous pourrez peut-être les utiliser. . Le W3C publie également les directives pour l'accessibilité des contenus Web (WCAG) - qui favorisent l'accessibilité des pages Web (via WAI).
Astuce : obtenez ces directives directement
.Vous pouvez lire ces directives sur le site Web du W3C, même si
c'est
parfois unpeu
difficile. àlire
:
HTML
4.01
Il n'est pas nécessaire de lire trop de documentation du W3C.Qui a besoin de WS ?
Vous n'avez peut-être qu'une vague idée que WS est une bonne chose, mais de nombreux sites - y compris de nombreux sites bien connus - ne se conforment pas à WS et semblent être bien gérés. Alors, pourquoi devrions-nous nous efforcer de nous conformer à WS ? Y a-t-il de réels avantages à le faire ? Qui a besoin de WS ? Qui doit prêter attention aux spécifications et aux recommandations du W3C ?
Le premier groupe de personnes qui doit prêter attention à WS est nous,
développeurs et concepteurs
Web :Développeurs et concepteurs de construction de sites Web. Vaut-il la peine de passer du temps à apprendre à développer avec WS ?Un balisage propre accélère la correction des bogues.
Si vous validez vos pages auprès du W3C, vous saurez au moins qu'un balisage irrégulier n'est pas la cause des erreurs que vous avez rencontrées. Parfois, le processus de validation d'une page et de correction des erreurs trouvées peut résoudre des problèmes d'affichage causés par des éléments interminables ou des balises mal orthographiées.
Même si la vérification de votre document ne résout pas les problèmes, vous saurez au moins que les problèmes existent dans le document canonique. Maintenant que vous savez que ce problème n'est pas un bug, vous pouvez commencer à vous concentrer sur d'autres problèmes, tels que les différences de gestion CSS dans les différents navigateurs.
Se conformer aux exigences d'accessibilité est facile.
Si vous écrivez un balisage XHTML canonique, vous pouvez alors vous assurer que le document est sémantiquement correct, et vous pouvez séparer le contenu du document de la présentation, vous pouvez faire beaucoup de travail pour résoudre de nombreux problèmes. problèmes d’accessibilité répertoriés dans les WCAG1.0. Il est également important de reconnaître que l’accessibilité ne concerne pas uniquement les personnes handicapées. Un site convivial peut être consulté par de nombreux appareils différents, tels que les téléphones mobiles et les PDA, qui ne disposent pas de la puissance de traitement nécessaire pour gérer un balisage dispersé et non standard.
Compatibilité ascendante
Si vous considérez uniquement les performances de votre page nouvellement développée dans les navigateurs actuels, comment pouvez-vous garantir ses performances dans les nouveaux navigateurs à l'avenir ? Le nouveau navigateur peut modifier votre page. L'affichage est épouvantable et vous vous retrouvez en difficulté ? pour trouver et résoudre des problèmes ennuyeux.
Se conformer à WS n'éradiquera pas complètement ce problème ; cependant, la compatibilité des normes réduit considérablement le risque d'échec de votre conception, et les éditeurs de logiciels de navigation actuels commencent également à prendre en charge les normes. Ils peuvent accidentellement mal interpréter une partie de la spécification, mais ils ne peuvent pas la désapprouver complètement. Si le pire se produit et qu'un nouveau navigateur produit des effets étranges sur votre site standardisé, il est beaucoup plus facile de le réparer qu'un site incompatible. Si vous rencontrez un problème, cela affectera également d’autres sites conformes aux normes. La sagesse collective de la communauté Web le soulignera et rédigera des articles pour y répondre. Par conséquent, tout le monde a discuté collectivement du fait qu’il est plus facile de corriger ce BUG dans un document compatible que dans un document incompatible.
Refactorisation plus facile
Avez-vous déjà dû supprimer le texte d'un site, le refactoriser et tout recommencer ? Avez-vous déjà vu ces étiquettes encombrées d'étiquettes de polices et de minuscules cellules de tableau (qui nous obligent à repartir de zéro) ? Tout ce que je sais, c'est que j'ai, et c'est un long processus, beaucoup de temps et d'argent ? la refactorisation de ce site.
Séparer le contenu et la présentation d'un document vous offre la beauté du respect des normes : cela signifie que la prochaine fois que quelqu'un voudra refactoriser le site, il n'aura pas à copier le document Web. Tout le texte du site sera balisé avec du (X)HTML sémantique et toutes les informations de présentation - ce que le webmaster souhaite modifier - seront stockées dans un fichier CSS facilement remplaçable.
Certains clients n'attendront pas qu'il soit refactorisé avant de commencer à vous demander d'apporter des modifications. Ils attendront d'avoir visité le Mammoth Fossil Pit et vous demanderont ensuite de dire : « Déplacez simplement la colonne de gauche vers la droite. ." Pour les sites compatibles standardisés, toutes les pages sont contrôlées par CSS. Vous pouvez facilement déplacer les balises sur la page sans avoir à penser à des astuces dans de nombreuses pages avec des tableaux complexes comme structures. Cela facilite la modification de la mise en page.
Séparer la structure de la présentation peut également faciliter l'ajout de nouveaux éléments, comme une version d'un site avec de petites images à contraste élevé, qui peut être plus attrayante pour certains utilisateurs. Pourquoi créer des versions distinctes de pages contenant uniquement du texte alors que vous pouvez facilement modifier les feuilles de style ?
Les éditeurs de logiciels denavigation
commencent à s'intéresser à WS. Dans le passé, les éditeurs de logiciels de navigation ajoutaient leurs propres balises et attributs propriétaires au langage de base. Mais maintenant, comme jamais auparavant, ils commencent tous à se conformer aux normes, et certains des derniers navigateurs s'efforcent déjà de les afficher selon (X)HTML et CSS tels que définis dans la spécification.
Dans un avenir proche, les navigateurs seront capables d'afficher la plupart des balises et du code non standard, car s'ils ne le font pas, des milliers de sites non standard ne s'afficheront pas correctement - et le public risque alors de lancer la faute sur le navigateur. pas les concepteurs de sites Web. Cependant, d’autres appareils (ceux qui n’ont pas la puissance de traitement des ordinateurs de bureau) s’appuieront davantage sur une compatibilité standardisée du code qu’ils rencontrent.
Fournisseurs de logiciels d'outils de création
Les fournisseurs de logiciels d'outils de création, tels que Macromedia, qui fabrique Dreamweaver, commencent également à se conformer à WS, tout comme les concepteurs Web, par exemple, car de plus en plus de leurs clients exigent que ces outils de création génèrent un balisage canonique. À l'origine, ces environnements de développement visuel n'avaient pas une bonne réputation car ils produisaient un balisage confus et non standard. Cependant, les derniers environnements de développement visuel majeurs ont invoqué des éléments standardisés de compatibilité et d'accessibilité, qui sont également devenus un argument de vente principal. Les éditeurs de logiciels doivent écouter et répondre aux besoins du marché.
Utilisateurs Web
Les utilisateurs des sites que nous concevons bénéficient également de notre adoption de WS, même s'ils ne s'en rendent pas compte. Peut-être utilisent-ils inconsciemment des sites développés spécifiquement pour les navigateurs populaires d'aujourd'hui ! Si ces utilisateurs passent à un autre navigateur, ils risquent de constater que l’expérience en ligne n’est plus agréable car ces balises propriétaires ne seront pas acceptées par le nouveau navigateur. Un site standardisé et compatible fonctionne bien dans différents navigateurs, qu'il s'agisse de navigateurs existants ou futurs.
De plus, un site Web qui suit les recommandations en matière d’accessibilité sera plus accessible aux utilisateurs qui trouvent la navigation sur le Web insatisfaisante. Le Web devrait offrir des conditions d'achat, de lecture et de recherche plus pratiques aux personnes ayant une déficience visuelle ou d'autres handicaps. Il ne faut pas les empêcher de naviguer sur un site car celui-ci utilise des balises propriétaires ou d'autres technologies exclusives (faisant référence au navigateur).
Comment pouvons-nous garantir l'utilisation correcte de WS lors de
l'utilisation de WS
? Que pouvons-nous faire pour nous conformer à la norme ?Tout d'abord, nous devons nous conformer à la spécification. Cela signifie que nous devons utiliser uniquement les éléments et attributs définis dans la spécification et éviter d'utiliser certains attributs spécifiques au navigateur, tels que la balise marquee d'IE et la balise clignotante de Netscape. N'utilisez pas non plus d'éléments qui apparaissaient dans des spécifications antérieures (telles que HTML 3.2) ou qui ont été supprimés des spécifications ultérieures.
Créer un document XHTML canonique
Dans cet article, nous utiliserons XHTML, nous suivrons donc les recommandations XHTML 1.0 du W3C [selon le W3C, Recommandation signifie spécification]. XHTML est essentiellement la dernière version de HTML et est conçu pour remplacer HTML, le langage de balisage Web. Bien qu'il s'agisse d'une variante HTML de XML, XHTML est presque identique à HTML, avec des différences subtiles dont nous parlerons plus tard dans XHTML et Sémantique.
Vous pouvez générer un document XHTML via la boîte de dialogue Nouveau document de Dreamweaver (Fichier>Nouveau...). Assurez-vous que Page de base est sélectionné dans la liste Catégorie, puis sélectionnez HTML dans la liste Page de base, comme illustré dans la Figure 2.1, « Création d'un nouveau document XHTML dans Dreamweaver ». Vous pouvez ensuite sélectionner n'importe quel type de document dans la liste déroulante.
Figure 2.1 : Création d'un nouveau document XHTML dans Dreamweaver
Figure 2.2 : Affichage du nouveau document XHTML en mode code
Cliquez sur "Créer" pour générer un nouveau document. Cliquez sur le bouton de code en haut de la fenêtre du document et accédez à la « vue code ». Vous pouvez voir clairement quel code est inclus dans un simple document XHTML. Comme le montre la figure 2.2, la première ligne du document « Afficher le nouveau document XHTML en mode code »
affichera le contenu suivant
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http: / /www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">C'est
ce qu'on appelle une déclaration de type de document, ou DOCTYPE. Comme son nom l'indique, DOCTYPE déclare quel est votre document - à quelle spécification (X)HTML vous vous conformez. Dans cet exemple, nous suivons XHTML 1.0 Transitional, qui est le paramètre par défaut pour DW 8. La section Transitionnelle nous donne des informations supplémentaires sur la version XHTML. XHTML1.0 a trois « saveurs » : Strict, Transitional et Frameset. DW utilise le type Transitional par défaut, et si vous souhaitez insérer un cadre dans le document, il s'agit de Frameset.
XHTML Strict est le format XHTML le plus strict, comme vous pouvez probablement le deviner. Un type de document Strict ressemble à ceci :
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">Si
vous utilisez un DOCTYPE Strict, vous ne pouvez pas l'utiliser dans le document. N'importe quel élément (tag) ou un attribut qui déclare la dépréciation ne peut pas être utilisé dans les frames. Les éléments déclarés obsolètes seront supprimés dans une future version de XHTML. Beaucoup de ces éléments sont utilisés pour contrôler l’apparence de la page, qui peut être entièrement remplacée par CSS. La plus grande différence entre Strict et Transitional est que lorsque vous utilisez Strict DOCTYPE, les attributs et éléments que vous pensiez pouvoir être utilisés pour les performances sont considérablement restreints.
Remarque : L'utilisation de DOCTYPE strict dans DW
DW n'est pas très stricte en termes de conformité à la norme. Si vous utilisez Strict DOCTYPE, portez une attention particulière à la validation de votre document et à la correction des attributs irréguliers. Fondamentalement, il est facile de les remplacer par du CSS.
Frameset DOCTYPE prend en charge l'utilisation de cadres. Si vous insérez un cadre dans le document, DW utilisera automatiquement ce type. La page cadre doit être liée à au moins deux autres pages, et il n'y a aucune limite quant au type de document des pages associées. Le code de Frameset DOCTYPE est le suivant :
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
HTML 4.01 fournit également ces trois "saveurs" de types de documents - Transitionnel, Strict et Frameset - ils fonctionnent exactement de la même manière que les DOCTYPE XHTML mentionnés ci-dessus. Si vous utilisez l'un ou l'autre type, vous devez l'indiquer dans le document HTML (et non XHTML). Nous discuterons en profondeur des différences entre HTML et XHTML plus loin dans la section sur la création d'un site Web.
Original : Dreamweaver 8 fait des standards par Rachel Andrew
Compilé : x5 !