Reprise du message précédent :
C'est censé être l'évolution de la branche html (globalement tous les enhancements sont parait-il reproduisibles en js) , avec un parrallèle une "évolution" vers XHTML 2.0

@0x90 : Ou pas

 
Pour de la prog traditionnelle tu as bien un language bas niveau (asm ou il) et des languages utilisables permettant la compil sur plusieurs plateformes (le C en première ligne) qui sortent du code quasi aussi bon que ce que tu sortirais en faisant de l'asm à la main dans la majorité des cas et qui rendent la choses plus facile et permettent de s'abstraire des spécificités des machines faisant tourner le programme, pourquoi pas faire pareil pour le web ?  
( Et on va dire que dreamweaver, c'est l'équivalent de windev )

J'serais tenter de dire, pour les mêmes raisons qui font aujourd'hui certains navigateurs sont plus aux normes que d'autres

Normalement ils ont prévu du HTML 6.0 car le xHTML c'était pas assez top pour certains (bandes de gros nuls).
http://blog.x-prime.com/index.php/ [...] t-xhtml-20

Diters, en ce moment j'administre un site web. Sur celui-ci y a un formulaire de contact coportant un champ "courriel" et un champs "message". C'est moi qui reçois les mails générés par ce formulaire de contact.  
 
Le problème actuellement, c'est que tous les mails que je reçois ont pour expéditeur "webadmin@monsite.fr", du coup c'est pas pratique du tout pour trier. Par contre quand je fais "répondre", ça répond à la bonne personne.
 
J'ai demandé au prestataire qui gère de formulaire de contact de faire en sorte que pour les mails reçus par ce biais, l'expéditeur soit le courriel renseigné par le visiteur. Il me répond que ce pourrait être considéré comme de l'usurpation d'identité, et être bloqué par des anti-spams. C'est vrai que ça se fait pas ce que je demande, ou c'est de l'embobinade de prestataire ?

Ca n'a strictement aucun rapport: le XHTML2.0 est une rupture franche et complète (enfin ça l'était la dernière fois que j'ai regardé les docs) avec XHTML 1.x, alors que HTML5 a pour but d'être une évolution du HTML4 avec une spécification plus complète et plus claire des comportements (esp. conditions d'erreurs), basé sur les implémentations actuelles du HTML4

super bordel en perspective donc, au niveau de la gestion de differents doctype par les browsers, ça va être super tiens.

1. Les doctypes, actuellement tout le monde s'en branle, la seule chose importante c'est leur forme pour servir de trigger enter quirks et strict
2. Le XHTML 2.0 est extrèmement controversé (c'est d'ailleurs les problèmes, entre autre de rétrocompatibilité, du xhtml 2 qui ont mené le WHATWG à lancer HTML5) et en est à peine à l'état de projet
3. Donc tout le monde s'en fout du XHTML 2.0, HTML5 FTW

 
   
 
C'est un con, il suffit de placer/remplacer le header pour spécifier un email d'expéditeur, et ça n'est en aucun cas de l'usurpation de quoique ce soit dans la mesure ou tu crées une fausse adresse qui sert juste de point de repère.

et donc on oublies le xhtml1.0? parce que je me fais pas chier la bite a bien ecrire si il suffit que je fasse du bel html 4.1, surement mieux pour passer ensuite au 5

et petit article qui traite du sujet ( correctement à mon gout, après faut attendre la validation de master masklinn):
http://www.digital-web.com/article [...] f_the_web/

Je l'ai vu hier (sourcé depuis CSS beauty), c'est une bonne approche

si encore c'était prévisible à chaque fois, ça serait bien

 
Sur et certain ? Parce qu'avant que je lui dise que c'est un con, que je veux qu'il fasse comme je lui dit de faire, il faut que j'ai bien réfléchi quand même.

http://www.zend.com/zend/trick/html-email.php
 
C'est en php, je sais pas ce qu'il utilise, mais envoyer un mail c'est pas sorcier.
 
En gros dans le header t'as From:email@expediteur.com et ReplyTo:email@repondrea.com
 
Ou il modifie From pour que ça corresponde à la personne qui t'as envoyé le mail, ou tu lui demande de changer From pour avoir un truc que tu identifies clairement comme provenant de ton formulaire.

HTML 4.01 et XHTML 1.0 c'est fondamentalement la même chose, les seules différences étant:
 

• Le type mime application/xhtml+xml qu'on ne peut pas utiliser parce qu'IE ne le gère pas
• Le prologue XML qu'on ne peut pas utiliser parce que ça fout MSIE en mode quirks
• Les namespaces XML dont tout le monde se fout
• Les balises xhtml sont impérativement en minuscules et fermées (<elm></elm> et <elm/> ), la syntaxe minuscule est beaucoup plus lisible et compatible HTML, de même que la fermeture des éléments composites, et la fermeture des éléments vides est gérée (ça repose sur des bugs/quirks du parseur, mais ça marche sans problème quand même)

Donc fondamentalement, aujourd'hui la seule différence entre du XHTML 1.0 compatible MSIE et du HTML 4.01 c'est le doctype, du XHTML 1.0 Strict correspond simplement à du HTML 4.01 Strict (théoriquement) propre  
 

J'aime bien son analyse, et j'ai tendance à être d'accord avec lui (en même temps j'aime pas le XML, donc ça facilite les choses )

je ne demandais pas le rapport entre les 2, mais leurs positionnements respectifs j'ai lu qques mails du thread et c'est plus clair maintenant.
j'ai cru qd meme comprendre qu'html aurait une propension plus large que le 4 a etre de l'xml bien formé ?

Normalement, HTML5 sera mieux (read: plus précisément) spécifié, et surtout les comportements en cas d'erreurs (gérées ou pas, balises non ou partiellement fermées, ce genre de trucs) devraient être spécifiés explicitement, donc on se retrouvera avec des pages toujours lisibles même quand invalides (au lieu d'avoir un message d'erreur et pas de page comme c'est le cas en XML), et un comportement en théorie cohérent d'un navigateur à l'autre (comparé au cas actuel où chaque navigateur fait sa petite sauce perso)

yes
j'aime bien aussi la floppée de nouvelles balises orientées contenu/sémantique

Le tout intégré dans IE 8.5, navigateur phrare de Vista XP SP2

effectivement ça donne envie là, l'article de magic au dessus est bien aussi: je savais pas que html 5 etait "conçu" par apple/opera/mozilla, bonne nouvelle pour la compatibilité de ce coté là donc.

y'a pas un mec de IE qu'est à la tête du working group de HTML5 aussi ?

je viens de voir la spec : ça a l'air sympa comme tout, ils réalisent enfin que le web a bougé sans le w3c (genre pour les balises embed qui sont utilisées partout sauf dans les specs html) et y'a plein de nouvelles balises intéressantes (tout ce qui sert aux citations par exemple).
Mais j'ai une question : "la plupart des nouvelles fitures peuvent être intégrées en javascript" : comment on fait dans le cas des nouvelles balises ?

Si, Chris Wilson qui est l'un des chefs de l'équipe MSIE

c'est d'ailleurs le seul dont les mails apparaissent tout pourri dans les archives, et un de ceux reply-on-top

on detourne l'usage d'une autre balise  
(le nombre de truc crade que j'ai pu faire dans une balise span/div )

ok, mais alors concrètement, on met une balise div qu'on transforme en JS, c'est ça ?

du coup on risque de jamais utiliser les nouvelles balises et nouveaux attributs, pour cause de non-compatibilité, et d'en rester aux hacks JS

Salut tout le monde,
vous connaissez un moyen pour faire le même genre de menu animé (le truc en flash en plein milieu de la page) autrement qu'en flash ?
 
http://www.garmin.com/

ça doit être jouable...Full CSS je sais pas...Mais pourquoi pas (Mouais pas fait attention aux fondus)

en full CSS : meem pas en reve ( ne serait ce que pour avoir les fondus  )  
 
en js , ca doit etre jouable , en faisant gaffe a la transparence sous IE et a la mise en cache des images

Et dans quelle mesure interviendrait le js, et le css serait pour quoi ?

C'est largement faisable.
CSS + JS; Pas bien difficile

CSS pour la mise en forme
JS pour le fondu de l'arrière plan

explique moi comment faire une animation/ un fondu sans js et je te crois  
 
pour ça , je ne vois que le js  
 
de meme pour changer le fond d'un cadre totalement different du menu, je pense qu'il est plus pratique de le faire en js qu'en CSS  
 
pour le reste, c'est un menu basique > CSS
 
eidt correction d'un lapsus genant

 
Pas besoin de Js
 
vous empilez 5-6 <div> avec un gif en background qui passe de blanc à transparent avec chacun une opacity css différente et des timings différents --> ça fait un fade

http://script.aculo.us/

0x90 : J'ai jamais vu un bourrin pareil

je voulais dire sans js

 
Lol drôle d'idée, mais si ça marche ...

t'es pas la moitié d'un bourrin toi

oui oui oui et les "timings différents" c'est une propriété css qui vient de sortir bien sur