Reprise du message précédent :
ptain tu la dis...si c'est dla merde IE, je fous un margin-left:2px; il m'en met 3 ou 4 ce con

heu sinon, j'avais déja posté un truc chelou sur le comportement des margin qui "sortaient" du div si y'avais pas de contenu visible avant... je sais pas si  y'en a qui voient de quoi je parle... en gros je suis obligé de mettre du texte dans un div pour que ça rétablisse les margin/padding sinon ça me décale tout

y'a pas une astuce pour corriger ça ?

  ?

ouai pas con, mais c'est pas tres joli comme solution  
 
ça me fait ça:
 

 
 
bon enfin, pour l'instant jvé garder ça

 
T'es sur que ça marche bien sous nux ça ?

up

moi je me demande si je ferais pas mieux de coder uniquement de l'HTML 4.1 strict que du xhtml 1.0 (pas 1.1 deja), ce qui au final change pas grand chose entre les 2 evidemment.

 
Ha oui, c'est sur, c'est pas super joli. Sinon, vu que c'est de la mise en forme, tu peux peut-être essayer de mettre ça dans ta css :

Mais je sais pas trop ce qu'il en est point de vue compatibilité. A essayer.

a mon avis ça sera plus simple de faire xhtml1>html5 que depuis du 4 tout moche

du 4 strict, donc entre le 4 strict et le xhtml y a pas grand difference (en utilisant css et en ayant des bonnes pratique evidemment)

répondez a la question

Skoi la question
 
(uriel > il n'y a même strictement aucune différence, en fait)

mwinmwin fait dans l'hypothetique en demandant quand html5 sortira, et quand faudra t il adapter les applis

Quand il sortira: personne ne le sait, ça fait 3 ans que le WHATWG a commencé à bosser sur Web Applications 1.0 mais on en sait pas plus, et je n'ai pas vu passer de délais au sujet du HTMLWG W3C.
 
Quand il faudra adapter les applis: quand on veux, puisqu'en principe le HTML5 doit être backwards-compatible avec le HTML 4.01 (c'est l'une de ses bases), donc quand il sera sorti et implémenté (surtout ça en fait) on pourra utiliser les améliorations du html5 sur le html4

mais les gens d'opera, safari et firefox qui sont dans le wg n'ont meme pas commencé de prototypes ? et google, ils vont sortir un browser ou bien ?

Euh, et quid des commentaires et des balises ouvrantes/fermantes?

bien sur qu'ils ont deja commence les implementations, comme PoC, mais faut pas se baser dessus, vu que c'est pas encore fige.

C'est plutôt l'inverse en fait, des éléments genre <canvas> qui existent déjà dans les navigateurs sont normalisés

(faudrait savoir, tu parlais de html 4 bien codé avec de bonnes pratiques ou pas?)

les web forms sont deja dans les navigateurs et pas encores normalises

non, je parle de XML vs SGML

Les Web Forms? Genre Web Forms 2.0 ou d'autres?

Oui enfin c'était uriel qui parlait de bien/mal écrit en fait, donc ça revient au même.
 
Commentaires -> il n'y a pas à ma connaissance des masses de différences entre les commentaires HTML et les commentaires XML, dans les deux cas ils sont ignorables par le parser et ne doivent pas contenir de chaînes "--"
Balises ouvrantes/fermantes -> Tu parles de la possibilité de ne pas fermer certaines balises HTML, ou de la fermeture des éléments vides là?

ouais, les web forms 2.0 y a une implementation partielle au moins dans opera.
 
pour les commentaire, leur formalisme est different. Le probleme se pose (enfin, se posait) surtout dans l'interpretation du contenu des balises <scripts>
Et sinon, je parle de l'obligation de ne pas fermer certaines balise HTML, car le parseur SGML ne comprend pas l'autre forme car non specifiee dans le DTD.

C'est un peut fort de dire que les WF2 ne sont pas encore normalisés je trouve

La spec n'est pas encore une reco, mais elle est plutot stable et n'a pas bougé ces 6 derniers mois

La dichotomie restera -- je présume -- la même, elle vient du fait que les parseurs XML ont le droit de dégager totalement les commentaires

Le HTML5 n'est pas un dialecte SGML. SI tu veux savoir comment il se parse exactement, c'est documenté

 
Google Browser, c'est une rumeur, vieille comme le monde, elle est relancé ?

 
Il sera en bundle avec Duke Nukem Forever

genre <br /> et autres balises solitaires?

 
Coder un browser en interne ET financer le dev d'un autre browser en même temps ?  
 
Google Browser ça existe bien, ça s'appelle firefox

En exclusivité sur la Phantom

 
Bande de couillons    
 

 
Ouais...c'est que j'ai cru comprendre en lissant quelques sites.

Oui mais non, il a raison, un HTML bien écrit, tu fermes pas une balise br/hr/input/img, etc.
Donc un html4 strict n'est pas forcément un bon XHTML, même si l'inverse est vrai.

En théorie si on veut être SGML-compliant. Sauf qu'aucune UA ne parse le HTML comme du SGML. Dans les faits ça n'a aucune importance, raison pour laquelle le HTML5 n'est plus en SGML et accepte e.g. "<br/>" afin d'être en sync avec la réalité des implémentations.

Ah non, si l'un n'est pas vrai l'autre ne peut pas non plus être vrai.

Ton objection signifie même explicitement qu'un fichier XHTML valide et correct n'est pas un "bon" fichier HTML (l'inverse étant qu'un "bon" fichier HTML n'est même pas un fichier XHTML valide)

Non, je dis l'inverse, c'est pourtant pas dur à comprendre.
Tu as ton joli fichier XHTML valide
ma ligne<br />
=> Hop, ça passe niquel en HTML
Tu as ton jolie fichier HTML valide
ma ligne<br>
=> Niqued, pas de fermeture pour être valide XHTML
 
Donc un XHTML peut très bien être un HTML niquel mais pas l'inverse.  

Ce n'est absolument pas ce que tu me dis.
 

• Tu parles de HTML "bien écrit" comme ayant les balises vides non fermées (je ne suis pas d'accord mais si tu veux)
• Donc utiliser un fichier XHTML comme du HTML fait que ton fichier HTML est "mal écrit" de part tes standards, et en bonus invalide si on le file à un parseur SGML (les balises vides ne sont pas fermables au sens XML en SGML), exactement ce que j'ai dit
• Et un fichier HTML valide et "bien écrit" (là encore d'après tes standards) est un fichier XHTML totalement invalide (normativement imparseable, les navigateurs doivent refuser de l'afficher), là encore ce que j'ai dit.

Et au final, le problème ce sont tes standards de considération d'un "bon html".

Si, c'est exactement ce que je dis.

C'est pourtant le cas, le HTML n'impose pas la fermeture de certaines balises, même en strict et même bien écrit. Si pour moi un html bien écrit signifie au moins qu'on ferme un paragraphe (ce qui n'est pas obligatoire), il n'y a aucun intérêt à fermer un <br>, un <input> ou un <img>. Sans compter les balises HTML supprimées dans le XHTML.

Non, tu peux parfaitement faire du zèle et fermer tes <br /> en HTML, donc une récupération de fichier XHTML ne posera pas de problème si tu changes le doctype du document par HTML

Y'a pas 36 façons de bien écrire du HTML.

Voilà ce que je considère comme un bon HTML 4 Strict, lisible :

<html>
<head>
<title>Ma belle page propre et valide</title>
</head>
<body>
<h1>Le coin du téléchargeur</h1>
<p>Observez l'illustration suivante<br>
<img src="monillustration.jpg" title="illustration à observer" alt="illustration"></p>
</body>
</html>

Bah ça, tu peux pas en faire un XHTML juste en changeant le DocType

Je prends le même en XHTML :

<html>
<head>
<title>Ma belle page propre et valide</title>
</head>
<body>
<h1>Le coin du téléchargeur</h1>
<p>Observez l'illustration suivante<br/>
<img src="monillustration.jpg" title="illustration à observer" alt="illustration"/></p>
</body>
</html>

Celui là passe très bien pour un HTML4 Strict

Donc je réitère, un XHTML peut très bien se convertir en HTML au contraire du HTML, même bien écrit, qui a peu de chance d'être un correct XHTML.
Après, si toi au grand masklinn, tu considères que mon HTML n'est pas correct parce que je ne ferme pas les balises, je te répondrais qu'il n'y a aucune raison de le faire et que ma page aurait pu être créé avant la validation du XHTML.

Non, si tu veux faire ton nazi prière de le faire jusqu'au bout: si les éléments vides sont représentés par des tags fermés ce n'est pas du HTML valide, parce que ce n'est pas du SGML valide.

Où ais-je dit un truc pareil? Aux dernières nouvelles c'est quand même toi qui considère que du HTML avec des éléments vides fermés explicitement "à la HTML" n'est pas du "bon" HTML

Bah prends le bout de code et passe le au parseur du W3C Validator, qu'est-ce que tu veux que je te dise.  
 

Pas de bol, le validateur W3C est hautement incomplet: il ne prend pas en compte ce genre d'erreurs à la syntaxe SGML parce que les implémentations ne le prenne pas en compte, et ce n'est pas la seule chose qu'il ignore (un document XHTML valide doit avoir une déclaration de namespace [<html xmlns="http://www.w3.org/1999/xhtml">], donc ton document XHTML est invalide puisqu'il ne l'a pas, et pourtant le validateur ne gueule pas. D'ailleurs cette déclaration de namespace suffit à rendre un document XHTML valide invalide en HTML, puisqu'elle n'existe pas en HTML)

Ha pardon, la prochaine fois que j'ai un document à valider, j'irais le montrer au grand seigneur Masklinn, le validateur W3C, caypourlespaydays.

Il manque le prologue xml aussi

Edit : Le SGML mal formé/invalide te pétait à la gueule non?

Attends, tu veux être pédant, on peut faire pédant, et si on veut faire pédant on va lire directement la spec, pas un validateur ne respectant pas la spec de manière intégrale parce qu'il doit faire des concessions d'ordre pratique dues aux comportements des implémentations

Maintenant si tu ne veux faire pédant que quand tu as l'impression que ça t'arrange mais que tu le refuses quand tout d'un coup ça ne supporte pas ton point de vue, on a un problème, c'est pas comme ça que ça marche

Et en l'occurence, je t'ai montré specs à l'appui qu'un document valide "bien codé" XHTML n'est pas un document valide HTML (du tout), et inversement, j'ai même fait l'effort de te linker la section de la spec XHTML que je mentionne, si tu n'es pas content tu ne peux t'en prendre qu'à toi même

c'est pas obligatoire ça (je le pensais aussi au début, j'ai découvert ça en 2005 ou 2006, le prologue est optionnel)

Probablement, mais je ne pourrais pas t'en assurer, n'ayant jamais utilisé de "vrai" SGML.

C'est recommandé en XHTML 1.0 et obligatoire en 1.1 puisqu'il doit être servi en application/xhtml+xml.

Pas d'accord, la spec XML dit que le prologue est recommandé (should) mais pas obligatoire (qui correspond à must). De même, la section "Conformance Definition" de la spec XHTML 1.1 ne mentionne le prologue que par:

Donc le sensest le même que dans la spec XML:

• Le prologue XML n'est pas obligatoire
• Le prologue XML est (fortement) recommandé
• Le prologue XML devient obligatoire si le document est dans un encodage autre que utf-8 ou utf-16

C'est vrai excuse moi, j'étais vexé en fait, moi qui avait tant foi en le W3C Validator. (Tidy aussi m'avait rien dit d'ailleurs).