5177 sujets

Le Bar du forum

Pages :
(reprise du message précédent)

a écrit :
Veux-tu vraiment un cours complet sur la balise <body> en HTML ? Sur le fait qu'elle est optionnelle en transitional dans ce format ? (Tombez pas dans les pommes... Oubliez ça, plutôt). Cela fait mes délices quand j'ai du temps à perdre, mais ce serait assez stupide en formation, et ne t'aiderait absolument pas à réaliser des sites plus sémantiques (sic), plus interopérables, plus indépendants du media, plus accessibles, etc.


Dis, pour que je puisse aussi agrémenter mes soirées avec les bizaroïderie de html, tu peux me donner 2-3 liens à ce sujet ?

Directement les références du w3c ?
bonjour,

Je rebondis sur une remarque du blog-blueser pour y aller aussi de mon petit coup de gueule, pas sur la remarque, qui es comme d'habitude de qualité, mais sur le fond du débat HTML/XHTML que je trouve simplement ridicule :

a écrit :
... pousser à la roue dans le sens où le fait le W3C lui même : XHTML, et pas HTML ...


La roue du W3C tourne vers un objectif assez clair : le tout XML, qui est déjà une réalité pour des pans entiers du web et au delà puisque XML est désormais une brique fondamentale du monde logiciel.

Prétendre qu'il n'y à pas de différence entre HTML et XHTML est un contre-sens, c'est parfaitement faux.

Pour préciser ma pensée avant de me faire lapider, quand on dis qu'il n'y à pas de différence entre XHTML et HTML on dit simplement qu'on produit le même résultat, la différence, elle, est fondamentale car elle s'appuie sur un choix technologique radicalement différent.

Dans l'évolution des langages à balises, HTML et XML sont situés au même niveau : ils sont tous les deux des applications d'un même langage "ancêtre" : le SGML.

La branche SGML-HTML est strictement consacré à l'édition de contenus web, elle ne sait faire rien d'autre, elle ne peut faire rien d'autre, elle ne pourra rien faire d'autre, version 5 ou pas.

En revanche la branche SGML-XML à été conçue pour permettre, à partir de ce noeud, de créer des sous-ensembles, des dialectes, spécialisés et interopérables entre eux (xhtml, svg, mathml...).

XHTML, dans sa version 1.0, n'est donc qu'une plateforme hybride, destinée à assurer la retro-compatibilité des technologies, mais son but à terme est de permettre à HTML de disparaitre en douceur.

Et pour être encore plus précis, XHTML 1.1 n'à rien de commun avec XHTML 1.0 ce sont deux langages totalement différents, même si ils se "ressemblent".

Dans le projet du W3C, la standardisation comporte trois étapes : HTML->XHTML 1.0 (période de transition), XHTML 1.0 -> XHTML 1.1 (passage au tout XML), XHTML 1.1 -> XHTML 2.0 qui est le point de rupture technologique.

La question n'est donc pas de savoir si tu dois coder XHTML, la question est simplement de savoir QUAND et la réponse c'est MAINTENANT, car, par rapport à l'évolution des technologies XML, tout délai supplémentaire accumule du retard.

L'autre question c'est de savoir si il y à un quelconque intérêt à maintenir HTML, et c'est là que se centre l'essentiel du débat :
Il n'y à objectivement aucun intérêt, aucun avantage, aucun gain.
En revanche, coder en HTML peut être une réponse "provisoire" à certaines contraintes.
Par exemple le niveau de qualification de webmastering ou la nécessité de faire intervenir des modules applicatifs dont la sortie produit du HTML.

Ce qui se résume à la seule question des contraintes, si il n'y en à pas le choix de XHTML s'impose, maintenir HTML serait stupide et contre-productif.

Si il y en à, alors la question se pose et le choix de HTML peut-être fait en ayant à l'esprit, néanmoins, que ce ne peut-être qu'une réponse "transitoire".

Enfin le sursis qu'apporterait HTML 5 à la branche SGML-HTML est très hypothétique en l'état, d'autant qu'il s'agit simplement de tenter d'introduire dans HTML des fonctionnalités déjà existantes dans XHTML modulaire.

Le choix Strict/Transitionnal quand à lui est un détail sans aucune importance acuellement à la seule différence qu'il est beaucoup plus simple de travailler en mode strict.
Ca te prépareras, par ailleurs, à prendre de bonnes habitudes et capitaliser sur l'apprentissage futur des dialectes XML dans lequel il n'y à plus de notion "strict/transtionnal", il y à la règle, point barre.

Enfin, le débat XHTML/CSS ou pas, ou peut, ou à moitié est du même acabit : la séparation forme/contenu est étroitement lié à la technologie XML (c'est son fondement), plus tu vas apprendre à coder de cette manière, où l'accumulation d'expérience est cruciale, plus tu te remerciera dans le futur... Smiley cligne

JP
Pages :