Meilleur moyen d'afficher la source générée d'une page Web ?

Question

Je suis à la recherche d'un outil qui me donnera la source générée appropriée, y compris les changements DOM effectués par les requêtes AJAX, pour l'introduire dans le validateur W3. J'ai essayé les méthodes suivantes :

1. Barre d'outils du développeur Web - Génère une source invalide selon le doc-type (par exemple, il supprime la partie autofermante des balises). Perd la partie doctype de la page.
2. Firebug - Corrige les défauts potentiels de la source (par exemple, les balises non fermées). Perd également la partie doctype des balises et injecte la console qui est elle-même du HTML invalide.
3. IE Developer Toolbar - Génère des sources invalides en fonction du type de document (par exemple, toutes les balises sont en majuscules, ce qui est contraire à la spécification XHTML).
4. Surligner + Afficher la source de la sélection - Il est souvent difficile d'obtenir la page entière, cela exclut également le type de document.

Existe-t-il un programme ou un module complémentaire qui me donne la version actuelle exacte de la source, sans la corriger ou la modifier d'une manière ou d'une autre ? Jusqu'à présent, Firebug semble le meilleur, mais je crains qu'il ne répare certaines de mes erreurs.

Solution

Il s'avère qu'il n'y a pas de solution exacte à ce que je voulais comme l'a expliqué Justin. La meilleure solution semble être de valider la source dans la console de Firebug, même si elle contient des erreurs causées par Firebug. Je tiens également à remercier Forgotten Semicolon pour avoir expliqué pourquoi "View Generated Source" ne correspond pas à la source réelle. Si je pouvais marquer 2 meilleures réponses, je le ferais.

Answer 1

Justin a raison. Le point clé ici est que le HTML est juste un langage pour décrire un document. Une fois que le navigateur le lit, c'est parti . Les balises ouvertes, les balises fermées et le formatage sont tous pris en charge par l'analyseur syntaxique. et puis s'en aller . Tout outil qui vous montre du HTML est le générer sur la base du contenu du document, de sorte qu'il sera toujours valide.

J'ai dû expliquer cela à un autre développeur web une fois, et il lui a fallu un peu de temps pour l'accepter.

Vous pouvez l'essayer par vous-même dans n'importe quelle console JavaScript :

el = document.createElement('div');
el.innerHTML = "<p>Some text<P>More text";
el.innerHTML; // <p>Some text</p><p>More text</p>

Les balises non fermées et les noms de balises en majuscules ont disparu, car le HTML a été analysé et éliminé après la deuxième ligne.

La bonne façon de modifier le document à partir de JavaScript est avec document méthodes ( createElement , appendChild , setAttribute ) et vous remarquerez qu'il n'y a aucune référence aux balises ou à la syntaxe HTML dans aucune de ces fonctions. Si vous utilisez document.write , innerHTML ou d'autres appels en langage HTML pour modifier vos pages, la seule façon de les valider est d'attraper ce que vous y mettez et de valider ce HTML séparément.

Cela dit, la façon la plus simple d'obtenir la représentation HTML du document est la suivante :

document.documentElement.innerHTML

Answer 2

[mise à jour en réponse à des détails supplémentaires dans la question éditée].

Le problème que vous rencontrez est que, une fois qu'une page est modifiée par des requêtes ajax, le HTML actuel n'existe plus qu'à l'intérieur du DOM du navigateur - il n'y a plus de source HTML indépendante que vous pouvez valider autre que ce que vous pouvez extraire du DOM.

Comme vous l'avez observé, le DOM d'IE stocke les balises en majuscules, corrige les balises non fermées et apporte de nombreuses autres modifications au HTML qu'il a reçu à l'origine. Ceci est dû au fait que les navigateurs sont généralement très bons pour prendre du HTML avec des problèmes (par exemple des balises non fermées) et réparer ces problèmes pour afficher quelque chose d'utile à l'utilisateur. Une fois que le HTML a été canonisé par IE, le HTML source original est essentiellement perdu du point de vue du DOM, pour autant que je sache.

Il est fort probable que Firefox apporte moins de ces changements, donc Firebug est probablement votre meilleure option.

Une dernière option (qui demande plus de travail) peut fonctionner pour les pages avec de simples modifications Ajax, par exemple récupérer du HTML du serveur et l'importer dans la page à l'intérieur d'un élément particulier. Dans ce cas, vous pouvez utiliser fiddler ou un outil similaire pour assembler manuellement le HTML original avec le HTML Ajax. C'est probablement plus de problèmes que cela n'en vaut la peine, et c'est une source d'erreurs, mais c'est une possibilité de plus.

[Réponse originale ici à la question originale]

Fiddler ( http://www.fiddlertool.com/ ) est un outil gratuit, indépendant du navigateur, qui fonctionne très bien pour récupérer le HTML exact reçu par un navigateur. Il vous montre les octets exacts sur le fil ainsi que le contenu décodé/dézippé/etc que vous pouvez introduire dans n'importe quel outil d'analyse HTML. Il montre également les en-têtes, les délais, le statut HTTP et beaucoup d'autres choses intéressantes.

Vous pouvez également utiliser fiddler pour copier et reconstruire des requêtes si vous souhaitez tester la façon dont un serveur répond à des en-têtes légèrement différents.

Fiddler fonctionne comme un serveur proxy, s'interposant entre votre navigateur et le site web, et enregistre le trafic dans les deux sens.

Answer 3

Je sais que c'est un vieux post, mais je viens de trouver ceci pièce d'or . Il est ancien (2006), mais fonctionne toujours avec IE9. J'ai personnellement ajouté un signet avec ceci.

Il suffit de copier-coller ceci dans la barre d'adresse de votre navigateur :

javascript:void(window.open("javascript:document.open(\"text/plain\");document.write(opener.document.body.parentNode.outerHTML)"))

Quant à firefox, la barre d'outils du développeur web fait l'affaire. Je l'utilise habituellement, mais parfois, certains contrôles asp.net tiers génèrent des balises différentes en fonction de l'agent utilisateur...

EDITAR

Comme Bryan l'a souligné dans le commentaire, certains navigateurs suppriment l'élément javascript: lors du copier/coller dans la barre d'url. Je viens de tester et c'est le cas avec IE10.

Answer 4

Si vous chargez le document dans Chrome, le Developer|Elements vous montrera le HTML tel que manipulé par votre code JS. Ce n'est pas directement du texte HTML et vous devez ouvrir (déplier) tous les éléments qui vous intéressent, mais vous pouvez effectivement inspecter le HTML généré.

Answer 5

Dans la barre d'outils du développeur Web, avez-vous essayé l'option Tools -> Validate HTML o Tools -> Validate Local HTML options ?

El Validate HTML L'option envoie l'url au validateur, ce qui fonctionne bien avec les sites accessibles au public. Le site Validate Local HTML L'option envoie le code HTML de la page en cours au validateur, ce qui fonctionne bien avec les pages protégées par un login ou celles qui ne sont pas accessibles au public.

Vous pouvez également essayer Voir le tableau des sources (aussi appelé Module complémentaire pour FireFox ). Une note intéressante à ce sujet :

Q. Pourquoi View Source Chart change-t-il mes balises XHTML en balises HTML ?

A. Ce n'est pas le cas. C'est le navigateur qui effectue ces modifications, VSC ne fait qu'afficher ce que le navigateur a fait avec votre code. Le plus courant : les balises auto-fermantes perdent leur barre oblique de fermeture (/). Voir cet article sur les sources rendues pour plus d'informations. (archive.org) .