jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Internet

Liens connexes

La demande au W3C (235 hits)
Le site du WHATWG (408 hits)
Annonce de la relance du HTML par le W3C (186 hits)
La page du renouveau groupe de travail HTML (192 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Internet : Apple, Opera et Mozilla poussent HTML5

Posté par Étienne Bersac (Jabber id, page perso, ). Modéré le 13 avril 2007.

Il y a des langages qui n'existent que sur le papier. HTML 5 semble être un de ceux là. Alors qu'en 1999, le W3C avait enterré le HTML à sa version 4 en faveur du XHTML, le WHATWG (fondé en 2004) a développé le HTML5, en vu de faire évoluer ce bon vieux HTML qui n'avait pas que des torts. Un point notable du HTML5 fut l'introduction de la balise canvas. La réponse tardive du W3C fut la réouverture du groupe de travail HTML pour le développement du HTML 6.0, qui reste encore à l'état de brouillon préliminaire. Le groupe de travail HTML a tout juste été recréé le 7 mars dernier, les résultats sont prévus pour le troisième trimestre 2010 !

La demande qui vient d'être faite est cruciale. Il s'agit tout simplement de concevoir le HTML 6.0 à partir du HTML5 et non directement à partir du HTML 4.x. La logique voudrait que le W3C considère le WHATWG comme un groupe dissident. Il faut dire que le développement du HTML 5 a pris quelques années (ce qui est courant dans la rédaction des standards), ce travail serait précieux pour le groupe de travail HTML du W3C.

Le W3C ne renie pas le XHTML qui reste le principal sujet de développement sur ce segment avec le travail sur le XHTML 2. Cette annonce pourrait bien mettre fin à la confusion et redonner au W3C son monopole sur la définition des standards du Web. Espérons-le.

La demande au W3C (235 hits)
Le site du WHATWG (408 hits)
Annonce de la relance du HTML par le W3C (186 hits)
La page du renouveau groupe de travail HTML (192 hits)

> Lire la dépêche (62 commentaires, moyenne: 3,1).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Strictement

Posté par Nÿco (Jabber id, page perso, ) le 13/04/2007 à 08:51. (lien). Évalué à 4.

Si j'ai bien compris :
* "HTML5" (sans espace) est le HTML 4.X++ du WHAT WG
* "HTML 5" (avec une espace) est le HTML 4.X++ du W3C

Maintenant des questions : y aura-t-il une "recommandation W3C" ou norme/standard de niveau équivalent en ce qui concerne le HTML en version 5(.x) ? Ou bien faudra-t-il attendre le HTML 6.x prévu en 2010++ ?

--
Jabber ID : xmpp:Nyco@jabber.fr

[^]Re: Strictement

Posté par Étienne Bersac (Jabber id, page perso, ) le 13/04/2007 à 10:00. (lien). Évalué à 3.
> Maintenant des questions : y aura-t-il une "recommandation W3C" ou norme/standard de niveau équivalent en ce qui concerne le HTML en version 5(.x) ? Ou bien faudra-t-il attendre le HTML 6.x prévu en 2010++ ?

C'est justement l'enjeu de cette demande : la reconnaissance du HTML5.

:)

--
E Ultreïa !

balise canvas et XHTML

Posté par Christophe Roland (page perso, ) le 13/04/2007 à 08:55. (lien). Évalué à 1.

Je trouve que c'est une bonne nouvelle car on peut enfin y voir plus clair.

Je suis de très près ce genre d'actualité (j'utilise xhtml 1.1 et mathml 2 pour mon site web) et je me pose la question: j'aime le xhtml et je pense que je vais continuer à l'utiliser; mais en xhtml, pourra t-on profiter des balises canvas et autres balises utilisées en html 5 ou ce sera réservé au html 6?

si quelqu'un sait me répondre, merci.

[^]Re: balise canvas et XHTML

Posté par Aurélien Croc (page perso, ) le 13/04/2007 à 09:16. (lien). Évalué à 8.
Excusez mon incompréhension mais dans le sens où le XHTML a été développer pour remettre à plat le format HTML, le clarifier, le nettoyer etc. quel est l'intérêt de poursuivre les recommandations pour ce langage plutôt que d'intégrer ces nouvelles balises, si tant est qu'elles soient réellement nécessaire, au langage XHTML ?
À vouloir garder les deux, il me semble que ça laisse aux gens la croyance qu'ils peuvent continuer à développer des sites en HTML et alors le XHTML ne servirait à rien ? (Mis à part pour des marginaux comme certains d'entre nous ?)
- [^]Re: balise canvas et XHTML
  
  Posté par Christophe Roland (page perso, ) le 13/04/2007 à 09:33. (lien). Évalué à 6.
  Le problème est vraiment là: je respecte le travail du WHATWG mais ça ne va pas aider à l'adoption du xhtml. Déjà qu'il n' a jamais eu beaucoup de succès, malgré qu'il existe depuis relativement longtemps (à cause d'internet explorer en partie sans vouloir troller).
  
  En plus, pour l'instant, la plupart des sites codés en xhtml sont envoyés avec un type mime text/html. Autrement dit, dans ce cas là, on ne fait pas du vrai xml et envoyer du xhtml avec ce type mime ou du html 4, ça revient au même. Pour la plupart des sites, le xhtml ne sert à rien, car il n'apporte aucune fonctionnalité nouvelles, mis à part le fait d'être vraiment du xml, mais dans cas, on envoie un type mime application/xhtml+xml si je me souvient bien, et alors internet explorer n'affiche tout simplement pas la page.
  
  Moi je l'utilise pour incorporer du mathml, mais peu de gens ont choisi cette solution (encore une fois problème dans les navigateurs), wikipedia par exemple utilise des images pour les formules.
  
  En plus, les retards et les critique du xhtml 2 n'ont par arrangé la situation. Reste que je viens de lire que le WHATWG parle aussi d'un xhtml 5 (genre html 5 mais avec une syntaxe xml) mais je ne sais pas ce que ça va donner. Tout ça reste un peu flou...
  - [^]Re: balise canvas et XHTML
    
    Posté par Aurélien Croc (page perso, ) le 13/04/2007 à 09:43. (lien). Évalué à 5.
    HTML 5, HTML 6, XHTML 2, XHTML 5 ...
    Au moins on n'est pas prêt d'avoir un web "standardisé". Ça semble quand même un peu du déjà vu : chacun fait ses trucs à sa sauce dans son coin...
    Plutôt que de jouer à ça, ils feraient mieux de bosser sur le XHTML 2 et le CSS 3 surtout ! (Car lui non plus, on n'est pas prêt de le voir à moins peut-être en 2015..)
    
    Soit dit en passant, si tu as un compte sur Wikipedia, tu peux décider d'afficher les formules en MathML.. Malheureusement pour les utilisateurs de khtml, c'est pas encore ça..
    - [^]Re: balise canvas et XHTML
      
      Posté par Christophe Roland (page perso, ) le 13/04/2007 à 10:00. (lien). Évalué à 1.
      
      Soit dit en passant, si tu as un compte sur Wikipedia, tu peux décider d'afficher les formules en MathML..
      
      ça ne marche pas... et je ne suis pas le seul dans le cas. A mon avis c'est pas encore implémenté.
    - [^]Re: balise canvas et XHTML
      
      Posté par Laurent J (page perso, ) le 13/04/2007 à 19:59. (lien). Évalué à 2.
      >chacun fait ses trucs à sa sauce dans son coin...
      
      ah eumh.. Tu es sûr d'avoir bien lu la news ?
      
      Apple, Opera et Mozilla ont travaillé ensemble au WHATWG pour élaborer un HTML5, et tu appelles ça "chacun fait ses trucs à sa sauce dans son coin" ? Dis moi, peux tu me citer d'autres "grands" éditeurs de navigateurs web, à part Microsoft ?
      
      Quant à XHTML 2, lit la spec, et tu verras que ça n'a plus vraiment grand chose à voir avec XHTML 1 et HTML. C'est un langage mort né parce qu'aucun grand éditeur ne participe activement à son élaboration.
      
      Par contre, à propos de CSS3, c'est vrai qu'il faudrait que le working group au w3c se bouge un peu plus. Mais bon, ça avance, ça avance :-)
      - [^]Re: balise canvas et XHTML
        
        Posté par lezardbreton (Jabber id, page perso, ) le 14/04/2007 à 07:31. (lien). Évalué à 3.
        Dis moi, peux tu me citer d'autres "grands" éditeurs de navigateurs web, à part Microsoft ?
        
        KHTML + tous les possibles futurs arrivant qui vont s'y retrouver encore moins. Et non KHTML != Webkit.
        
        [^]Re: balise canvas et XHTML
        
        Posté par Laurent J (page perso, ) le 14/04/2007 à 09:44. (lien). Évalué à 2.
        je vois mal KHTML ne pas suivre le chemin de webkit. Ils (KHTML et les autres) ont tout à y gagner d'implémenter ce que propose Apple/Mozilla/Opera.
- [^]Re: balise canvas et XHTML
  
  Posté par Nelis (page perso, ) le 13/04/2007 à 09:35. (lien). Évalué à 5.
  Je me pose la même question que toi, pourquoi continuer le HTML alors qu'il y a le XHTML ? D'autant que n'importe quel parseur XML peut-être utilisé pour lire le XHTML alors que pour le HTML ...
  
  --
  Vache qui rit, à moitié dans son lit
  - [^]Re: balise canvas et XHTML
    
    Posté par Laurent J (page perso, ) le 13/04/2007 à 20:07. (lien). Évalué à 2.
    Et pourquoi pas continuer HTML ? Et pourquoi pas transposer l'ensemble des balises et attributs HTML dans un XHTML 5 comme le propose le WHATWG ?
    - [^]Re: balise canvas et XHTML
      
      Posté par ptifeth () le 17/04/2007 à 05:45. (lien). Évalué à 3.
      Parce que html est une soupe de balises dont la syntaxe de base dépend des balises et que xml amène comme dit plus haut la possibilité d'utiliser des outils variés, pas seulement des navigateurs.
      CSS devrait passer au xml aussi, non ? Alors c'est sûr, ça sera un peu plus pénible à utiliser avec un éditeur de type 'nano', mais tellement plus facile avec un éditeur xml...
      - [^]Re: balise canvas et XHTML
        
        Posté par Laurent J (page perso, ) le 17/04/2007 à 11:29. (lien). Évalué à 2.
        > Parce que html est une soupe de balises
        
        Je te ferais remarquer que la grammaire du XHTML est à l'identique de ce qu'on trouve dans HTML.
        
        On appel soupe de balise une mauvaise utilisation du langage (genre 15 tableaux imbriqués pour afficher trois cadres).
        
        >CSS devrait passer au xml aussi, non ?
        
        CSS n'a pas été conçu que pour HTML, mais aussi pour XML. Ça fait donc longtemps que tu peux utiliser css avec du xml. Tu peux trés bien ouvrir un document xml dans un navigateur, lié à une feuille de style CSS via une processing instruction xml-stylesheet.
        
        >Alors c'est sûr, ça sera un peu plus pénible à utiliser avec un éditeur de type 'nano', mais tellement plus facile avec un éditeur xml...
        
        je vois absolument pas le rapport. Je vois pas par exemple en quoi Nvu est compliqué à utiliser (où l'utilisateur ne voit pas une seule balise à l'horizon, et où il peut styler en CSS sans qu'il le sache pratiquement). Et on fait pareil avec XML dans Etna (éditeur XML wysiwyg).

Apple, Opera et Mozilla

Posté par Ducerf Gaël (page perso, ) le 13/04/2007 à 09:13. (lien). Évalué à 1.

C'est quoi le rapport avec Apple, Opera et Mozilla ?

[^]Re: Apple, Opera et Mozilla

Posté par DPhil (page perso, ) le 13/04/2007 à 09:16. (lien). Évalué à 2.
Ce sont eux qui ont demandé au W3C de réintégrer le travail:
http://lists.w3.org/Archives/Public/public-html/2007Apr/0429(...)

[^]Re: Apple, Opera et Mozilla

Posté par Christophe Roland (page perso, ) le 13/04/2007 à 09:17. (lien). Évalué à 4.
Ce sont les trois plus gros contributeurs au WHATWG, le groupe qui a développé html 5.

[^]Re: Apple, Opera et Mozilla

Posté par mats (page perso, ) le 13/04/2007 à 09:21. (lien). Évalué à 1.
lire par exemple ce courriel :
http://lists.w3.org/Archives/Public/public-html/2007Apr/0429(...)

Pour les flemmards, voici la signature :
L. David Baron, Mozilla Foundation
Lars Erik Bolstad, Opera Software ASA
Brendan Eich, Mozilla Foundation
Dave Hyatt, Apple Inc.
Håkon Wium Lie, Opera Software ASA
Maciej Stachowiak, Apple Inc.

XHTML-ng 7.2.5 rev6 compliant

Posté par Thenomor () le 13/04/2007 à 09:31. (lien). Évalué à 5.

Tu va voir qu'un jour il va falloir être être sorti d'une école d'ingénieur pour faire son site web!

Arrêtons un peu de complexifier l'informatique et laissons les geeks du dimanche faire leurs bidouilles!
Tiens ca me rappelle un article que j'avai vu sur u-zine il y a quelques temps déjà ( http://www.uzine.net/article2143.html )

Fut un temps où internet appartenait au peuple, même si les sites étaient laids et anti-ergonomiques.... Ne laissons pas internet devenir une galerie marchande technocrate !!

Bon ce soir, je prends des vacances, ca me fera du bien...

[^]Re: XHTML-ng 7.2.5 rev6 compliant

Posté par Bruce Le Nain (Jabber id, page perso, ) le 13/04/2007 à 11:57. (lien). Évalué à 4.
Je croyais en plus que le xhtml était principalement une manière de présenter son code proprement, pour que l'interprétation soit plus facile quelle que soit le navigateur.

--
Hôdo
Livingstone

[^]Re: XHTML-ng 7.2.5 rev6 compliant : réjouissons nous...

Posté par André Rodier (page perso, ) le 13/04/2007 à 12:45. (lien). Évalué à 8.
J'ai plussé parce que je trouve l'article intéressant, mais il décrit trop les faits et pas assez la cause.
La stagnation du (X)HTML et du web en général est amha plus due à des causes stratégiques que techniques.

Microsoft a longtemps détenu le monopole des navigateurs. Et le code HTML reconnu par Internet Explorer est devenu un standard ipso facto.

Que ce serait-t-il passé si MS avait implémenté les normes du xhtml : ( Svg, MathML, extensibilité, etc...), dans son moteurs de rendu ?
Les webmestres auraient suivi (avec plaisir), et le moteur gecko aurait été obligé d'implémenter ces normes assez rapidement pour ne pas devenir obsolète.

Microsoft n'a pas fait évoluer son moteur de rendu trident pendant plus de 5 ans. Peut être pour des raisons stratégiques, puisque son chiffre d'affaires provient essentiellement de la vente de logiciels clients. Cette société n'a donc pas d'intérêt à voir se multiplier des applications décentralisées accessibles via un standard non breveté...

Le WHATWG, commence à avoir un poids non négligeable dans la part d'utilisation des navigateurs internet. Il fait donc simplement le travail que Microsoft aurait du faire depuis longtemps : implémenter des technologies et les proposer en standard. N'oublions pas que Microsoft est une membre officiel, et sans doute influent ($$$) du w3c.

Quand des sociétés, plus ou moins concurrentes, enterrent la hache de guerre pour le bien du consommateur, nous ne pouvons qu'applaudir. Temporairement...

[^]Re: XHTML-ng 7.2.5 rev6 compliant

Posté par Moonz () le 13/04/2007 à 13:11. (lien). Évalué à 0.
Merci pour ce moment de rigolade :)
HTML plus simple que XHTML... Faudra que je la ressorte celle là :)
- [^]Re: XHTML-ng 7.2.5 rev6 compliant
  
  Posté par rewind () le 13/04/2007 à 14:09. (lien). Évalué à 10.
  Moi j'ai rigolé sur "Arrêtons un peu de complexifier l'informatique". Quand on voit les pirouettes dans le code d'un navigateur qui servent à gérer la bouillie de balises pas fermées, alors qu'il serait tellement plus simple de dire aux gens : fermez vos balises, c'est pas dur et ça sauve les bébés phoques !

[^]Re: XHTML-ng 7.2.5 rev6 compliant

Posté par Guillaume Rossignol () le 14/04/2007 à 11:09. (lien). Évalué à 3.

Fut un temps où internet appartenait au peuple, même si les sites étaient laids et anti-ergonomiques.... Ne laissons pas internet devenir une galerie marchande technocrate !!

Aujourd'hui, quelqu'un qui souhaite faire un site il s'oriente vers des CMS style spip ou un moteur de blog comme Dotclear, et tout se qu'il a à faire, c'est lire le manuel et remplir les champs. Et donc le peuple en a rien à secouer des normes.

De plus, les anciennes normes sont toujours supportés, les nouvelles permettent d'apporter de nouvelles fonctionnalitées, d'assurer un rendu etc. libre a chacun d'utiliser une norme encore plus limitative que ce qui pourrait se faire.

utilité ?

Posté par Troy McClure (page perso, ) le 13/04/2007 à 14:50. (lien). Évalué à 4.

A quoi ça sert le html 5 et le html 6 ? à part rendre les navigateurs toujours plus complexes lourds et buggés ? pourquoi ne pas continuer sur la voie du xhtml puisque c'est censé etre le successeur ? ça me semble tellement débile de vouloir pousser le html 5 que quelque chose doit m'échapper ...

[^]Re: utilité ?

Posté par Metzgermeister () le 13/04/2007 à 17:04. (lien). Évalué à 4.
Parce que le HTML reste un standard et un langage historique : il existe des millions de pages web écrites avec ce langage et ses balises, et la transition n'est pas forcément facile. Dans le cas du XHTML, ça marche assez peu, parce que le XHTML 1 est une "simple réécriture" de l'HTML 4.01 au format XML. Et puis, l'utilisation de l'XHTML demande aussi peut-être plus de rigueur.

Pour ma part, j'attends surtout l'XHTML 2 qui semble devenir encore plus un langage de structuration des informations, avec la suppression de certaines balises de mise en forme avec en parrallèle le CSS 3 qui va encore plus être le langage de mise en forme de ces informations. Bref, une belle séparation des usages, et ceci ne peut être qu'un avantage pour les sites web !

Il est certes un peu regrettable que le W3C mette en place un tel groupe de travail, ce qui risque de faire ralentir le processus de mise en norme de l'XHTML 2.

[^]Re: utilité ?

Posté par Laurent J (page perso, ) le 13/04/2007 à 17:29. (lien). Évalué à 4.
as tu regardé ce que proposait HTML 5 ? Et est ce que tu fais du dev web ?

Tout ce que propose le WHATWG :

- il y a déjà une partie qui sont déjà en cours de normalisation au w3c (XBL2, xmlhttprequest &cie)
- dans le HTML5, il y a des choses qui simplifient la vie du developpeurs. Faut voir le nombre de ligne de code qu'il faut actuellement pondre pour faire des sites web ajax qui bougent dans tous les sens. C'est tout bonnement horrible. Alors que dans HTML5, il y a des balises et attributs qui simplifient énormément de choses et qui nécessitent moins de code à écrire.

Et il faut savoir que des trucs de HTML5 (mais pas tout) sont en cours d'intégration dans Firefox 3.

Enfin, XHTML n'a jamais été qu'une simple reformulation de HTML en XML : il n'y a rien de plus, rien de moins en XHTML par rapport à HTML ! Mêmes balises, mêmes attributs.

HTML 4.1 strict = XHTML 1.0 strict
HTML 4.1 transitionnal = XHTML 1.0 transitionnal

Et je suppose, que ce qu'on aura en HTML, sera dispo aussi en XHTML (dans firefox). Donc bref...

(y a même des trucs de HTML5 en cours d'intégration dans Firefox 3, qui seront aussi dispo directement dans XUL...)
- [^]Re: utilité ?
  
  Posté par Metzgermeister () le 13/04/2007 à 18:00. (lien). Évalué à 1.
  Tu noteras que je ne me suis pas prononcé sur l'HTML 5, je ne pense pas en savoir assez pour pouvoir parler dessus. :-)
  
  Toutefois, je suis plutôt content de voir que le projet XHTML 2 n'est pas annulé.
  - [^]Re: utilité ?
    
    Posté par Laurent J (page perso, ) le 13/04/2007 à 19:54. (lien). Évalué à 2.
    Oh là ! Attention ! je ne parle pas de XHTML 2 !
    
    XHTML 2 n'a strictement rien à voir avec ce que je raconte. Moi je parle d'un XHTML 1++ (non standard).
    
    XHTML 2 fait table rase sur HTML/XTHML. C'est un tout autre langage. Il est mort né pour moi... (y a qu'à voir le working group XHTML2 : aucun des grands acteurs coté navigateur y participe activement, même si le nom de certains, comme Microsoft y sont inscrit).
    - [^]Re: utilité ?
      
      Posté par bichenoubi () le 13/04/2007 à 23:09. (lien). Évalué à 2.
      Je dois pas connaître ce que c'est vraiment xhtml2. Mais en regardant là
      http://www.w3.org/TR/xhtml2/xhtml2-doctype.html#s_doctype
      j'y retrouve la quasi totalité des balises que je connais.
      En quoi alors c'est si différent de coder xhtml2 qu'en xhtml1
      
      HTML5 me semble plus une excuse pour ne pas avoir à se forcer à implenter une gestion stricte d'un vrai xhtml. Une façon de garder les navigateurs tels qu'il sont en sans trop d'efforts et en ajoutant seulement des fonctions joujou.
      
      Et dire que HTML5 est plus "démocratique" que XHTML c'est une farce. Personne de M. Toutlemonde veut vraiment aller jouer dans le code que ça soit un ou l'autre. Ils sont tous les deux aussi confondant. En autant qu'un logiciel tel que Dreamweaver implémente correctement xhtml2, il n'y aura aucun problème.
      - [^]Re: utilité ?
        
        Posté par Laurent J (page perso, ) le 14/04/2007 à 05:46. (lien). Évalué à 2.
        >j'y retrouve la quasi totalité des balises que je connais.
        
        Tu as quand même pas mal de nouvelle balises. Et lire une liste de balise ne suffit pas ;-) Il faut voir par exemple les conséquences des balises section, l ou h (au niveau css par ex)
        
        >Et dire que HTML5 est plus "démocratique" que XHTML c'est une farce
        
        Compte le nombre de site en HTML. Compte ceux en XHTML (valide). Les premiers sont une écrasante majorité quand même..
      - [^]Re: utilité ?
        
        Posté par Laurent J (page perso, ) le 14/04/2007 à 06:27. (lien). Évalué à 2.
        > HTML5 me semble plus une excuse pour ne pas avoir à se forcer à implenter une gestion stricte d'un vrai xhtml.
        
        à noter qu'un XHTML 5, la version XML de HTML5 est prévu hein..
        
        http://www.whatwg.org/specs/web-apps/current-work/#html-vs
        
        [^]Re: utilité ?
        
        Posté par Metzgermeister () le 14/04/2007 à 14:35. (lien). Évalué à 0.
        Ça me semble assez utopique de penser qu'il puisse exister un HTML5 et un XHTML5. Finalement, l'une des deux va disparaître, au profit de l'autre (ou en tout cas, l'une ne sera pas utilisée, l'autre si).
        
        [^]Re: utilité ?
        
        Posté par Laurent J (page perso, ) le 14/04/2007 à 19:32. (lien). Évalué à 2.
        Ce n'est pas utopique du tout.
        
        Ceux pour qui la syntaxe HTML suffit, ils feront leurs pages en HTML5. Et pour ceux qui voudront mélanger ce que propose html5 avec d'autres langages XML (genre, intégrer du MATHML, du SVG etc), ils utiliseront le XHTML5.
        
        HTML5 et XHTML5, c'est le même langage, ce sont juste des syntaxes différentes (l'une SGML, l'autre XML). Je ne vois pas en quoi l'un des deux va disparaitre, vu qu'ils reposent sur les mêmes spécifications, proposent les mêmes balises et attributs.
        
        C'est finalement comme XHTML1 et HTML4 : ils proposent les mêmes balises, les mêmes attributs. Bref, c'est le même langage, mais une syntaxe différente. Pour rappel : http://openweb.eu.org/articles/differentes_dtd/
- [^]Re: utilité ?
  
  Posté par Moonz () le 15/04/2007 à 09:50. (lien). Évalué à 2.
  Je dois avouer que j'ai la flemme de lire les specs de HTML 5, alors puisque j'ai quelqu'un qui les a lues sous la main, j'en profite ;)
  
  Y a t'il dans HTML5 des "client-side includes", c'est à dire un truc du genre
  <include src="foo.xml" />, qui remplace la balise include dans l'arbre DOM par l'arbre DOM de foo.xml (éventuellement sans la balise racine) ?
  En fait, je pense que ça devrait plutôt être ajouté comme fils de include dans l'arbre DOM, pour pouvoir en plus jouer avec avec Javascript...
  Je suis sûr qu'il y a moyen de faire des trucs sympas avec ça :p. C'est d'ailleurs quelque chose qu'on peut faire avec "AJAX" me semble t'il, mais on perd dans ce cas la compatibilité avec les navigateurs non javascript...
  - [^]Re: utilité ?
    
    Posté par Juke (Jabber id, page perso, ) le 16/04/2007 à 05:55. (lien). Évalué à 3.
    >mais on perd dans ce cas la compatibilité avec les navigateurs non javascript
    
    Je suis d'accord avec toi mais pense tu qu'il y aura bcp de navigateur HTML5 non JS ?
    - [^]Re: utilité ?
      
      Posté par Moonz () le 16/04/2007 à 21:09. (lien). Évalué à 2.
      Un Firefox avec noscript ?
      Et puis si HTML 5 n'est qu'une évolution d'HTML 4, qu'est-ce qui empèchent links, lynx, ou dillo de l'implémenter ?

[^]Re: utilité ?

Posté par Samaty Tramo (page perso, ) le 14/04/2007 à 15:23. (lien). Évalué à 5.
Parfois je me demande si le Xhtml 1 c'était appelé Html 5 si cela n'aurait pas obligé Kro à le mettre histoire de suivre et de ne pas devenir obsolète. Et je me demande si c'est pas cela le plan d'Opera, Mozilla, etc ...

- Opera : Genre, votre société n'a pas de soft qui comprennent le html 5 ?
- Entreprise : Non nous, on est resté avec iexplorer et le html 4.
- Opera : On pouvais comprendre que sauter de technologie avec le Xhtml pouvais faire peur. Mais là c'est la continuité.
- Entreprise : A oui, merde, faut suivre sur ce coup là.

Enfin, c'est peu-être mes espoir, les voir bouger :). Même si je pense qu'il n'y avait aucun saut technologique entre le html4.1 et le Xhtml 1. Pas plus que du html 3.2 au 4.0.

En même temps je comprends le w3c qui voulait une nouvelle dynamique (que j'aime) avec le xhtml,xform,svg,mathml que kro a plombé. Mais visiblement, une approche xhtml5 / html 5 pourrait gagné là ou une approche xhtml 1 / html 4 n'a pas complètement réussie commercialement.

En même temps quand on regarde ipv6 qui a pourtant 2 chiffres de plus que ipv4. De toute façon, il était temps de tenter quelque chose.

XHTML 5

Posté par Infernal Quack (Jabber id, page perso, ) le 13/04/2007 à 17:28. (lien). Évalué à 2.

J'espère qu'ils vont penser à faire un XHTML 5 car le XHTML n'est qu'une XMLisation du HTML et donc je ne vois pas la difficulté.

Je souhaiterais même la mort du HTML, un des seuls formats informatiques batards où la gestion d'erreur n'est pas dans les spécifications mais où les erreurs son hautement permises ce qui implique que la majorité du code des navigateurs est là pour deviné ce qu'à voulu faire le créateur du site-web (Bon, je mets tous en italique ou juste la paragraphe ?).

[^]Re: XHTML 5

Posté par Laurent J (page perso, ) le 13/04/2007 à 17:33. (lien). Évalué à 4.
De ce que je vois dans FF3, il me semble en tout cas que ce qui est dispo au niveau HTML l'est aussi au niveau HTML5 (si mes souvenirs sont bons, il n'y a que le parser qui change dans Firefox entre HTML et XHTML, et les noeuds DOM crées dans les deux cas sont les mêmes objets C++).

Il y a aussi des différences, mais essentiellement au niveau du modèle de boite CSS. (par exemple, en HTML, la balise body , n'est pas une boite, alors que XHTML, elle l'est).

[+] [^]Re: XHTML 5

Posté par vladislav askiparek () le 13/04/2007 à 18:32. (lien). Évalué à -1.
"où la gestion d'erreur n'est pas dans les spécifications mais où les erreurs son hautement permises ce qui implique que la majorité du code des navigateurs est là pour deviné ce qu'à voulu faire le créateur du site-web"

ben oui, je ne vois pas pourquoi je devrais être un super webmaster agréé bac+5 et tuticuanti pour pouvoir mettre les photos de mes enfants en ligne. Le web doit rester accessible à tout le monde, codeurs ou pas codeurs.

Un navigateur doit rester un interpréteur et non pas devenir un compilateur qui n'admet aucune erreur. Si c'était le cas, nous aurions sans aucuns doutes moins de problèmes pour accéder à certains sites réservé au fameux Internet Explorer®.

Avec mon dernier Pentium® à 8000GHz, je pense que mon PC est capable de compter les balises et de savoir s'il en manque une ou pas. Et cela sans devoir utiliser une usine à gaz comme navigateur.
- [^]Re: XHTML 5
  
  Posté par Christophe Roland (page perso, ) le 13/04/2007 à 19:26. (lien). Évalué à 4.
  Mais enfin, pourquoi tout le monde dit que le xhtml c'est dur? Juste parce qu'on est obligé de fermer les balises?
  
  Il faut dédiaboliser le xhtml, c'est vraiment pas dur à faire et en fait c'est pas plus dur que le html (ou à peine)!
  
  D'ailleurs pour faire du xhtml même stricte, il suffit de savoir utiliser nvu. Et pas besoin d'être bac+5 pour ça. Le webmaster amateur n'écrit pas le code source à la main...
- [^]Re: XHTML 5
  
  Posté par Laurent J (page perso, ) le 13/04/2007 à 20:05. (lien). Évalué à 3.
  > ben oui, je ne vois pas pourquoi je devrais être un super webmaster agréé bac+5 et tuticuanti pour pouvoir mettre les photos de mes enfants en ligne
  
  Excuse moi, mais un utilisateur lambda n'a pas à coder une page html : il utilise les outils à sa disposition (nvu, dreamweaver, ou même mieux, un soft de gestion de gallerie de photos en php ou autre).
  
  Dans openoffice, tu tapes les balises xml opendocument ? non, j'en suis sûr.
  
  Je vois pas en quoi c'est génant d'avoir un langage un peu plus complexe. L'objectif de l'informatique, c'est pas coder. C'est utiliser. C'est aux outils de cacher toute la complexité d'un système, d'un langage.
  - [^]Re: XHTML 5
    
    Posté par _p4_ () le 14/04/2007 à 10:06. (lien). Évalué à 1.
    
    un utilisateur lambda n'a pas à coder une page html
    
    Aujourd'hui oui. Au siècle dernier, disons avant phpNuke, inventeur du cms, les gens devaient plus ou moins coder leur page à la main ou avec des éditeurs offline. Ajourd'hui avec les outils de publication directement online genre blogs et autres web services 2 cela n'est plus nécessaire.
    
    Rendons hommage au html à la papa: un language de balisage pas propre, pas xml-compliant, mais qui a fait beaucoup pour le web. Le coté permissif et bordélique du html 3.2 a permis son essort: l'information est toujours accessible, même mal encodée. En ce qui concerne le web je trouve que c'est un bon principe. C'est vrai que xhtml apporte des choses bien: meilleure accessibilité et compatibilité xml essentiellement. Je l'utilise aujourd'hui pour ses avantages et aussi un peu pour le principe tout en déplorant parfois son coté plus exigeant. Parfois je me prendrai presque à regretter le bon vieux temps où le monde était dominé par Netscape 3...
    - [^]Re: XHTML 5
      
      Posté par Moonz () le 15/04/2007 à 09:41. (lien). Évalué à 4.
      > Rendons hommage au html à la papa: un language de balisage pas propre, mais qui a fait beaucoup pour le web
      Il a quand même fait la première guerre des navigateurs et est selon moi une des principale cause de ce que certains appellent "la nouvelle guerre des navigateurs". Si pour toi ça c'est faire beaucoup pour le web...
      
      > Le coté permissif et bordélique du html 3.2 a permis son essort: l'information est toujours accessible, même mal encodée
      Ce qui a permis l'essort du C, c'est son côté accessible partout: pour peu que tu fasses pas d'hypothèses trop osées, ça marche sur à peu près toutes les plateformes matérielles. Pourtant, mal encodé, le C passe pas.
      Tu vas le dire, oui, mais le C, c'est un truc de bidouilleurs.
      Ben oui, mais tu sait, l'époque du HTML 3.2, c'était pas Windows XPVista Noob Powered (c) ou KDE hein... Les noob de l'époque, ils faisaient du Basic aussi. Et ben figure toi que le basic n'est pas le langage le plus permissif au monde...
      Aujourd'hui, les noob, c'est NVU.
      Tu nous dit que parce que les noobs d'avants arrivaient facilement à faire du HTML et que les noob d'aujourd'hui n'arrivent pas à faire du XHTML, c'est la preuve que le XHTML est plus complexe. Non, c'est parce que le niveau des noobs a baissé (et avant que ça parte en troll, oui, c'est triste, et non, ce n'est pas un commentaire méprisant. J'ai moi même été un noob, et un moins bon noob que ceux qui débutaient avec les cartes perforées... Les noobs de l'époque des PDPs étaient certainement meilleurs que moi aujourd'hui...)
      
      > tout en déplorant parfois son coté plus exigeant.
      Et moi, je déplore le côté laxiste du HTML. Quand tu passes deux heures à débugger ton code javascript (pas un truc de 5000 lignes de code hein) alors que le problème se situait dans une malheureuse faute de frappe dans le code HTML (alors qu'en XHTML, le navigateur m'aurait tout de suite signalé l'erreur), c'est clairement qu'il y a un problème avec le HTML, non ?
      
      > Parfois je me prendrai presque à regretter le bon vieux temps où le monde était dominé par Netscape 3...
      Réactionnaire ;)
- [^]Re: XHTML 5
  
  Posté par vieuxmk () le 13/04/2007 à 20:07. (lien). Évalué à 7.
  
  ben oui, je ne vois pas pourquoi je devrais être un super webmaster agréé bac+5 et tuticuanti pour pouvoir mettre les photos de mes enfants en ligne
  
  Heu, monsieur lambda qui veut mettre des photos en lignes tape son HTML dans notepad O_O ? Et quand bien même il le ferait, en quoi ça demande un Bac + 5 de fermer ses balises ?
  
  Un navigateur doit rester un interpréteur et non pas devenir un compilateur qui n'admet aucune erreur.
  
  Ahem, ton interprète Python admet les erreurs de syntaxe dans ton code source ? Étrange.
  
  Si c'était le cas, nous aurions sans aucuns doutes moins de problèmes pour accéder à certains sites réservé au fameux Internet Explorer®.
  
  Bien sur, une norme peu stricte et laissant à chacun carte blanche pour interpréter les erreurs rend plus facile l'écriture de HTML portable sur tous les navigateurs, ça semble logique.
  
  Avec mon dernier Pentium® à 8000GHz, je pense que mon PC est capable de compter les balises et de savoir s'il en manque une ou pas.
  
  Le monsieur te dit pas qu'autoriser les erreurs c'est mal, mais que le faire et ne pas spécifier DANS UNE NORME comment les gérer et laisser chacun faire sa tambouille incompatible c'est compliquer la vie de tout le monde, dev. webs en première ligne.
  
  Je vois pas comment tu peux prôner à la fois la simplicité supposée du HTML et un mode de fonctionnement de la norme ou il est nécessaire de connaître les arcanes de chaque navigateur...
- [^]Re: XHTML 5
  
  Posté par Moonz () le 13/04/2007 à 20:12. (lien). Évalué à 10.
  Marre de ces discours à la CON. Demander de respecter la syntaxe XML n'est PAS élististe, ne demnde pas d'être BAC +5 et est accessible tous. Je vois même pas comment on peut penser le contraire tellement c'est absurde
  -> Quelqu'un qui a fait un site avec les photos de famille avec le bloc note possède assez d'intelligence et de capacités pour fermer une balise, non ? à moins que tu penses qu'écrire <p>Michèle</p> est infiniment plus complexe intellectuellement qu'écrire <p>Michèle, mais dans ce cas, je pense qu'il y a sérieusement quelque chose qui va pas chez toi...
  -> Quelqu'un qui n'a de toutes façon pas les capacités (ou la volonté aussi, ça se comprend très bien) de fermer une balise n'a pas les capacités de l'ouvrir non plus. Pour lui, il y a NVU (et ce n'est pas une critique élitise du type "NVU pour le bas peuple")
  
  J'irais même plus loin, un navigateur tolérant est quelque chose d'infiniment plus compliqué. Prenons un exemple tout con:
  <script></srcipt>
  Avec ta super politique "soyons tolérant", qu'est-ce que tu crois qu'il va arriver ? Ben la page sera toute blanche, le type se demandera (parfaitement légitimement) pourquoi, ne comprendra (toujours aussi légitimement) pas, et se dira (et il aura raison) "c'est trop compliqué". Éventuellement, il demandera de l'aide sur un forum, et s'il a de la chance, quelqu'un verra la faute de frappe et dira "tu n'as qu'à le faire en XHTML, l'erreur te sautera aux yeux". Et hop, un aigri anti-XHTML en plus. Quels connards d'élitistes ces pro-XHTML.
- [^]Re: XHTML 5
  
  Posté par Erwan (page perso, ) le 14/04/2007 à 00:18. (lien). Évalué à 2.
  ben oui, je ne vois pas pourquoi je devrais être un super webmaster agréé bac+5 et tuticuanti pour pouvoir mettre les photos de mes enfants en ligne.
  
  Flickr ? Webshots ? iPhoto+iWeb ? Picasa ? VOX ?

X/HTML5 Versus XHTML2

Posté par dragoonway (page perso, ) le 13/04/2007 à 22:03. (lien). Évalué à 4.

Pour ceux que ça intéresse, voici un article efficace en francais sur les tenants et aboutissants des 2 challengers en présence :
http://xhtml.com/fr/future/x-html-5-versus-xhtml-2/

--
o--weed-is-communism--o

[^]Re: X/HTML5 Versus XHTML2

Posté par bichenoubi () le 13/04/2007 à 23:55. (lien). Évalué à 1.
Très intéressant, ça confirme ma préférence pour xhtml2.

Je me demande si quelqu'un serait capable de faire avec le même ratio d'objectivité/subjectivité la réflexion inverse en favorisant html5.

Je trouve domage que Mozilla et Opera qui sont deux navigateurs à suivres les normes du web jouent au Microsoft de 1998.
- [^]Re: X/HTML5 Versus XHTML2
  
  Posté par Laurent J (page perso, ) le 14/04/2007 à 06:17. (lien). Évalué à 5.
  ouai, forcément, avec un argumentaire aussi pauvre à propos de html 5 dans cet article....
  
  Le type a oublié 95% des nouveautés de (x)HTML5. Il n'a pas du lire vraiment la spec. http://www.whatwg.org/specs/web-apps/current-work/
  
  Il ne parle pas par exemple des élements audio, video, meter, progress, figure, canvas, source, datagrid, command, menu : tout plein de truc pour développer des applis web modernes sans avoir à pondre des centaines de lignes de code javascript.
  
  Et il ne faut pas oublier non plus la partie javascript, avec les objets Storage (déjà implémenté dans FF2), le drag and drop (déjà en partie dans le trunk de Firefox 3), l'aspect offline (déjà dans le trunk Firefox 3) etc...
  
  Bref, XHTML2 fait totalement l'impasse sur tout ça, qui sont pourtant nécessaires de nos jours !
  
  Et je ne parle pas des formulaires. Là où HTML5 rajoute quelques attributs qui apportent la puissance nécessaire et comblent les manques actuels, XHTML2 propose tout bonnement d'utiliser XForms. La bonne blague, quand on connait la complexité de XForms ! Xforms, c'est trés bien pour des formulaires complexes, mais c'est overkill pour la majorité des formulaires web.
  
  Le gros avantage de HTML5, est qu'il se base sur quelque chose d'existant, tandis que XHTML2 pas beaucoup. C'est donc plus facile pour les développeurs : ils peuvent passer "en douceur" de HTML4 à HTML 5. Et les pages HTML5 se dégraderont mieux dans un navigateur qui ne le supporte pas que XHTML2 (on sait tous le problème du content-type du xhtml 1.1, qui n'est pas reconnu par IE, donc chez 80% des utilisateurs, alors imaginez le problème d'un nouveau langage XHTML2 pas vraiment compatible avec les autres...).
  
  C'est aussi plus facile pour les éditeurs de navigateurs pour implémenter (x)HTML5 plutôt que XHTML2. Ils n'ont pas à tout recoder, mais juste à rajouter des choses. Et pas la peine de me signaler qu'il y a beaucoup de balises en commun dans XHTML2 avec XHTML1 : les specs sont différentes, donc faut réécrire une bonne partie du truc. Par exemple, le fait qu'on puisse mettre un href (donc des liens) sur toutes les balises, n'est vraiment pas anodin en terme d'implémentation et de reprise de code de xhtml1.
  
  >Je trouve domage que Mozilla et Opera qui sont deux navigateurs à suivres les normes du web jouent au Microsoft de 1998.
  
  Comme je disais dans un autre commentaire, Mozilla, Opera et Apple sont les principaux éditeurs de navigateurs. L'autre grand acteur, c'est Microsoft. Bref, franchement, ce que font Mozilla, Opera et Apple n'est franchement pas comparable avec ce que faisait Microsoft et Netscape dans leur coin dans les années 90. là on a 3 acteurs majeurs qui marchent main dans la main ! si MS n'a pas voulu suivre le WHATWG, c'est quand même pas le probleme des autres ! Je dirais me que c'est le contraire : Microsoft, avec son WPF et autre XAML, et à ne pas suivre le W3C ou le WHATWG, continuent à faire cavalier seul !
- [^]Re: X/HTML5 Versus XHTML2
  
  Posté par bichenoubi () le 16/04/2007 à 04:34. (lien). Évalué à 1.
  Je me répond à moi-même ayant trouvé cet article éclairant.
  
  http://www.digital-web.com/articles/html5_xhtml2_and_the_fut(...)

Ironie

Posté par bichenoubi () le 13/04/2007 à 23:50. (lien). Évalué à 1.

Le comble de l'ironie serait que Microsoft se positionne en faveur du XHTML2.
Je me verrais un peu dérouté de devoir utiliser IE....

[^]Re: Ironie

Posté par Laurent J (page perso, ) le 14/04/2007 à 06:25. (lien). Évalué à 5.
tu n'auras jamais à utiliser IE, pour la bonne raison qu'aucun dev web n'utilisera XHTML2...

Et puis bon, c'est un peu de la vision du future à 2 balles que tu nous dis là :-). IE, le seul navigateur actuelle à ne pas prendre en charge XHTML 1. Et Microsoft qui soutiendrait XHTML 2 à l'avenir ? la bonne blague :-)

Bon sinon rassures-toi : bien qu'il y ait des participants au working group XHTML2 qui viennent de Microsoft, ils n'ont pas dit un seul mot depuis des années.. Bref, l'implication de Microsoft dans XHTML2 est quasi nulle. Et je ne parle pas des autres éditeurs de navigateurs, qui sont aussi totalement absent pour la plupart.

Je ne vois pas comment un langage puisse avoir un avenir, si les principaux intéressés ne contribuent pas à l'élaboration de ses specs. Et si ils ne contribuent pas (que ce soit MS ou les autres), c'est qu'il y a un problème dans XHTML2 n'est ce pas ? ;-)

Pour moi, XHTML2 n'a aucun avenir.

Css3 et marcher sur la tête...

Posté par Raphaël Gertz (page perso, ) le 14/04/2007 à 08:59. (lien). Évalué à 2.

En tout cas ça changera pas grand chose pour moi...

Des choses intéressantes que j'ai retenus :
- href dans toutes les balises (ça serait vraiment un plus dans du xhtml1.1)

Des choses qui manques :
-
(au lieu de fermer bêtement la balise a la xhtml1.1)

Mais surtout c'est au niveau du css que les soucis que j'ai sont les plus grand.

Pour moi il manque un gros :
display: integrated; /* à l'intérieur, ne débordera pas du conteneur */
display: float; /* flotant à l'intérieur, débordera du conteneur */

Parce que float: left; c'est une sacré merde !
(surtout qu'un clear: left; ne va pas prendre en charge l'élément float du conteneur, puis remonter, mais va clear sur toute la page !!!)

D'autre part il serait bon d'avoir enfin un round corner qui marche et standard.
(ou droit a une marge sur les bords par exemple)

Après les derniers vrais manques sont les histoires de soumissions de form en javascript, j'ai toujours pas trouvé comment simplement envoyer un fichier sur un serveur en xmlrpc.

J'entend l'user fait un glisser déposer dans une zone d'un fichier, le javascript génère la form avec le chemin (comment affecter le chemin d'une balise input type=file) et quelques input text a côté, puis soumet tout ça en xmlrpc.

De même qu'un système de progression simple de l'upload...
(mine de rien le navigateur il sait lui le taux d'envoi d'un fichier, ça serait vraiment bien d'avoir ça dans l'arbre dom).

Après pour la sémantique et autre je pense qu'on met la charrue avant les boeufs.
Comprendre on fixe un api avant d'avoir fait un panel des besoins et bonnes pratiques.

Rien que par exemple la section head toujours pas standardisée depuis des années (ça serait bien d'avoir 10-15max champ meta a remplirs optionels mais recommandés)

ps : si vous avez des tutos par l'exemple qui résolvent mes soucis n'hésitez pas (surtout l'histoire de la sémantique, les balises blabla c'est vraiment loin du code xhtml)

--
site perso : http://rapsys.free.fr/

[^]Re: Css3 et marcher sur la tête...

Posté par Laurent J (page perso, ) le 14/04/2007 à 10:00. (lien). Évalué à 2.

Des choses intéressantes que j'ai retenus : - href dans toutes les balises

Je suis pas vraiment de ton avis. Ça risque d'être un super beau bordel surtout si tu as toute une arborescence de balises avec chacune un href... Pour le user, ça va être imbitable.

display: integrated; /* à l'intérieur, ne débordera pas du conteneur */
display: float; /* flotant à l'intérieur, débordera du conteneur */

integrated ? ça veut pas dire grand chose, et surtout ta définition ne permet pas de comprendre ce que tu veux.

Va voir aussi la spec CSS3 qui propose d'autres valeurs pour le display.

surtout qu'un clear: left; ne va pas prendre en charge l'élément float du conteneur, puis remonter, mais va clear sur toute la page !!!)

Là tu énonces un bug de IE je pense... En tout cas chez moi, un clear:left n'a jamais annulé tous les float. Enfin en tout cas je n'ai jamais rencontré le problème. (enfin bon, je ne m'amuse pas non plus à mettre des floats dans tous les sens)

il serait bon d'avoir enfin un round corner qui marche et standard.

c'est prévu dans CSS3, et ça fonctionne dans Firefox 1.0+ ( -moz-border-radius)

Après les derniers vrais manques sont les histoires de soumissions de form en javascript, j'ai toujours pas trouvé comment simplement envoyer un fichier sur un serveur en xmlrpc.

xmlhttprequest ? sinon que ce soit XForms ou les webform en HTML5, ça apporte de nombreuses améliorations à ce niveau. http://ljouanneau.com/blog/2006/08/30/587-web-forms-2 . Et avec XForms, tu peux envoyer les données dans le format que tu veux.

Après pour la sémantique et autre je pense qu'on met la charrue avant les boeufs. Comprendre on fixe un api avant d'avoir fait un panel des besoins et bonnes pratiques.

C'est le but de html5. Regarde la spec et les nouvelles balises qu'il propose avant de critiquer dans le vide.

la section head toujours pas standardisée depuis des années

pardon ? c'est standardisé depuis des années dans HTML et XHTML.. Et standardisé des "metas", ce ne serait pas logique, puisque par définition, les métas est une manière d'enrichir le head selon tes propres besoins.

M'enfin peut être que les microformats pourraient résoudre ton problème.
- [^]Re: Css3 et marcher sur la tête...
  
  Posté par Raphaël Gertz (page perso, ) le 14/04/2007 à 11:47. (lien). Évalué à 2.
  Templeet m'a bouffé un bon commentaire
  « Des choses qui manques :
  - <script src="script.js" />
  (au lieu de fermer bêtement la balise a la html4) »
  
  « Là tu énonces un bug de IE je pense... En tout cas chez moi, un clear:left n'a jamais annulé tous les float. Enfin en tout cas je n'ai jamais rencontré le problème. (enfin bon, je ne m'amuse pas non plus à mettre des floats dans tous les sens) »
  
  Non, pas vraiment.
  
  Tu ne semble pas comprendre mon dilemme.
  
  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
  <head>
  <title>test</title>
  </head>
  <body>
  <div style="float: left; width: 150px;">
  <div>menu 1</div>
  <div>menu 2</div>
  <div>menu 3</div>
  <div>menu 4</div>
  <div>menu 5</div>
  </div>
  <div style="margin-left: 150px">
  <div class="article" style="background: yellow">
  <div style="float: left;">
  <img src="upload/a998ed9f82ebe961b2f923cd6cbd28e1_reload.png" alt="blabla" style="display: block" />
  description
  </div>
  ton texte ici qui est assez long, mais pas asses
  <div style="visibility: hidden; clear: left;"> </div>
  </div>
  </div>
  </body>
  </html>
  
  Bref dans cet example, ça va chier si ton image est plus haute que ton texte, a ce moment là ton image va déborder du bord de ton cadre.
  
  Et pour ça il n'y a pas de solution "propre", une solution serait d'ajouter après ton texte un élément du style :
  <div style="visibility: hidden; clear: left; height: 1px;"> </div>
  
  Mais ça marche pas car ton navigateur va aller connement s'aligner sur ton menu flottant a gauche au lieu du float d'au dessus que tu lui demande.
  
  Bref, le principe même de ces float est moisi, et c'est ce que j'entends par mon display: integrated;
  C'est que l'image se trouve insérée dans le flux du texte.
  
  « C'est prévu dans CSS3, et ça fonctionne dans Firefox 1.0+ -moz-border-radius »
  Navré mais c'est une spécificité firefox/mozilla, j'ai toujours pas vu une vrai règle css dispo a ce propos.
  
  « xmlhttprequest ? sinon que ce soit XForms ou les webform en HTML5, ça apporte de nombreuses améliorations à ce niveau. http://ljouanneau.com/blog/2006/08/30/587-web-forms-2 . Et avec XForms, tu peux envoyer les données dans le format que tu veux. »
  C'est pas ce que je cherche ça moi...
  
  Ce que je veux est simplement pouvoir soumettre la form avec un envoie de fichier (si possible avec indicateur de progression) sans recharger la page.
  
  Leur xforms et webform sont a mon avis complètement inutiles, trop compliqué pour ce que c'est.
  
  Moi ce que je veux est pouvoir simplement côté client envoyer sans soumettre (et donc recharger la page) simplement un formulaire.
  
  Un truc du genre :
  ret = document.getElementById('formXXX').submitXMLRPC('une page');
  
  Enfin une du code js qui permette souplement de soumettre mon formulaire sans recharger la page.
  (et que le site reste fonctionnel par ailleurs tant que je recharge pas une page)
  
  « C'est le but de html5. Regarde la spec et les nouvelles balises qu'il propose avant de critiquer dans le vide. »
  
  Navré mais j'ai regardé leur balises, rien de concret, ça me donne l'impression d'avoir été conçu pas des mathématiciens sans penser au gens normaux...
  Désolé mais les specs j'appelle pas ça une doc, pour moi c'est une daube infâme illisible.
  (pour moi une vrai doc c'est le site de php avec une doc correcte partout)
  
  « Pardon ? c'est standardisé depuis des années dans HTML et XHTML.. Et standardisé des "metas", ce ne serait pas logique, puisque par définition, les métas est une manière d'enrichir le head selon tes propres besoins.
  
  M'enfin peut être que les microformats pourraient résoudre ton problème. »
  
  Ce que j'entend par là est que son contenu n'est pas pas une liste standard du genre :
  <title>{siteTitle}</title>
  <link rel="icon" type="image/x-png" href="{siteFavicon}" />
  <meta name="author" content="{siteAuthor}" />
  <meta name="license" content="{siteLicense}" />
  <meta name="keywords" content="{siteKeywords}" />
  <meta name="generator" content="{siteGenerator}" />
  Les prev, next et parent manquent, et quelques autres j'imagine.
  
  Je parle pas de normes et de balises, mais de contenu minimum de cette section head qui est pour moi un foutoir !
  
  --
  site perso : http://rapsys.free.fr/
  - [^]Re: Css3 et marcher sur la tête...
    
    Posté par Moonz () le 14/04/2007 à 17:31. (lien). Évalué à 2.
    > Ce que je veux est simplement pouvoir soumettre la form avec un envoie de fichier (si possible avec indicateur de progression) sans recharger la page.
    HTTP permet ça, c'est standard, et ça marche partout, même chez ceux qui n'ont pas Javascript:
    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10(...)
    - [^]Re: Css3 et marcher sur la tête...
      
      Posté par Moonz () le 14/04/2007 à 17:40. (lien). Évalué à 2.
      J'oubliais pour les flemmards, un petit résumé:
      
      Dans la page (PHP par exemple) qui est censée recevoir le fichier, il suffit de commencer par un:
      header("HTTP/1.1 204 No Content")
      puis la réception du fichier se fait de manière tout à fait normale, comme tu le ferais habituellement. Pour la barre de progression, c'est le rôle du butineur... Si le navigateur est suis correctement les recommandations de la RFC, il ne devrait pas recharger la page (non, ce n'est pas un troll envers IE, je n'ai pas essayé avec lui, peut être que ça marche même ;))
      
      Vous allez arrêter de chercher les solutions overkill AJAX Ouaib 2.0 aux problèmes simples, oui ? ;)
      
      PS: En tous cas, merci, moi qui me demandait à quoi pouvait bien servir ce code en pratique, tu viens d'éclairer la lanterne...
  - [^]Re: Css3 et marcher sur la tête...
    
    Posté par Laurent J (page perso, ) le 14/04/2007 à 19:24. (lien). Évalué à 2.
    
    « C'est prévu dans CSS3, et ça fonctionne dans Firefox 1.0+ -moz-border-radius »
    Navré mais c'est une spécificité firefox/mozilla, j'ai toujours pas vu une vrai règle css dispo a ce propos.
    
    C'est une spécificité Mozilla dans le sens où il y a le -moz- devant le "border-radius". Border-radius étant le style que tu cherches dont la spec est décrite dans le brouillon de CSS3. Et comme c'est un brouillon, Mozilla l'a implémenté mais a mis son prefixe devant. Ainsi, au cas où la spec sortirait en candidate recommandation mais avec des modifications, Mozilla ne serait alors pas en contradiction avec la spec CSS3.
    
    De nombreux styles Mozilla implémentant des styles de CSS3 ou CSS2 mais dont les specs étaient flous ou non figées, sont passés par le stade "-moz-". Et ils ont retirés le -moz- quand l'implémentation correspondait bien à la spec finale. Et c'est souvent le même processus chez d'autres éditeurs (les styles prefixés par un "-kkchose-" étant autorisés par la spec CSS)
    
    Ce que je veux est simplement pouvoir soumettre la form avec un envoie de fichier (si possible avec indicateur de progression) sans recharger la page. Leur xforms et webform sont a mon avis complètement inutiles, trop compliqué pour ce que c'est. Moi ce que je veux est pouvoir simplement côté client envoyer sans soumettre (et donc recharger la page) simplement un formulaire.
    
    Les specs que tu appels inutiles et compliquées (webforms ? compliqués ??? Tu es sûr d'avoir lu la spec ou même mon billet ?) te permettent justement de faire ce que tu décris.
    
    Navré mais j'ai regardé leur balises, rien de concret, ça me donne l'impression d'avoir été conçu pas des mathématiciens sans penser au gens normaux...
    
    J'ai pourtant je pense bien expliqué simplement dans mon billet dont j'ai donné l'url. Si tu l'avais lu correctement, tu aurais vu que, pour éviter de remplacer la page, il suffit juste de renvoyer un code http 204 (simple fonction header() en php). Si tu trouve cela pas concret, je sais pas ce qu'il te faut
    
    Désolé mais les specs j'appelle pas ça une doc, pour moi c'est une daube infâme illisible.
    
    Il est vrai que les specs ne sont pas fait pour les utilisateurs finaux de la techno, mais pour ceux qui l'implémente. Mais franchement, celle de HTML5 et webforms sont quand même relativement simple par rapport à d'autres. En attendant que des tutos sortent pour les utilisateurs finaux comme toi, une fois que la spec sera figée et sera une recommendation.
    - [^]Re: Css3 et marcher sur la tête...
      
      Posté par Laurent J (page perso, ) le 14/04/2007 à 19:36. (lien). Évalué à 2.
      pour compléter à propos de -moz-border-radius de mozilla qui est l'équivalent du futur border-radius de CSS3, voici la spec de ce dernier : http://www.w3.org/TR/2005/WD-css3-background-20050216/#the-b(...)
  - [^]Re: Css3 et marcher sur la tête...
    
    Posté par Laurent J (page perso, ) le 14/04/2007 à 20:07. (lien). Évalué à 2.
    
    Bref dans cet example, ça va chier si ton image est plus haute que ton texte, a ce moment là ton image va déborder du bord de ton cadre.
    
    Ok, j'ai compris ce que tu voulais faire. Certes, il faut bricoler, mais le comportement que tu décris de float est tout à fait normal et conforme aux spécifications. Float, ça retire du flux la boite sur lequel il est appliqué. c'est donc normal que la boite jaune ne prenne pas la hauteur de celle flottante, puisque cette dernière n'est plus contenue "visuellement" dans la boite jaune.
    
    Bref, ce n'est pas "une merde" comme tu dis, c'est juste que le float de CSS2 ne correspond pas à tes besoins.
    
    Heureusement, dans CSS3, ils sont en train de réflechir pour prendre en compte le cas que tu décris, avec la propriété clear-after : http://www.w3.org/TR/2002/WD-css3-box-20021024/#the-clear-af(...) Par exemple, il suffira de mettre dans ta div article :
    
    <div class="article" style="background: yellow; clear-after:left;" >
    
    plus besoin de ta div hidden.

Revenir en haut de page

Articles précédents : Internet

Liens connexes

Dépêche modérée par

Dépêche éditée par

Internet : Apple, Opera et Mozilla poussent HTML5

Strictement

[^]Re: Strictement

balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

[^]Re: balise canvas et XHTML

Apple, Opera et Mozilla

[^]Re: Apple, Opera et Mozilla

[^]Re: Apple, Opera et Mozilla

[^]Re: Apple, Opera et Mozilla

XHTML-ng 7.2.5 rev6 compliant

[^]Re: XHTML-ng 7.2.5 rev6 compliant

[^]Re: XHTML-ng 7.2.5 rev6 compliant : réjouissons nous...

[^]Re: XHTML-ng 7.2.5 rev6 compliant

[^]Re: XHTML-ng 7.2.5 rev6 compliant

[^]Re: XHTML-ng 7.2.5 rev6 compliant

utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

[^]Re: utilité ?

XHTML 5

[^]Re: XHTML 5

[+] [^]Re: XHTML 5

[^]Re: XHTML 5

[^]Re: XHTML 5

[^]Re: XHTML 5

[^]Re: XHTML 5

[^]Re: XHTML 5

[^]Re: XHTML 5

[^]Re: XHTML 5

X/HTML5 Versus XHTML2

[^]Re: X/HTML5 Versus XHTML2

[^]Re: X/HTML5 Versus XHTML2

[^]Re: X/HTML5 Versus XHTML2

Ironie

[^]Re: Ironie

Css3 et marcher sur la tête...

[^]Re: Css3 et marcher sur la tête...

[^]Re: Css3 et marcher sur la tête...

[^]Re: Css3 et marcher sur la tête...

[^]Re: Css3 et marcher sur la tête...

[^]Re: Css3 et marcher sur la tête...

[^]Re: Css3 et marcher sur la tête...

[^]Re: Css3 et marcher sur la tête...