Le HTML redémarre !

Citation : Kanor

Ça l'est, c'est juste une chose que j'avais remarquée et qui m'amusait

Citation : iKs
iKs : il n'est pas possible de répondre à ce que tu dis car on n'a aucune matière à réponse ; le Web n'est pas une compagnie aérienne, et poursuivre la comparaison plus loin comme tu l'as fait n'est pas pertinent ; et cela l'est encore moins puisque tu mélanges tout et n'importe quoi (je parlais de structure, et tu me réponds avec une histoire de pilotes avec des moteurs de sous-marin sur un avion déclassé. Où est la logique ? Surtout que je ne peux pas voir à quoi correspondrait par analogie ni le moteur de sous-marin, ni le fait que le pilote soit inexpérimenté, ni en quoi l'avion serait "rafistolé", comme on l'a dit plus tôt). Au final, je ne peux pas te répondre car c'est sans queue ni tête.
Par ailleurs, je ne vois pas en quoi je "résume ta pensée" parce que d'une part je ne suis pas du tout d'accord avec toi, et d'autre part je considère que tu as tord.

Cependant, quant à l'utilité :
Pour reprendre le même exemple (qui s'écarte déjà de la réalité, car chaque internaute dispose de son propre matériel, ce qui n'est pas le cas ici), il faudrait alors construire des nouveaux aéroports et de nouvelles pistes si l'avion est d'une envergure non compatible avec ce qui est déjà construit.


Autre chose pour iKs : dans ta justification (et sans prendre en compte celle-ci), tu omets complètement une chose fondamentale qui est le visiteur. Parce que le webmaster ne se sert pas de HTML pour réchauffer son café, mais pour produire du contenu aux internautes.
Or le XHTML apporte des nouveautés et en apportera d'autres (de part ses aspects modulaire, extensible et tout le reste) ; et au fur et à mesure que les technologies progressent, les besoins changent (l'inverse est vrai également). Non, utiliser XHTML ne rendra pas plus beau, plus fort ni plus intelligent (c'est ce qu'il faut comprendre si tu dis qu'il est sensé "apporter quelque chose au webmaster"), mais en tant que fournisseur de contenu, on est fournisseur de service. Et en tant que fournisseur de service, on doit savoir évoluer pour que le service soit approprié et réponde aux besoins de l'utilisateur.


Bluestorm : c'est un sujet dont on avait déjà parlé je crois, et je crois aussi que je n'ai pas su te répondre [le sujet de l'implémentation d'un parseur XML quant à l'utilisation de XHTML]. Ce sont les quelques raisons qui sont avancées, et qui sont cohérentes ; ceci dit, je ne connais ni les rouages du web ni comment cela se passe réellement du côté des développeurs, au niveau des exigences, des obstacles et des contraintes. Il faudrait faire partie des décideurs pour le savoir.
Donc s'il y en a, je ne serais pas capable de te les donner, si ce n'est celles que j'ai déjà énoncées. Il y a très certainement une part de mauvaise volonté dans tout cela, mais également des problèmes techniques qui se regroupent sous le terme de "difficultés d'implémentation" (dont l'implémentation en elle-même, la globalisation de la technologie, les webmasters, etc.). Pour ces derniers, je ne suis pas capable de te faire un topo correct, et c'est pourquoi je suis incapable de répondre à ta question (que je me pose aussi).

Je ne m'inscrirai pas dans le débat HTML 4 vs xHTML 1 parce que je ne connais pas le HTML 4 (j'ai tout appris avec les tutoos de M@téo21).
Par contre je suis allé voir le lien en bas de news (que j'invite tout le monde à consulter) et je me suis fait un début d'idée.
Pour ce que j'en ai vu, le xHTML 2.0 me parait assez sympa, j'aime particulièrement l'ajout des atributs "href" sur n'importe quelle balise (rudement pratique !), et bon nombre des autres innovations ont l'air sympa à première vue.
Par contre le HTML 5 m'a l'air d'un beau bordel (passez moi l'expression) :
-le retour aux iframe nuit à l'accessibilité pour les handicapés
-les balises de mise en forme risquent à mon avis d'avoir tendance à "court-circuiter" le côté "design séparé" offert par le CSS.
- de plus, ce nouveau language utiliserait certaines balises de mise en forme HTML 4 (comme <i>), mais qui auraient un SENS DIFFERENT ! De quoi donner très envie aux developpers encore attachés au HTML 4 d'y rester définitivement !! Imaginez-vous devoir apprendre une autre langue où des mots que vous connaissez ont changé de sens !

En résumé je suis pour l'instant plutôt favorable a l'xHTML 2.0 mais vraiment réticent quant à l'HTML 5. Maintenant je n'ai pas assez d'expérience et une grande partie des enjeux m'échappent sûrement...

Citation : Kanor
Il n'empéche pas que le xHTML ait contribué grandement à généraliser le CSS

Fieldset > Iks t'a très bien répondu... ou alors c'est toi qui t'es mal exprimé

Jérémie > Thunder aurait fait son site sans aucune CSS, il aurait été codé en Html tout autant...

Moi pareil, j'ai apprit xHTML grâce aux cours de matéo21, donc HTML, je connais pas trop... Mais c'est toujours bon à savoir, merci pour cette new.

Je viens aussi de relire la page avec les trucs cool/pas cool, et je trouve aussi, comme Yaude, que le HTML5 semble être un fameux bordel. On dirait une soupe de vielles balises, de récentes et de nouvelles. Quant à prendre une position, je serai plus en faveur du XHTML2, mais dans son style, les aspects "pas cool" sont fortement repoussants.

pourvu que tous les navigateurs suivent cette nouvelle mouture

Attention : l'article en bas de la news compare les drafts de XHTML2 et les drafts de la spec de HTML5 faite par le Def. WHATWG et non par le W3C HTML WG ! Celle du W3C HTML Working Group n'a pour l'instant pas vu le jour.

Nous sommes actuellement en pleine discussion pour trouver le meilleur moyen de concilier le travail des deux WG car aboutir à deux spécifications différentes pour une même technologie serait une hérésie que nous souhaitons à tout prix éviter. De là à ce que le WHATWG l'entende de la même manière...

Citation : iKs

Bah moi je te dis qu'il apporte pour tout webmaster mais le support actuel par les agents utilisateurs est beaucoup trop limité pour que l'ensemble des webmasters l'adopte.

Le SVG, XForms et compagnie ne sont pas réservés à l'élite et sont par ailleurs très utiles, sinon ils n'auraient pas été crées.

@Kanor: Et tu ne penses pas que les navigateurs n'ont pas implémentés XHTML à cause du fait que les développeurs ne l'utilisaient pas ?
Si les producteurs de contenu veulent voir implémenter des possibilités, les navigateurs suivront. C'est entre autre pour ça que IE s'est mis à jour : pour implémenter ce que Firefox proposait et donc rattraper son retard dans l'esprit des devs.

@atly : Tu as résumé ce que je pensais généralement de la situation. Cependant nous n'arrivons pas à la même conclusion, voilà tout.

Je dis qu'HTML est à moitié sous-marin car HTML a été concu à un moment de son existence pour gérer le style de la page, ceci alors que comme nous le savons, le CSS fait ça en 10 fois plus puissant et propre.
De plus, des balises ont été inventées par différents navigateurs puis depreciée / déconseillée / etc.. J'appelle ça du rafistolage : durant la guerre Netscape/IE le HTML est parti en freestyle et maintenant on essaie de réparer (et qu'à moitié d'après la news à propos de certaines balises) au lieu de repartir sur de bonnes bases.
Enfin l'avion est mal piloté car les webmasters font n'importe quoi. Même en HTML 4.01 les documents sont invalides, et comme il faut bien afficher la page, les navigateurs ne bronchent pas et affichent correctement la page (en la considérant comme une soupe de balises et en tentant de corriger au maximum les erreurs). Ceci fait que les mauvaises habitudes persistent et que si on ne reprends pas une certaine sévérité, AMHA on fonce droit dans le mur à long terme.

J'éspère que tu auras compris ma pensée sur ce point (et je t'invite fortement à y réagir).

Concernant ta deuxième partie je ne saisi plus : tu défend en gros l'HTML 5 dans la première, mais tu me dit ici qu'XHTML apportera des nouveautés intéressantes ?
Oui c'est vrai, XHTML est la bonne base (ou plutôt XML) qui permettra des évolutions très très intéressantes, c'est pourquoi je soutiens fortement XHTML 2 ! Cependant actuellement les nouveautés ne sont pas implémentées correctement et ne sont pas connues. Il est donc logique que personne ne trouve d'intérêt à passer à XHTML 1..

C'est ce que je m'efforce à dire depuis le début : oui XHTML est puissant et est le futur (et HTML est AMHA à abandonner) mais il est tout à fait logique qu'en l'état actuel des choses, il ait fait un flop magistral et qu'HTML reste présent en grande majorité sur le Web.

Citation : iKs

Ben c'est un cercle vicieux. Si personne commence à bouger, personne ne bouge.
Mais jpense que c'est aux navigateurs de faire le premier pas, et c'est ce qu'ils font d'ailleurs.

Par exemple si IE6 implémentait un moteur XHTML, le tuto du site du zéro enseignerait le réel xHTML et ce serait un gros succès.

Peut-être que les zéros ne sauraient pas à la sortie du tuto utiliser l'extensibilité que permet l'xHTML mais rien que le fait d'utiliser un parser XML est un gros avantage question praticité pour rendre valide sa page, question rapidité et accessibilité que Deeder a bien précisé.

Ca sa va rebooster le HTML !!

Citation : iKs

Satis commode possum respondere.

Encore une fois, non, je ne suis pas d'accord avec toi ni sur la conclusion, ni sur le principe. Car je ne tiens pas une hypothétique inutilité du XHTML pour cause, et je ne parle absolument pas des pratiques des développeurs ; je résumais uniquement les enjeux du point de vue de l'implémentation pour ceux qui n'avaient pas compris. C'est pourquoi, ne considérant absolument pas les mêmes causes que toi, ni d'ailleurs ne parle de la même chose que toi (et tenant pour faux certaines des assertions à la base de ton raisonnement comme déjà énoncé, je ne peux qu'être en désaccord), les causes étant différentes les conséquences le sont également.
Et ce désaccord ne saurait exister que sur le fond, car de toute manière je ne me permettrais pas de juger pour faux une opinion valable qui se détacherait de la mienne uniquement par l'interprétation des faits et des solutions.


Autre chose :
Tu t'emmêles ici les pinceaux entre le CSS et le HTML. Nous ne parlons pas ici du CSS ; et nous ne parlons pas non plus ici des styles qu'effectivement le HTML a pu gérer. Par conséquent je comprends ta pensée puisque les faits que tu énonces sont justes (excepté certains points sur lesquels je reviendrai), mais je ne comprends pas où cela est sensé nous mener dans la réflexion qui nous intéresse.
Avec ce que tu énonces, il est impossible de discourir sur le HTML5, comme tu peux toi-même le remarquer si tu te relis.
Je m'intéresse (et là est toute la question) à la fonction du HTML telle qu'elle est, c'est-à-dire le balisage et la structuration du contenu ; on devra également considérer le fait que HTML5 a justement dans ses objectifs de permettre notamment un balisage plus propre ou plus puissant, ce qui se fait nonobstant que le HTML ait pu, à un moment ou un autre dans ses versions précoces, être "mal conçu".

"Même en HTML 4.01 les documents sont invalides" : Ah ? ne t'ai-je pas entendu plus tôt discourir du site d'Eric Meyer, du fait qu'en empêchant les navigateurs d'afficher des documents mal conçus on commetrait une grossière erreur ?
Et sans repartir de ce que tu as énoncé précédemment, en quoi les documents HTML4.01 seraient invalides de par leur nature (puisque visiblement, tu ne laisse plus la place ici au développeur en généralisant ; en d'autres termes, "le HTML est mauvais") ?

Je ne vois par ailleurs pas le lien entre le HTML4.01 et les mauvaises habitudes. Ces mêmes mauvaises habitudes peuvent exister dans un document XHTML, et c'est d'ailleurs tout l'interêt du HTML5, qui apporterait de nouveaux outils et une nouvelle "bonne pratique". Là, un éventuel désaccord viendrait ici, et non du reste : le HTML5 permettrait-il d'atteindre ces objectifs ?
Par ailleurs, il est possible qu'on aille "droit dans le mur" ; mais pour des raisons différentes, c'est-à-dire que je ne comprends pas le lien logique dans l'enchaînement. Mais je vais quand même poursuivre : AMHA, pour faire disparaître ces mauvaises habitudes il ne faut pas, par exemple, opter pour une solution radicale qui empêcherait l'affichage dès lors qu'il y aurait un problème de codage (surtout à l'avènement de l'user-generated content). Ce serait impossible à mettre en oeuvre. Par conséquent, je pense à titre personnel que cela doit passer par une sensibilisation des codeurs, une découverte des outils et de leurs avantages, et, primordialement, d'obtenir d'eux qu'ils fassent confiance à ces mêmes outils. Car la confiance (en plus de la méconnaissance) est un des problèmes majeurs dans le changement.
Et cette confiance ne pourrait s'obtenir en faisant une rupture brutale et destructrice (au sens où elle serait restrictive) ; une approche incrémentale, c'est donc aussi un essai de mise en confiance plus progressif.



Concernant ma deuxième partie, il s'agit du même topo. Tu sembles ici considérer que l'on défend soit le XHTML, soit le HTML5, et que défendre les deux serait contradictoire. Cela est absolument contraire à tout ce que j'ai dit et une telle remarque, en plus d'être non compatible avec certains de tes propos, montre une mauvaise compréhension des miens.
Là, tu fais un autre détour obscur sur les différences entre XHTML2 et XHTML1 ; je considère XHTML dans l'ensemble, car XHTML1 apporte également de grandes nouveautés (et XHTML2 est simplement dans la continuité). Et faire la distinction ici, alors qu'on parle de XHTML et de l'HTML dans l'ensemble me paraît peu approprié.
Encore une autre conclusion obscure : "Il est donc logique que personne ne trouve d'interêt (...) dans XHTML1" : je revois ici un des arguments que tu avançais plus tôt (et que je ne partage pas), mais de toute évidence XHTML2 aura le même problème ; par conséquent je ne vois pas l'interêt de cette démarche au sein de ton approche.


Quant à ta conclusion : je ne vois ici qu'une réminiscence de tes propos précédents, mais je ne vois absolument aucune ouverture sur HTML5 (qui est pourtant le sujet de la discussion ET la solution proposée) ou sur les développeurs (alors que c'était pourtant un des arguments de tête que tu avançais). De plus, tu ne conclus pas réellement, car le sujet d'une solution reste inabordé.
Autre différence majeure et fondamentale entre mon approche et la tienne, qui fait que je m'étonne que tu assimiles nos deux approches : mon discours porte essentiellement sur les solutions, tandis que le tien uniquement sur ta vision des causes, que je trouve de plus maladroite.


En résumé, je trouve ton raisonnement incohérent ; certaines choses sont justes, d'autre non dans les faits, mais le plus grave AMHA est que l'interprétation qui en est faite est sans queue ni tête.



Avec tout le respect que je te dois, j'espère t'avoir exposé ce que je pensais, puisque tu m'invitais à réagir.
Bonne soirée,
atly.

Citation : atly

Tu considères donc mes faits comme faux, puisque tu affirme ne pas juger l'interprétation.
Pourrais-tu me détailler rapidement ces erreurs ? Parce que là effectivement tu écris bien, tu sors une magnifique phrase de latin, mais tout cela n'est que phrases sans réel contenu.

Citation : atly

Tout d'abord je ne m'emmêle en rien les pinceaux étant donné que comme tu me l'accorde, l'HTML a été utilisé à la place du CSS et les balises "stylisantes" était standards et très utilisées. De plus le CSS et l'HTML sont intimement liés, que tu le veuilles ou non.
Cependant comme tu le dis le problème n'est pas là. Le problème est que HTML 5 conserve bon nombre de balises (pour l'instant) qui sont totalement à bannir (et qui sont donc "stylisantes"). Dans un effort de continuité, l'HTML 5 garde des éléments foireux des versions précédentes (tu me diras que ce n'est pas encore passé dans les mains du W3C, certes, mais tout de même). C'est là que réside le problème.

Citation : atly

Je n'ai jamais au grand jamais dit que l'HTML était mauvais. Je n'ai pas non plus dis que les documents HTML étaient invalides en eux-même.
J'ai simplement dit que les documents sur le Web, même placés sous le DOCTYPE HTML 4.01 Transitionnal (c'est-à-dire l'un des moins strict), étaient invalides. Et j'ai utilisé cet argument justement pour dire que bloquer complètement l'accès aux pages invalides était totalement irréalisable et stupide.
De plus le site d'Eric Meyer est invalide d'après ce que j'ai vu (avec l'extension Tidy de Firefox qui fait souvent des faux-positifs donc je n'en suis aps sur) donc je ne vois vraiment pas pourquoi tu viens m'en parler ici. Le site d'Eric Meyer était sensé illustré le fait que CSS pouvait très bien s'utiliser avec HTML. C'est tout.
Je te demanderai à l'avenir de faire un effort et de lire mes posts avant de me faire dire n'importe quoi. Merci d'avance.

Citation : atly

Faux.
Un document XHTML envoyé en tant que tel à un navigateur, et donc parsé comme du XML, doit être bien formé pour être traité. En conséquence toutes les mauvaises habitudes, du style ne pas fermer une balise, disparaissent. Et comme le webmaster a, idéalement, envoyé son document en application/xhtml+xml dès le début, il a corrigé au fur et à mesure les erreurs et n'a aucun problème à la fin.
Bien sur cela n'empêche pas de mettre un block dans un inline ou de mal utiliser une balise mais c'est déjà un grand pas de réalisé.

Ensuite comme je l'ai dit plus tôt l'HTML 5 dans l'état actuel des choses ne fait que conserver les problèmes et n'apporte pas de bonne pratique. Au contraire, XHTML (1 et bien sur 2) insiste sur la sémantique en supprimant les unes après les autres les balises de style. Envoyé en tant qu'XML, l'XHTML force également à bien fermer ses balises.
Où sont donc les bonnes pratiques de l'HTML 5 ?

Citation : atly

Peux-tu m'indiquer où tu réponds à cette même question ?
Personnellement tu trouvera ma réponse tout au long de ce messages et tu pourra la tirer de mes réponses précédentes concernant HTML dans son ensemble.

Citation : atly

C'est très simple, si HTML 5 conserve les balises merdiques dont j'ai parlé précédemment et si l'HTML 5 est également considéré comme une soupe de tag par les clients, alors les mauvaises habitudes persisteront. Et avec les nouvelles balises et les nouvelles technologies, s'amplifieront. Et avec l'accès au Web par le plus grand nombre, exploseront.
Résultat : le mur.

C'est pourquoi je pense qu'il faut définir des règles les plus strict possible pour ne pas laisser se faire les mauvaises habitudes.

Citation : atly

C'est effectivement, comme je l'ai dit (cf. plus haut) impossible à mettre en place pour le pages existantes. Cependant les nouvelles pages devraient être valides ou tout du moins bien formées. Comme je l'ai également dit, le fait de forcer incite le webmaster à corriger progressivement et lors de la création, résultat : aucun soucis.
La solution pour décider quelle page doit être valide et quelle page ne doit pas l'être ? Simple. Un DOCTYPE en XHTML Strict donnerai un mode Ultra-Standard ou un truc du style. Ou plus simplement, le parseur XML ne laisserai pas passer les fautes de formation (c'est déjà la cas).

Pour te donner un exemple qui marche bien (à mon avis, mais bien sur tu va me dire que j'ai tort) : si tu oublies de fermer un } en PHP, ton script ne marche plus du tout (ou mal). Est-ce que cela pose en problème aux zéros ? Aucun. Suffit de le savoir et de corriger au fur et à mesure (et de faire gaffe dès le début).

Citation : atly

Génial ! Merci pour l'info. Il faut éduquer les webmasters.. Trop fort ! Merci à toi, ô maitre du concret et des solutions

Citation : atly

Il me semble logique de soit défendre l'XHTML 2 soit défendre l'HTML 5. Si tu défends les deux c'est que tu incites le Web à prendre 2 directions opposées et donc à se "déstandardiser" dans le sens ou même dans le meilleur des mondes les navigateurs auraient à gérer 2 standards. Et pour ce qui est projet à plusieurs c'est génial également.

Bref si c'est ta position, fait le savoir, qu'on en discute

Citation : atly

C'est très simple. XHTML 1 est une réécriture d'HTML 4.01, donc XHTML 1 n'apporte pas de nouvelles balises. De plus, XHTML 1 est interprété comme de l'HTML 4.01 ! On est donc sur de n'avoir aucune nouveauté à l'horizon...
Il n'y a donc en toute logique apparemment aucun intérêt (j'ai bien dit apparemment).

Au contraire XHTML 2 apporte de nouvelles balises, de nouveaux attributs. Ceci attisera la curiosité et donc incitera les gens à utiliser XHTML 2 (juste pour la possibilité de mettre un href dans n'importe quelle balise, ça rocks) et donc les navigateurs à l'implémenter.
Si les navigateurs font bien les choses ils le liront avec un parseur XML (déjà présent chez de nombreux browsers) et donc mon idée de well-formedness dès le départ aura marchée. Bien sur cette situation est utopique.

Citation : atly

Si je n'ouvre pas sur HTML 5 c'est que je considère qu'il en sera de même pour HTML 5 que pour HTML 4. Depuis quand fais-tu le séparation entre les version d'HTML d'ailleurs ?

Citation : atly

Tu proposes donc des solutions sans avoir identifié la cause. De plus tu dis proposer des solutions mais un exemple ci-dessus montre que tu ne donnes que des conseils généraux que tout le monde est capable de ressortir ("faut éduquer les gens", "faut qu'ils codent proprement", "faut qu'ils utilisent les outils à leur disposition", etc..).

Citation : atly

Je ne vois toujours pas en quoi l'interprétation que je fait de ce que j'affirme est sans queue ni tête. Bien évidemment mon avis n'est pas simple, vu la situation actuelle, déjà compliquée, et la situation future sur laquelle nous ne sommes apparemment pas d'accord, encore plus compliquée d'après la news.
Merci de me montrer précisément ce qui n'a pas de sens dans ma réflexion et je tacherai de te répondre.

Je te réinvite bien sur à réagir.
Avec autant de respect,
iKs.

Citation : iKs
Les balises et les éléments ne sont que des détails, au contraire du format XML qui apporte beaucoup de choses.

Si IE n'intègre pas de parser XHTML, xHTML2 sera aussi interprété comme de l'HTML 4.01.

Le site d'Eric Meyer est valide par ailleurs.

Citation : iKs

Un document HTML qui n'a pas toutes ses balises fermées peut être bien formé et valide.

Évidemment, on est tout à fait d'accord sur ce point. Cependant ce qui attire les masses c'est les nouvelles possibilités "concrètes". Or XSLT ou SVG ne représentent pour la majorité d'entre nous que des abréviations.
De plus, même si XML et cie étaient connus, le fait que les navigateurs interprètent les pages XHTML comme de l'HTML empêcherait toute avancée.

Bref je ne sais pas exactement comment il faudra faire pour que tout remarche correctement, je l'avoue. Comme tu l'as dit nous sommes dans un cercle vicieux, cependant je crois qu'XHTML 2 et ses nouveautés concrètes (j'en répète une intéressante : la présence de l'attribut href sur toutes les balises) inciteront les gens à vouloir l'utiliser et à s'y intéresser et donc les navigateurs à l'intégrer "proprement" (jusqu'ici il n'y avait rien à changer puisque les balises restaient les mêmes). Après bien sur je ne suis pas devin..

Sinon IE intègre un parser XML par défaut d'après ce que j'ai lu (je ne peux pas tester personnellement) mais il n'est pas activé. Si tu envoie à IE un fichier XML avec une stylesheet XSL associée, par exemple, tu verras que ça fonctionne. Donc ça m'a l'air d'être un manque de bonne volonté de la part de Microsoft..

Enfin, un document HTML qui n'a pas ses balises fermées n'est pas bien formé au sens XMLien du terme. Il peut cependant être valide (ce qui est faux de l'XHTML qui doit être bien formé pour être valide).
Mais la well-formedness XMLienne ne s'applique pas à l'HMTL de toute façon donc à quoi bon en discuter

Merci pour l'info sur le site d'Eric Meyer.

Attention : je n'ai pas dit que tout était faux et loin de là.
C'est pourquoi j'ai précisé que ce que je te dis n'était en aucun sens unilatéral, et qu'effectivement j'attendais un retour de ta part pour en discuter ; ce qui signifie que j'y trouve donc de l'interêt.
Je n'ai fait que noter quelques points que je ne partageais pas, ou dont la rigueur ne me paraissait pas juste. De plus, certains de tes exemples ou arguments sont erronés. Je considère que c'est cela qui fait la différence ; ceci dit, je considère aussi que ce sont ces détails qui font le désaccord, et qu'il suffit qu'un point dans le fond ne soit pas conforme à mes opinions pour que le reste le soit aussi.
Une autre chose à clarifier est, comme tu l'as toi-même remarqué, que je n'ai pas donné mon opinion sur le sujet. Mon opinion reste personnelle, et j'énonce ainsi les principes qui selon moi devraient être respectés dans la recherche d'une solution ; quant à mon opinion, je ne me permettrais pas non plus de l'exposer sans y consacrer entièrement une étude. (Je ne juge pas au feeling, et là le point sensible est qu'il ne s'agit pas que d'une opinion abstraite, mais de savoir si une solution sera dans le futur plus ou moins appropriée ; ce qui nécessite un effort d'analyse sur le sujet que j'avoue ne pas encore avoir consacré.)



Une fois ce point clarifié, continuons (dans l'ordre des idées) :
"Tu considères donc mes faits comme faux, puisque tu affirme ne pas juger l'interprétation."
Ce n'est pas cela. Je les considère parfois comme peu pertinent, ou non propices à la discussion en cours. Comme je l'ai dit un peu plus haut, si une hypothèse se trouve erronée ou mal placée, l'interprétation peut s'en trouver faussée.
Ainsi, il y a un rapport que tu n'as pas semblé prendre en compte : ce n'est pas que je ne juge pas l'interprétation, mais l'interprétation dépend avant tout du raisonnement dont elle découle.
Quant à savoir si mes phrases sont réellement sans contenu, en me référant au paragraphe que je viens d'écrire c'est plutôt que j'y ai glissé une nuance qui malheureusement ne s'est pas faite suffisamment entendre. Ou alors que je n'exprimais pas mon opinion comme je l'ai justifié plus haut.
Ainsi, je vais tenter d'être plus explicite à partir de maintenant.
(Inutile, de plus, de s'attaquer à mes phrases plus qu'à mon raisonnement.)


Deuxième point : Comme je me suis évertué à le dire, je ne considère que le HTML en lui-même, et non en pratique. HTML5 est en Working Draft et je n'exposerai ainsi pas un jugement que je ne peux pas arrêter (le travail n'étant pas encore fini). Ceci dit, il s'agit ici essentiellement d'une question de confiance, qui s'obtient de différentes manières (cf. précédent).
Je considère alors que le HTML doit effectivement assumer son héritage (mais encore une fois, qu'on ne doit pas s'y arrêter, sinon toute notion de progrès et d'évolution est inexistante ; je suppose que cette distinction a du t'induire en erreur quant à mes propos).

Je ne comprends toujours pas l'idée quant aux CSS. Oui CSS et HTML sont intimement liées, mais c'était là un bon exemple des choses dont je ne comprenais pas la pertinence ici. L'évolution dont il est ici question ne concerne que le HTML, et sa capacité à structurer de manière appropriée tel type de donnée, de faciliter tel dispositif, d'intégrer telle technologie, et caetera.


Kanor ayant déjà répondu aux deux points suivants, je ne le traiterai pas.
J'ajouterai simplement que les "bonnes pratiques" ne se limitent pas à la bonne formation stricte d'un document. Sinon ces évolutions ne serviraient à rien ; au contaire, il s'agit d'utiliser des outils appropriés, de baliser une chose de manière appropriée et non obstrusive, etc.
Par conséquent, un document XHTML peut être mal conçu. Même si le parsing des documents XHTML est plus strict. HTML5 fournit par exemple des outils sémantiques plus poussés que HTML4 ; je ne suis pas entièrement d'accord avec ce que je vois ici des WD de HTML5, mais je parles ici du principe et de l'objectif. Si tu veux un semblant d'opinion à ce sujet, je suis favorable à HTML5 et toute révision future du HTML. A titre personnel.



"Peux-tu m'indiquer où tu réponds à cette même question ?" : Je t'ai déjà répondu plus tôt que cela n'était pas mon intention de le faire. Cette question ne s'insère pas dans le raisonnement que j'ai fait (car il s'agit du jugement du HTML5, que, comme je l'ai dit encore une fois, je n'ai pas exposé ici). Mais il fait une ouverture sur la question qu'actuellement je trouverais intéressante plutôt que le reste.



Autre point important qui mérite d'être dit : Je ne considère pas qu'XHTML2 et HTML5 soient _forcément_ deux positions différentes à prendre. C'est éventuellement un risque [le fait que le tout parte dans deux directions opposées], mais ce n'est pas un problème sans solution ; au contraire, c'est un paramètre fondamental à prendre en compte pour ceux qui définissent actuellement HTML5, car il pourrait être problématique si cette question est mal résolue. Cependant, elle peut l'être, aussi je considère que je peux défendre les deux, bien que ce soit à des termes temporels différents (une approche progressive s'inscrit par définition dans un processus qui vise un autre objectif dans la durée).



Quant à ta solution sur les Doctype : ce serait un autre paramètre compliqué lorsque pour moi la question est de rendre le tout plus simple. C'est une divergence d'avis, bien sûr, mais quant aux réalisations pratiques de cette solution je suis sceptique.
Pour la comparaison avec PHP : je ne considère pas cette comparaison comme viable, car PHP et HTML ont des buts différents. L'un sert à programmer, l'autre à structurer du contenu.
De plus, j'ai parlé de l'user-generated content ; cela serait extrèmement difficile et problématique à mettre en place, et c'est pourquoi je pense que la réelle solution se trouve plus du côté des développeurs que des navigateurs. Oui les navigateurs lorsqu'ils sont peu mis à jours ou implémentent mal une technologie, il est difficile de l'utiliser à grand public. Mais ce n'est pas ici ce dont je parle ; le problème est que les développeurs servent les utilisateurs en leur fournissant du contenu. Les moteurs, eux, n'ont pas le même rôle et sont plutôt les outils des utilisateurs. Régler ce problème primordialement au niveau des outils me semble 1) ne pas résoudre la question à sa source 2) pouvoir potentiellement léser l'utilisateur, ce qui n'est pas ce que l'on souhaite.


Quant à ta phrase "ô (...)" : elle n'a rien à faire dans ton post. D'ailleurs, pourquoi viens-tu me parler de solution concrète, alors que d'une part on est justement en train de débattre sur l'une d'elle (HTML5), et que d'autre part j'ai déjà affirmé ne pas exposer ma vision des choses et les solutions que je propose ?
Par conséquent je ne la considérerai pas comme un argument valable.


Point suivant : je fais la séparation entre HTML5 et les autres versions dans la conclusion car c'est (!) quand même ce dont on parle. Là où HTML est une généralité, HTML5 est une solution proposée et je la considère comme telle dans ma conclusion.

Et enfin, dernier point : je n'ai pas dit proposer des solutions. J'ai cependant énoncé les principes qui doivent guider les solutions. C'est un principe de raisonnement logique.

De même que si je veux savoir comment faire telle chose, je dois me poser d'abord la question des critères essentiels que doivent suivre les solutions, auquel cas elles ne seraient plus viables.



Voilà, je pense avoir répondu à tout ; le maître mot est que visiblement mes propos étaient très fortement nuancés et que visiblement tu n'en as pas tenu compte. La grande majorité des points relevés ci-dessus étaient liés à une chose que tu cherchais dans mes propos et que tu ne trouvais pas, car j'avais décidé de ne pas en parler. L'exemple le plus frais dans ma mémoire est la confusion entre les solutions et les principes des solutions, ce qui sont deux choses absolument différentes.


Avec le même respect toujours (sans cependant considérer toutes les critiques personnelles que tu as bien voulues glisser comme argument).
atly.

PS : J'ai critiqué ton raisonnement, je laisse la critique technique (car certains points/arguments/exemples que tu emploies sont mal choisi ou faux) à d'autres.

Citation : iKs

Jne suis pas d'accord avec toi là-dessus et je te l'ai déjà dit à plusieurs reprises.

Le SVG par exemple est largement connu par les infographistes, il est supporté par les logiciels de dessin vectoriel les plus connus comme Illustrator ou Corel Draw.

XSLT commence à être daté et est aussi une technologie connue...

XForms qui a l'air d'avoir du succès quant à son intégration directe dans la spec xHTML2, peut être dès aujourd'hui utilisé en xHTML via namespace.

Aujourd'hui, tu ne rentres pas dans une boite de dév web sans avoir des connaissances en XML.

Citation : undefined

T'es drôle, cela fait plusieurs fois que tu me sors l'argument du support alors que c'est tout aussi valable pour xHTML2.
Encore une fois jne te parle pas du support, jte parle des possibilités de la spec.

Citation : undefined

Ben si il est activé, vu que comme tu dis un fichier XML associé à du CSS ou XSL fonctionne.

Il ne comprend pas tout simplement l'xHTML. Il ne supporte pas déjà le type mime adéquat ainsi que l'extension (Il te demande de télécharger la page quand tu lui envoies un *.xhtml). Et quand tu lui mets une page au format XML avec une extension .xml avec les doctype et ns adéquats, il ne met pas par exemple le contenu de la balise <title> en titre de page.

Citation : iKs

Tu as juste pris un mauvais exemple. C'était au niveau de la spécification et non du parser.

Même si on aurait un parser HTML qui n'accepterait pas les erreurs de syntaxe, il ne dirait rien sur une balise <p> pas fermée vu que c'est autorisé dans la spec.

J'ajoute une chose au post de Kanor : le parseur XML Microsoft,MSXML, (et d'ailleurs les autres aussi) est effectivement capable de parser du XML (c'est son but), mais est loin d'être capable de gérer un document XHTML actuellement.

Je répondrai surement demain à vos deux posts car vu mon état aujourd'hui je sens que vous pointerez de nombreuses failles

Cependant je me pose une question suite à la dernière remarque d'atly : si j'ai bien compris, à partir d'un parseur XML il est très aisé de réalisé un navigateur ultra-basique qui gère l'XHTML. Comment se fait-il alors que Microsoft ne l'implémente pas ? De la mauvaise volontée ? Une envie de rester à l'HTML (pourquoi cela profiterai-t-il à Microsoft ?) ?

Citation : iKs

Non, les doctypes et namespaces ne sont que éléments qui permettent de vérifier la bonne formation et la validité du document, ils ne permettent pas comment interpréter la spec.
Sinon, on n'aurait pas à dire que Firefox va intégrer le SVG et XForms alors qu'il possède un moteur XML, comme tous les autres navs.

Donc non, le support de l'xHTML n'est pas juste "désactivé", il est inexistant et demande à être développé. Ce qui n'empêche pas qu'il y a de la mauvaise volonté..