Vérification de la validité des données. Code HTML valide Demandes valides

Jusqu'à présent, nous avons examiné des morceaux individuels de code HTML. Mais un document HTML (ou une page web, ce qui veut dire la même chose) nécessite une certaine structure pour être valide.

Pourquoi nous soucions-nous de la validation des documents HTML ?

• Exactitude : un document valide s'affiche correctement dans le navigateur.
• Débogage : un mauvais code HTML peut provoquer des erreurs difficiles à détecter.
• Maintenabilité : un document valide est plus facile à mettre à jour ultérieurement, même pour quelqu'un d'autre.

La première information que nous écrivons est taper Document HTML - type de document.

Considérez un doctype comme une version d'une voiture au fil des années : la Ford Fiesta que vous avez achetée en 1986 était une Fiesta 2. Si vous en achetez une aujourd'hui, c'est une Fiesta 7.

Auparavant, plusieurs versions de HTML coexistaient (XHTML et HTML 4.01 étaient des standards concurrents). Actuellement, HTML5 est la norme.

Pour indiquer au navigateur qu'un document HTML est HTML5, démarrez simplement votre document avec la ligne suivante :

C'est ça. Installez-le et oubliez-le.

Vous vous demandez peut-être pourquoi ce doctype HTML5 ne mentionne pas le chiffre 5. Le W3C pensait que les définitions précédentes du doctype étaient trop confuses et en a profité pour le simplifier en supprimant la mention de la version HTML.

Hormis la ligne doctype, l'intégralité de votre document HTML doit être située à l'intérieur de l'élément :

est techniquement l'ancêtre de tous les éléments HTML.

Comment les attributs sont transportés Informations Complémentaires pour un élément HTML, l'élément contient également des informations supplémentaires pour l'ensemble de la page Web.

Par exemple, le titre de la page (affiché dans l'onglet) est dans :

Mon fabuleux blog

Les éléments HTML suivants peuvent apparaître dans et uniquement dans :

Bien qu'il ne contienne que des métadonnées, qui ne sont pas du tout destinées à être affichées (sauf pour ), l'élément est l'endroit où nous écrivons tout notre contenu. Tout ce qu'il contient sera affiché dans la fenêtre du navigateur.

En combinant toutes ces exigences, nous pouvons rédiger un document HTML simple et valide :

Feuille de repères

Bonjour le monde!

Si vous affichez cet exemple dans un navigateur, vous verrez que :

• « MarkSheet » est écrit sur l'onglet du navigateur ;
• "Bonjour le monde!" est le seul texte affiché dans la fenêtre car c'est le seul contenu.

Le W3C propose un service de validation de balisage pour vérifier les erreurs et les avertissements de tout document HTML.

La vérification de la validité du code HTML du site est obligatoirement incluse dans mon . Mais il n'est pas nécessaire de surestimer l'importance des erreurs de validation dans la promotion SEO : elles sont très faibles. Pour n'importe quel sujet du TOP, il y aura des sites avec un grand nombre de telles erreurs et ils vivent très bien.

MAIS! L'absence d'erreurs techniques sur le site est un facteur de classement, et donc cette opportunité ne doit pas être négligée. Il vaut mieux le réparer, cela ne s'aggravera certainement pas. Les moteurs de recherche verront vos efforts et vous donneront un petit plus dans votre karma.

La validation du code site est vérifiée à l'aide de service en ligne Validateur HTML W3C. S'il y a des erreurs, le service vous donne une liste. Je vais maintenant analyser les types d'erreurs les plus courantes que j'ai rencontrées sur les sites.

• Erreur : ID en double min_value_62222

Et derrière cette erreur se cache un avertissement.

• Attention : la première occurrence de l'ID min_value_62222 était ici

Cela signifie que l'identifiant de style ID est dupliqué, qui, selon les règles de validité HTML, doit être unique. Au lieu d'ID, vous pouvez utiliser CLASS pour les objets en double.

Corriger ce problème est souhaitable, mais pas très critique. S'il y a beaucoup de telles erreurs, il est préférable de les corriger.

De même, il peut y avoir d'autres options :

• Erreur : ID en double placeWorkTimes
• Erreur : ID en double callbackCss-css
• Erreur : ID en double Capa_1

Ce qui suit est un avertissement très courant.

• Attention : l'attribut type n'est pas nécessaire pour les ressources JavaScript

Il s'agit d'une erreur très courante lors de la vérification de la validation d'un site Web. Selon les règles HTML5, l'attribut type n'est pas nécessaire pour la balise script ; il s'agit d'un élément obsolète.

Avertissement similaire pour les styles :

• Avertissement : l'attribut type de l'élément style n'est pas nécessaire et doit être omis.

La correction de ces avertissements est souhaitable, mais pas critique. À grandes quantités mieux vaut le réparer.

• Avertissement : pensez à éviter les valeurs de fenêtre qui empêchent les utilisateurs de redimensionner les documents

Cet avertissement indique que vous ne pouvez pas augmenter la taille de la page sur mobile ou tablette. Autrement dit, l'utilisateur souhaitait regarder de plus près les images ou le très petit texte et ne pouvait pas le faire.

Je considère cet avertissement comme très indésirable, il est gênant pour l'utilisateur et c'est un inconvénient comportemental. Éliminé en supprimant ces éléments - maximum-scale=1.0 et user-scalable=no.

• Erreur : l'attribut itemprop a été spécifié, mais l'élément n'est une propriété d'aucun élément

Il s'agit d'un micro-balisage, l'attribut itemprop doit être à l'intérieur de l'élément avec itemscope. Je pense que cette erreur n'est pas critique et peut être laissée telle quelle.

• Avertissement : les documents ne doivent pas utiliser about:legacy-compat, sauf s'ils sont générés par des systèmes existants qui ne peuvent pas générer le doctype standard.

La ligne about:legacy-compat n'est nécessaire que pour les générateurs HTML. Ici, il vous suffit de le faire, mais l'erreur n'est pas du tout critique.

• Erreur : source de balise de fin parasite

Si vous regardez dans le code du site lui-même et trouvez cet élément, vous pouvez voir qu'une seule balise est écrite par paire - ce n'est pas correct.

Par conséquent, vous devez supprimer la balise de fermeture du code. Semblable à cette erreur, des balises peuvent apparaître

• Erreur : un élément img doit avoir un attribut alt, sauf sous certaines conditions. Pour plus de détails, consultez les conseils sur la fourniture d'alternatives textuelles pour les images.

Toutes les images doivent avoir un attribut alt, je considère cette erreur comme critique et doit être corrigée.

• Erreur : l'élément ol n'est pas autorisé en tant qu'enfant de l'élément ul dans ce contexte. (Suppression d'autres erreurs de ce sous-arbre.)

L'imbrication des balises est ici incorrecte. DANS

il ne devrait y avoir que
• . Dans cet exemple, ces éléments ne sont pas du tout nécessaires.

  

  De même, il peut y avoir d'autres erreurs comme celle-ci :

  • L'élément h2 n'est pas autorisé en tant qu'enfant de l'élément ul dans ce contexte.
  • L'élément a n'est pas autorisé en tant qu'enfant de l'élément ul dans ce contexte.
  • L'élément noindex n'est pas autorisé en tant qu'enfant de l'élément li dans ce contexte.
  • L'élément div n'est pas autorisé en tant qu'enfant de l'élément ul dans ce contexte.

  Tout cela doit être corrigé.

  • Erreur : l'attribut http-equiv n'est pas autorisé sur l'élément méta à ce stade

  

  L'attribut http-equiv n'est pas destiné à l'élément méta, il doit être supprimé ou remplacé.

  Erreurs similaires :

  • Erreur : l'attribut n2-lightbox n'est pas autorisé sur l'élément a à ce stade.
  • Erreur : l'attribut asyncsrc n'est pas autorisé sur le script d'élément à ce stade.
  • Erreur : Le prix de l'attribut n'est pas autorisé sur l'option d'élément à ce stade.
  • Erreur : la chaîne de hachage d'attribut n'est pas autorisée sur l'étendue de l'élément à ce stade.

  Ici, vous devez également supprimer les attributs n2-lightbox, asyncsrc, price, hashstring ou les remplacer par d'autres options.

  • Erreur : balise de début incorrecte dans l'image de l'en-tête

  Ou comme ceci :

  • Erreur : balise de début incorrecte dans le div en-tête

  

  Les balises img et div ne doivent pas être dans . Cette erreur doit être corrigée.

  • Erreur : CSS : erreur d'analyse

  

  DANS dans ce cas Il ne doit pas y avoir de point-virgule après la parenthèse dans les styles.

  Eh bien, une telle erreur, une bagatelle, mais pas agréable) Voyez par vous-même si elle doit être supprimée ou non, cela n'aura aucun impact sur la promotion du site.

  • Attention : l'attribut charset sur l'élément de script est obsolète

  Il n'est plus nécessaire de préciser l'encodage dans les scripts ; c'est un élément obsolète. L'avertissement n'est pas critique, à votre discrétion.

  • Erreur : le script d'élément ne doit pas avoir de jeu de caractères d'attribut à moins que l'attribut src ne soit également spécifié.

  Dans cette erreur, vous devez supprimer l'attribut charset="uft-8" du script, car il affiche l'encodage en dehors du script. Je pense que cette erreur doit être corrigée.

  • Attention : Rubrique vide

  

  Voici un en-tête h1 vide. Vous devez supprimer les balises ou mettre un titre entre elles. L'erreur est critique.

  • Erreur : Balise de fin br

  

  La balise br est unique, mais est créée comme si elle fermait une paire. Nous devons supprimer / de la balise.

  • Erreur : La référence du caractère nommé n'a pas été terminée par un point-virgule. (Ou & aurait dû être échappé comme &.)

  

  Ce sont des caractères HTML spéciaux, vous devez les écrire correctement ou les copier. Il vaut mieux corriger cette erreur.

  • Erreur fatale : impossible de récupérer après la dernière erreur. Toute autre erreur sera ignorée

  C'est une erreur grave :

  

  Il ne devrait rien y avoir du tout après, puisqu'il s'agit de la dernière balise de fermeture de la page. Vous devez tout supprimer après ou le déplacer plus haut.

  • Erreur : CSS : à droite : seul 0 peut être une unité. Vous devez mettre une unité après votre numéro

  Vous devez écrire la valeur en px :

  

  Voici une erreur similaire :

  • Erreur : CSS : margin-top : seul 0 peut être une unité. Vous devez mettre une unité après votre numéro
  • Erreur : élément non fermé a

  Effectue plusieurs vérifications de votre code. Les principaux :

• Validation de la syntaxe - vérification des erreurs de syntaxe.
• est une syntaxe valide même s'il ne s'agit pas d'une balise HTML valide, la vérification de la syntaxe est donc peu utile pour écrire du bon HTML.
• Vérification de l'imbrication des balises - les balises doivent être fermées dans l'ordre inverse de leur ouverture. Par exemple, cette vérification détecte les erreurs avec .
• Validation DTD - vérification que votre code correspond à la définition de type de document spécifiée. Cela inclut la vérification des noms de balises, des attributs et de « l'intégration » des balises (balises d'un type à l'intérieur de balises d'un autre type)
Gardez à l’esprit qu’il s’agit de vérifications logiques et que la manière dont le validateur est implémenté n’a pas d’importance. Si au moins une des vérifications échoue, le code HTML est considéré comme invalide. Et c'est là que réside le problème. Arguments Le principal argument en faveur de la validation HTML est la compatibilité entre navigateurs. Chaque navigateur possède son propre analyseur, et lui fournir ce que tous les navigateurs comprennent est le seul moyen d'être sûr que votre code fonctionnera correctement dans tous les navigateurs. Étant donné que chaque navigateur possède son propre mécanisme de correction des erreurs HTML, vous ne pouvez pas vous fier à un code invalide.

Le principal argument contre la validation est qu’elle est trop stricte et ne correspond pas au fonctionnement réel des navigateurs. Oui, le HTML peut être invalide, mais tous les navigateurs peuvent traiter certains codes invalides de la même manière. Si je suis prêt à assumer la responsabilité du mauvais code que j'écris, je n'ai pas à me soucier de la vérification. La seule chose dont je dois m'inquiéter, c'est que cela fonctionne.

Ma position C'est l'une des rares fois où je parle publiquement de ma position sur quelque chose. J'ai toujours été parmi les opposants à la validation, car le validateur est trop strict pour être pratique dans des applications réelles. Certaines choses prises en charge par la plupart des navigateurs (dans, après) ne sont pas valides, mais sont parfois très nécessaires au bon fonctionnement.

En général, mon plus gros problème de validation est la vérification n°4 (pour les éléments superflus). Je suis partisan de l'utilisation d'attributs personnalisés dans les balises HTML pour stocker des métadonnées supplémentaires liées à un élément particulier. D'après ma compréhension, il s'agit par exemple d'ajouter l'attribut foo lorsque j'ai des données (barre) que je dois associer à un élément spécifique. Parfois, les gens surchargent les attributs existants à ces fins simplement pour passer la validation, même si l'attribut sera utilisé à d'autres fins. Cela n'a aucun sens pour moi.

Le secret des navigateurs est qu'ils ne vérifient jamais que le code HTML correspond à la DTD spécifiée. Le Doctype que vous avez spécifié dans le document fait passer l'analyseur du navigateur dans un certain mode, mais cela ne charge pas le doctype et ne vérifie pas la conformité du code avec celui-ci. Autrement dit, l'analyseur du navigateur traite le HTML avec certaines hypothèses d'invalidité, comme les balises à fermeture automatique et les éléments de blocage à l'intérieur des éléments en ligne (je suis sûr qu'il y en a d'autres).

Dans le cas d'attributs personnalisés, tous les navigateurs analysent et reconnaissent les attributs syntaxiquement corrects comme valides. Cela permet d'accéder à ces attributs via le DOM en utilisant Javascript. Alors pourquoi devrais-je m’inquiéter de la validité ? Je vais continuer à utiliser mes attributs et je suis très content que HTML5 les formalise.

Le meilleur exemple d’une technologie qui aboutit à un HTML invalide mais qui fait une énorme différence est ARIA. ARIA fonctionne en ajoutant de nouveaux attributs à HTML 4. Ces attributs fournissent une signification sémantique supplémentaire aux éléments HTML et le navigateur est capable de transmettre cette sémantique aux dispositifs d'assistance pour aider les personnes handicapées. Tous les principaux navigateurs prennent désormais en charge le balisage ARIA. Cependant, si vous utilisez ces attributs, vous aurez un HTML invalide.

En ce qui concerne les balises personnalisées, je pense qu'il n'y a rien de mal à ajouter de nouvelles balises syntaxiquement correctes à une page, mais je n'y vois pas beaucoup de valeur pratique.

Pour clarifier ma position : je crois que les contrôles n°1 et n°2 sont très importants et doivent toujours être effectués. Je considère également le contrôle n°3 comme important, mais pas aussi important que les deux premiers. La vérification n°4 est très discutable pour moi car elle affecte les attributs personnalisés. Je pense que, au maximum, les attributs personnalisés doivent être marqués comme des avertissements (et non des erreurs) dans les résultats de validation afin que je puisse vérifier si j'ai entré le nom de l'attribut de manière incorrecte. Il est possible de signaler les balises personnalisées comme erreurs bonne idée, mais présente également quelques problèmes, par exemple lors de l'intégration de contenu dans d'autres balises - SVG ou MathML.

Valider pour valider ? Je pense que la validation pour le plaisir est extrêmement stupide. Un HTML valide signifie uniquement que les 4 vérifications ont réussi sans erreurs. Il y a plusieurs choses importantes qu'un code HTML valide ne garantit pas :
• un code HTML valide ne garantit pas l'accessibilité ;
• Un HTML valide ne garantit pas une bonne UX (expérience utilisateur) ;
• Un code HTML valide ne garantit pas un site Web fonctionnel ;
• Un HTML valide ne garantit pas l'affichage correct du site.
Un HTML valide peut être quelque chose dont on peut être fier, mais cela n'est pas en soi un indicateur de compétence. Votre code valide ne fonctionne pas toujours mieux que mon code invalide. Validation HTML5 La validation HTML5 résout certains des problèmes liés à la validation HTML 4. Elle autorise explicitement les attributs personnalisés (ils doivent commencer par data-). Cela permettra à mon code de passer le contrôle de validation HTML5. Bien sûr, il y a certaines choses avec lesquelles je ne suis pas d'accord avec le validateur HTML5, mais je pense qu'il répond bien mieux aux besoins pratiques que le validateur HTML 4. Conclusion Je pense que certaines parties de la validation HTML sont extrêmement importantes et utiles. mais je ne veux pas être son otage parce que j'utilise mes attributs. Je suis fier d'utiliser ARIA dans mon travail et je m'en fiche si c'est considéré comme du code invalide. Encore une fois, sur les quatre contrôles du validateur, je n'ai de problèmes qu'avec un seul. Et un validateur HTML5 me sauvera de la plupart de ces problèmes.

Je sais que c'est un sujet controversé pour beaucoup, alors évitez toute déclaration purement émotionnelle dans les commentaires.

UPD : merci pour le karma, je l'ai déplacé vers la thématique. Je répéterai les mots de l'auteur : je comprends qu'il s'agit d'un sujet controversé, mais veuillez vous abstenir de commentaires purement émotionnels et de donner des arguments.

Dernièrement, j'ai reçu plusieurs questions d'utilisateurs concernant la validité de mes thèmes et la validation en général. Dans cet article, je veux y répondre.

Qu'est-ce que la validité ?


On pense que la validité du code est une caractéristique unique et universelle de tout code.
En fait, la validité est la conformité du code HTML du document avec un certain ensemble de règles spécifiées dans le doctype ou implicites dans HTML5.
Autrement dit, la validité est un concept relatif, puisque les règles sont différentes, tout comme leurs exigences.
Pour que ce soit plus clair, je vais donner un exemple que j'ai trouvé sur le site css-live.ru :

Vers le chantier bâtiments résidentiels et les centrales nucléaires, différents SNiP sont utilisés ( codes du bâtiment et règles), donc un document valable selon un ensemble de règles peut ne pas l'être selon un autre (une centrale nucléaire construite selon les normes d'un immeuble résidentiel serait bien !).

Le doctype indique généralement le document sur lequel la validation HTML est prévue, mais peut être choisi pour des raisons pragmatiques afin de sélectionner le mode de navigation optimal.
XHTML5 n'a peut-être pas de doctype du tout, mais reste valide.

La validation : qu'est-ce que c'est ?

En termes simples, la validation est le processus de vérification du code et de le rendre conforme au doctype choisi (DTD).

Comment est vérifiée la validité ?

La validité du code HTML est vérifiée par un outil appelé validateur.
Le validateur w3c le plus connu est https://www.w3.org.
Le validateur w3c effectue plusieurs vérifications de code.
Les principaux :

• Vérification des erreurs de syntaxe :
  Exemple tiré de habrahabr.ru/post/101985 :
  est une syntaxe valide même s'il s'agit d'une balise HTML non valide
  La vérification de la syntaxe est donc peu utile pour écrire un bon code HTML.
• Vérification de l'imbrication des balises :
  Dans un document HTML, les balises doivent être fermées dans l'ordre inverse de leur ouverture. Cette vérification identifie les balises non fermées ou mal fermées.
• Validation du html selon DTD :
  Vérifier dans quelle mesure le code correspond à la DTD - Définition du type de document (doctype) spécifiée. Cela inclut la vérification des noms de balises, des attributs et de l'insertion des balises (balises d'un type à l'intérieur de balises d'un autre type).
• Vérification des éléments étrangers :
  Il détectera tout ce qui se trouve dans le code mais pas dans le doctype.
  Par exemple, des balises et des attributs personnalisés.

Pour vérifier la validité du code CSS, il existe un validateur CSS - http://jigsaw.w3.org/css-validator.
La validité du code est le résultat d'un contrôle mécanique de l'absence d'OB formel, selon l'ensemble de règles spécifié.
Vous devez comprendre que la validation est un outil et non une valeur en soi.
Les codeurs expérimentés savent généralement où les règles de validation HTML ou CSS peuvent être enfreintes et où non, et quelles sont les conséquences (ou non) de telle ou telle erreur de validation.
Exemples de cas où un site Web produit du code invalide :

• plus pratique et plus rapide - attributs personnalisés pour Javascrip/AJAX ou
• Optimisé pour le référencement - balisage ARIA.

Il est clair que la validité pour la validité ne sert à rien.
En règle générale, les maquettistes expérimentés respectent les règles suivantes :
- Il ne devrait y avoir aucune erreur grossière dans le code.
- Les mineurs peuvent être tolérés, mais uniquement pour des raisons justifiées.
Concernant l'acceptabilité des erreurs de validation html/CSS :

Les erreurs de validation (VE) peuvent être divisées en groupes :
• OB dans les fichiers modèles :
  Ils ne sont pas difficiles à trouver et à réparer.
  Si certaines erreurs mineures contribuent à rendre le site plus fonctionnel ou plus rapide, vous pouvez les quitter.
• OB dans les scripts tiers connectés au site :
  Par exemple, un widget VKontakte, un script Twitter ou des fichiers vidéo de YouTube.
  Il n'y a aucun moyen de les réparer, puisque ces fichiers et scripts se trouvent sur d'autres sites et nous n'y avons pas accès.
• Règles CSS que le validateur ne comprend pas :
  Le validateur vérifie que le code du site correspond à une version spécifique de HTML ou CSS.
  Si vous avez utilisé des règles CSS version 3 dans votre modèle et que le validateur vérifie la conformité avec la version 2.1, il considérera alors toutes les règles CSS3 comme des erreurs, même si ce n'est pas le cas.
• Des OB qu'il faut inévitablement laisser sur place pour obtenir le résultat souhaité. Par exemple:
  • balises noindex. Ils ne sont pas valables, mais ils sont très nécessaires et il faut les supporter.
  • kaki. Pour que le site s'affiche correctement dans certains navigateurs, vous devez parfois utiliser des hacks - un code que seul un certain navigateur comprend.
• Erreurs du validateur lui-même.
  Souvent, il ne voit pas certaines balises (par exemple, celles de fermeture) et signale OB là où il n'y en a pas.

Il s'avère qu'un chantier aura presque toujours une sorte de OV.
De plus, il peut y en avoir beaucoup.
Par exemple, les pages principales de Google, Yandex et mail.ru contiennent chacune plusieurs dizaines d'erreurs.
Mais ils ne perturbent pas l'affichage des sites dans les navigateurs et n'empêchent pas leur fonctionnement.
Tout ce qui est écrit ci-dessus s'applique à mes sujets.

DANS sujets difficiles Il y a:
• Fonctions WordPress (par exemple the_category()) qui produisent du code invalide.
• Sortie de vidéos à partir de sites d'hébergement vidéo, par exemple depuis YouTube, et il y a beaucoup de OV dans le code YouTube que ni vous ni moi ne pouvons influencer.
• Boutons réseaux sociaux, qui sont connectés à l'aide de scripts de ces réseaux et contiennent des OV.
• Règles CSS3 et HTML5 considérées comme des erreurs par les anciens validateurs.
  Dans le même temps, les validateurs des versions CSS3 et HTML5 considèrent les anciennes règles comme des erreurs :).
• Parfois, afin d'obtenir un affichage correct dans le navigateur Internet Explorer ou dans les anciennes versions d'autres navigateurs, vous devez utiliser ce qu'on appelle des hacks - un code que seul un navigateur spécifique comprend afin d'écrire des règles d'affichage d'un site spécifiquement pour ce navigateur.

En conséquence, vous ne pouvez obtenir un code totalement valide qu'en codant très thèmes simples, c'est-à-dire ceux qui contiennent un minimum de fonctionnalités.
Après avoir terminé la mise en page de l'un de mes thèmes, je le vérifie toujours avec un validateur et corrige toutes les erreurs qui peuvent être corrigées sans perdre la fonctionnalité du thème.
Autrement dit, s'il y a un choix entre la fonctionnalité opérationnelle et la validité, je choisis la fonctionnalité.
Si vous créez vos propres thèmes, je vous conseille de faire de même.
De mon point de vue (et aussi du point de vue de la plupart des concepteurs de mise en page), considérer la validation html/CSS comme la vérité ultime est une erreur. Il est obligatoire de corriger uniquement les agents qui :
- empêcher le navigateur d'afficher correctement la page (balises non fermées et mal imbriquées).
- ralentir le chargement des pages (scripts mal connectés).
- peut être corrigé sans perturber la fonctionnalité du thème.
J'espère avoir répondu à toutes les questions sur la validation.

Je pense que tous ceux qui souhaitent développer et promouvoir des sites Web ont, d’une manière ou d’une autre, rencontré le concept de validité du code. Cette phrase implique l'écriture du code HTML d'un site conformément à certaines normes développées par le World Wide Web Consortium (W3C). Le respect des règles prescrites par cette norme est une garantie de compatibilité entre navigateurs, c'est-à-dire l'affichage correct de la page créée dans tous les navigateurs, ainsi que l'absence d'erreurs affectant la vitesse de chargement et d'autres paramètres.

DANS Internet moderne les critères de qualité de la mise en page du site Web ont commencé à jouer un rôle important, car le webmaster doit désormais obtenir l'affichage correct de la ressource non seulement sur les ordinateurs de bureau et les ordinateurs portables, mais également sur de nombreux appareils mobiles avec une variété de résolutions.

La propreté et la structure du code créé par les développeurs peuvent être détectées en vérifiant la validité du site, qui est effectuée via un vérificateur spécial sur la ressource officielle du W3C. Voici un validateur de code HTML en ligne disponible gratuitement, situé sur validator.w3.org


Avec son aide, vous pouvez vérifier la validité du code HTML de trois manières :

• Valider par URI - vérification par adresse
• Valider par File Upload - analyse du fichier uploadé
• Valider par saisie directe - vérification d'un morceau de code spécifique.

Choix méthode requise effectué en passant à l'onglet approprié :



Voyons ce qui se passe si nous vérifions la validité d'un site bien connu sur Runet, par exemple Habrahabr. Collez-le dans le champ d'analyse et cliquez sur le bouton « Vérifier ». Après quelques secondes, le validateur W3C nous donnera le résultat suivant :



C'est un assez bon résultat, car la vérification de la plupart des ressources produira des dizaines, voire des centaines d'erreurs.

Si vous faites défiler un peu la page, vous pouvez voir exactement où le vérificateur a trouvé les erreurs et leur description, en indiquant les lignes. De plus, il décrit en détail quel est exactement le problème, ce qui facilite sa résolution.

Dans tous les cas, si des erreurs étaient trouvées sur votre site, ne vous inquiétez pas, car d'une part, il existe en réalité très peu de sites Web qui seraient pleinement conformes à la norme W3C, et d'autre part, toutes les erreurs trouvées par le validateur HTML -code peuvent être corrigé.

Vérifier un site pour la validité de son code HTML vous permet de comprendre s'il nécessite des corrections et une optimisation de la mise en page, car la propreté et la bonne structure du code sont un élément important de l'optimisation interne. Une présentation sémantique de haute qualité permet à un autre entrepreneur de comprendre rapidement le code de quelqu'un d'autre, d'augmenter la pertinence du texte et d'accélérer le chargement des pages.

De nombreux articles ont été écrits sur l'opportunité et la nécessité de rechercher les erreurs de validation, et ci-dessus nous avons déjà écrit les principaux avantages que l'on peut obtenir en adaptant le code de votre site conformément aux standards du W3C. De plus, de telles mesures seront également utiles aussi bien dans le cas d'un grand portail ou service que par rapport à un petit blog ou un site Web de cartes de visite.