Question

Lorsque vous développez une nouvelle application Web, quelle version de HTML devriez-vous viser ?

MODIFIER:

cool, j'essayais juste de me faire une idée des autres. J'ai tendance à utiliser XHTML 1.0 Strict dans mon propre travail et Transitional lorsque d'autres sont impliqués dans la création de contenu.

J'ai marqué le premier message de transition XHTML 1.0 comme étant la « bonne réponse », mais je crois fermement que toutes les réponses données à ce stade étaient également valables.

Était-ce utile?

La solution

Je tournerais pour XHTML Transitional 1.0.Il existe encore quelques nuances qui n'aiment pas le XHTML strict, et la plupart des éditeurs que j'ai vus maintenant vous donneront les coups de pouce appropriés pour vous assurer que les choses sont bien faites.

Autres conseils

HTML 4.01.Il y a absolument sans raison utiliser XHTML pour tout sauf des problèmes expérimentaux ou académiques que vous souhaitez uniquement exécuter sur les navigateurs Web « obscurs ».

XHTML Transitional est totalement inutile, même pour ceux navigateurs, donc je ne sais pas pourquoi quelqu'un viserait cela.Il est en fait plutôt alarmant qu'un certain nombre de personnes recommandent cela.

Je dirais que viser HTML 4.01 est le plus prévisible, mais Teifion a vraiment raison, "tout ce qui rend votre page fera l'affaire".

en réponse à Michael Stum:

XHTML est basé sur XML, il permet donc une analyse plus facile et vous pouvez également utiliser les composants XML de la plupart des IDE pour interroger et insérer des éléments par programmation.

Ce n’est certainement pas vrai.Une grande partie du XHTML sur le Web (sinon la plupart) n'est pas conforme à la validité XML (et ce n'est pas nécessaire - il n'est pas envoyé au format XML).Essayer de traiter cela comme du XML lorsque vous le traitez ne fera que vous causer beaucoup de maux de tête.Cette page sur Stack Overflow, par exemple, générera des erreurs avec de nombreux outils XML impitoyables en raison d'un balisage non valide.

De transition les versions XHTML et HTML sont obsolètes.Ils étaient destinés uniquement pour les anciens agents utilisateurs qui ne prennent pas en charge CSS.Voir explication dans la DTD.

Le W3C conseille d'utiliser Strict autant que possible, et de nos jours, c'est certainement possible.

La version de transition a déjà été supprimée dans XHTML/1.1 et HTML5.


XHTML/1.0 possède exactement les mêmes éléments et attributs (sémantique) que HTML4.La spécification XHTML/1.0 ne spécifie même aucun élément !Pour tout autre chose que la syntaxe, il fait référence à HTML4.

De plus, vous ne pourrez utiliser aucune fonctionnalité de XHTML qui n'est pas disponible en HTML (espaces de noms, XML DOM) si vous envoyez des documents en tant que text/html, et malheureusement, cela est nécessaire pour la compatibilité avec IE et d'autres navigateurs HTML uniquement.

En 2008, le bon choix serait HTML4 Strict :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

mais depuis 2016, il n'y a que une version de HTML c'est important.

 <!DOCTYPE html>

@Mike:

Bien que je convienne que la validité n'est pas nécessaire pour effectuer le rendu d'une page (après tout, nous devons conserver la compatibilité IE6 dans...), créer du XHTML valide, compatible ET valide, n'est pas un problème.Les problèmes commencent lorsque les gens sont habitués à HTML 4 et utilisent les balises et attributs dépréciés.

Ce n’est pas parce que le Web est un tas de merde que chaque nouvelle page doit également être un tas de merde.La plupart des erreurs de validation sur SO sont si triviales qu'elles ne devraient pas prendre trop de temps à corriger, comme des guillemets manquants sur les attributs.

Mais cela peut encore être un peu inutile, étant donné que le W3C n'a de toute façon aucune idée de l'endroit où il veut aller (voir HTML 5) et qu'une certaine grande société de navigateurs qui fabrique également des systèmes d'exploitation ne s'en soucie pas non plus, donc un site pourrait aussi bien envoyer son doctype que HTML 1337 Sucks et les navigateurs essaieront toujours de le restituer.

Il y a quelques convaincant avertissements sur l'utilisation de XHTML, en se concentrant principalement sur le fait que le type MIME d'un tel document doit être envoyé comme suit :

Content-type: application/xhtml+xml

Pourtant, IE 6 et 7 ne prennent pas en charge cela, et les sites Web doivent alors l'envoyer sous la forme :

Content-type: text/html

Malheureusement, cette méthode est considéré comme nocif.

Certains déplorent également le fait que, même si le but du XHTML est de rendre les pages Web analysables par un analyseur XML, il a échoué en pratique en raison d'une utilisation incorrecte sur les sites Web existants.

Je préfère toujours écrire des documents en XHTML 1.0 Strict, principalement à cause du défi et du propreté et vérifier les erreurs qu'un validateur donne.J'apprécie un peu mieux la syntaxe, car elle m'oblige à être très explicite sur la fin des balises, etc.C'est pour moi plus un choix personnel que purement technique.

Dillie-O a raison avec sa réponse de XHTML 1.0 Transitional, mais je suggérerais de tirer sur XHTML 1.0 Strict et de ne recourir à Transitional que s'il y a une fonctionnalité dont vous avez absolument besoin et que Strict n'autorise pas.

Tout ce qui affiche votre page le fera, quelle que soit la norme populaire que vous utilisez.XHTML est plus strict et probablement "meilleur", mais je ne vois pas quels avantages vous obtiendrez avec une norme par rapport à une autre.

Je suis pour XHTML Strict à chaque fois.Je crois fermement que HTML devrait ressembler davantage à XML.Il n'est pas difficile de le valider si vous connaissez XML et le validateur de W3 vous met de toute façon sur la bonne voie.

XHTML 2.0 se dirige vers ce que le W3 vise depuis longtemps : le web sémantique.Le meilleur avantage de XHTML 2.0 pour moi est que chaque page conforme sur le Web sera compréhensible en tant que contenu ou article (car c'est ce que sont les pages - des documents) car elles s'appliquent toutes au même standard.Vous seriez alors en mesure de construire des interprètes (c.-à-d.navigateurs) qui présentent le contenu d'une manière complètement différente - il y a littéralement des milliers d'idées qui attendent ici.

Si vous souhaitez utiliser XHTML 1.0 d'une manière compatible HTML, c'est très bien.Cependant, notez que le validateur W3C et les DTD XHTML ne savent rien des types MIME ni de la façon dont les navigateurs se comportent différemment (comme la correspondance nom/identifiant <map>) entre eux.Les DTD ne savent rien non plus de la manière dont les navigateurs prennent en charge certains éléments (comme <embed> par exemple).

Cela signifie que les DTD XHTML et le validateur ne reflètent pas la réalité et qu'essayer de s'y conformer est inutile.

Si vous souhaitez utiliser XHTML uniquement pour pouvoir fermer certains éléments avec /> (lorsque compatible HTML), utilisez simplement le balisage HTML5 (le navigateur est donc en mode standards complets).HTML5 permet l'utilisation de /> d'une manière compatible HTML (de la même manière compatible HTML que vous devez le faire lorsque vous utilisez le balisage XHTML 1.0 avec text/html).Ensuite, tenez-vous-en à ce qui fonctionne (vous le savez mieux que certaines DTD) dans les navigateurs.

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8"/>
        <title></title>
    </head>
    <body>
        <p>Line1<br/>Line2</p>
        <p><img src="" alt="blank"/></p>
        <p><input type="text"/></p>
        <p><embed type="application/x-something" src=""/></p>
    </body>
</html>

Ensuite, utilisez http://validator.nu/ pour être sûr qu'il est au moins bien formé.

Si vous disposez d'outils pour générer votre XHTML comme n'importe quel autre document XML, optez pour XHTML.Mais lorsque vous utilisez simplement des modèles de texte brut, la concaténation de texte, etc.vous êtes d'accord avec le bon vieux HTML 4.01.

Les navigateurs commencent désormais à prendre en charge cette norme vieille de 10 ans.

Important: Évitez d'être traité de bozo lors de la production de XML

Personnellement, je préfère XHTML 1.0 Transitional.

XHTML est basé sur XML, il permet donc une analyse plus facile et vous pouvez également utiliser les composants XML de la plupart des IDE pour interroger et insérer des éléments par programmation.

Transitional n'est pas aussi strict que strict, ce qui le rend relativement facile à utiliser, comparé à strict qui peut souvent être un PITA. Comparaison entre transitionnel et strict

La version 1.0 est "plus compatible" que la version 1.1 et la version 1.1 semble être encore en cours de développement.

Je vise XHTML 1.0 Trans.Il est préférable de se conformer afin que lorsque des bogues sont corrigés dans les navigateurs, vous ne travailliez pas soudainement contre la montre pour essayer de comprendre ce qui doit réellement être modifié.

À mon avis, la version 1.1 est ratée et la version 2.0 a été réduite en miettes :Ai-je vraiment besoin/vouloir une balise d’en-tête/pied de page ?

Je ne pense pas que ce soit vraiment important que vous utilisiez XHTML ou HTML brut.L'objectif final ici est d'avoir une maintenance réduite et un développement rapide grâce à un rendu prévisible.Vous pouvez l'obtenir en utilisant xhtml ou html, à condition que vous disposiez d'un code de validation.J'ai même entendu des arguments selon lesquels il est préférable de cibler le mode bizarreries, car les nouvelles versions des navigateurs ne changent pas le mode bizarreries, la maintenance est donc facile.

En fin de compte, tout cela devient une soupe de balises, pour une bonne raison, car amener les développeurs d’applications Web à écrire du HTML sans erreur signifie leur demander d’écrire du code sans bug.Les validateurs ne sont d'aucune aide, car ils valident uniquement la page vue initiale.C'est aussi pourquoi je n'ai jamais vu l'intérêt du xhtml comme XML pour quoi que ce soit au-delà des sites statiques.Le niveau d'arrogance dont un développeur d'applications Web devrait avoir besoin pour proposer son application Web au format XML est stupéfiant.

HTML 4.0 strict ou ISO HTML.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top