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.
Aller plus loin
- La demande au W3C (1 clic)
- Le site du WHATWG (2 clics)
- Annonce de la relance du HTML par le W3C (2 clics)
- La page du renouveau groupe de travail HTML (1 clic)
# Strictement
Posté par Nÿco (site web personnel) . Évalué à 4.
* "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++ ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# balise canvas et XHTML
Posté par Christophe Roland (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 8.
À 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 (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 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 (site web personnel) . Évalué à 1.
ç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 (site web personnel, Mastodon) . Évalué à 2.
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 . Évalué à 3.
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 (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: balise canvas et XHTML
Posté par Nelis (site web personnel) . Évalué à 5.
[^] # Re: balise canvas et XHTML
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: balise canvas et XHTML
Posté par feth . Évalué à 3.
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 (site web personnel, Mastodon) . Évalué à 2.
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 Galou (site web personnel) . Évalué à 1.
[^] # Re: Apple, Opera et Mozilla
Posté par DPhil (site web personnel) . Évalué à 2.
http://lists.w3.org/Archives/Public/public-html/2007Apr/0429(...)
[^] # Re: Apple, Opera et Mozilla
Posté par Christophe Roland (site web personnel) . Évalué à 4.
[^] # Re: Apple, Opera et Mozilla
Posté par mats . Évalué à 1.
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 nomorsad . Évalué à 5.
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 (site web personnel) . Évalué à 4.
[^] # Re: XHTML-ng 7.2.5 rev6 compliant : réjouissons nous...
Posté par André Rodier . Évalué à 8.
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 . Évalué à 0.
HTML plus simple que XHTML... Faudra que je la ressorte celle là :)
[^] # Re: XHTML-ng 7.2.5 rev6 compliant
Posté par rewind (Mastodon) . Évalué à 10.
[^] # Re: XHTML-ng 7.2.5 rev6 compliant
Posté par Guillaume Rossignol . Évalué à 3.
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 (site web personnel) . Évalué à 4.
[^] # Re: utilité ?
Posté par Metzgermeister . Évalué à 4.
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 (site web personnel, Mastodon) . Évalué à 4.
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 . Évalué à 1.
Toutefois, je suis plutôt content de voir que le projet XHTML 2 n'est pas annulé.
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 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 . Évalué à 2.
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 (site web personnel, Mastodon) . Évalué à 2.
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 (site web personnel, Mastodon) . Évalué à 2.
à 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 . Évalué à 0.
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 3.
Je suis d'accord avec toi mais pense tu qu'il y aura bcp de navigateur HTML5 non JS ?
[^] # Re: utilité ?
Posté par Moonz . Évalué à 2.
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 . Évalué à 5.
- 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 (site web personnel) . Évalué à 2.
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 ?).
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: XHTML 5
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
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 . Évalué à -1.
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 (site web personnel) . Évalué à 4.
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 (site web personnel, Mastodon) . Évalué à 3.
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_ . Évalué à 1.
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 . Évalué à 4.
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 . Évalué à 7.
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 ?
Ahem, ton interprète Python admet les erreurs de syntaxe dans ton code source ? Étrange.
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.
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 . Évalué à 10.
-> 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><!-- Un compteur de visite copié collé sur je sais quel site --></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 . Évalué à 2.
Flickr ? Webshots ? iPhoto+iWeb ? Picasa ? VOX ?
# X/HTML5 Versus XHTML2
Posté par dragoonway . Évalué à 4.
http://xhtml.com/fr/future/x-html-5-versus-xhtml-2/
[^] # Re: X/HTML5 Versus XHTML2
Posté par bichenoubi . Évalué à 1.
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 (site web personnel, Mastodon) . Évalué à 5.
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 . Évalué à 1.
http://www.digital-web.com/articles/html5_xhtml2_and_the_fut(...)
# Ironie
Posté par bichenoubi . Évalué à 1.
Je me verrais un peu dérouté de devoir utiliser IE....
[^] # Re: Ironie
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
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 G. (site web personnel) . Évalué à 2.
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)
[^] # Re: Css3 et marcher sur la tête...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
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.
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.
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)
c'est prévu dans CSS3, et ça fonctionne dans Firefox 1.0+ ( -moz-border-radius)
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 le but de html5. Regarde la spec et les nouvelles balises qu'il propose avant de critiquer dans le vide.
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 G. (site web personnel) . Évalué à 2.
« 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 !
[^] # Re: Css3 et marcher sur la tête...
Posté par Moonz . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel, Mastodon) . Évalué à 2.
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)
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.
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
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 (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Css3 et marcher sur la tête...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.