5177 sujets

Le Bar du forum

Pages :
Bonjour,

J'ai eu un petit débat assez constructif hier sur HTML5 vs XHTML2-5 j'aurais voulu avoir d'autres opinions et connaître la tendance sur alsacréations, donc je me permet de poster. Sans dévoiler direct mon opinion sur le sujet pour ne pas orienter le débat (et puis je peux peut-être changer d'avis…)

Les liens qui sont ressortis pour les différentes positions :
- W3C Interaction Domain Architectural vision for HTML/XHTML2/Forms Chartering positionnement du W3C sur le débat,
- HTML 5 : les documents deviennent des applications très instructif,
- HTML 5 differences from HTML 4 la syntaxe de HTML5 qui peut être aussi rigoureuse que du XML.

Merci d'avance Smiley smile

(edit : woops, c'était le mauvais forum apparement. désolé)
Modifié par nod (02 Jun 2009 - 11:47)
Pour désigner XHTML 5 et XHTML 2 en même temps :-° ça aurait peut-être été plus clair en (X)HTML5 vs XHTML2…

Sinon un autre lien que j'ai oublié qui se trouve dans l'autre post aussi : X/HTML 5 Versus XHTML 2.

( edit ) je viens de lire l'autre topic, en 2 ans les choses ont peut-être changés… ou pas.
Modifié par nod (02 Jun 2009 - 12:05)
Pour moi c'est simple, XHTML2 est orienté document tandis que (X)HTML5 est orienté application. Il y a de bonnes idées dans HTML5 (comme <video>) mais je ne suis absolument pas convaincu par la plate-forme applicative que devient le web. Ce n'est pas sans raison s'il existe de nombreux frameworks pour les applications graphiques, c'est parce que rien n'est parfait et que tout le monde n'a pas le même point de vue. C'est pourquoi prétendre détenir la vérité avec un web d'ores et déjà pourri par la rétro-compatibilité me semble ridicule. La base même du web qui est HTTP n'est pas faite pour de l'applicatif, alors arrêtons de bricoler et inventons quelque chose de nouveau, en s'inspirant de l'excellent travail fait sur XMPP depuis des années.

La division au sein du W3C m'a toujours énervé mais je trouve que ça empire de plus en plus, je ne comprends même pas pourquoi l'IETF reconnaît et travaille avec une organisation dont la philosophie est si différente de la leur.

(Ah bon ? On est pas vendredÿ ? Smiley lol )
Modifié par Changaco (02 Jun 2009 - 16:58)
Bref HS après avoir lu la réponse de changacco : IL faudrait vraiment que le débat web vs bureau ait lieu sur la terrasse un de ces quatre...
Changaco a écrit :
mais je ne suis absolument pas convaincu par la plate-forme applicative que devient le web

D'autres le sont assez largement. Je pense par exemple à Tarik Krim, fondateur de Netvibes et qui va lancer prochainement Jolicloud, un OS dérivé d'Ubuntu GNU/Linux destiné aux netbooks et dont l'interface utilise des langages web.
http://www.jolicloud.com/

Par ailleurs il faut distinguer l'emploi des technos web comme plateforme applicative, que ça soit dans le navigateur (Gmail, Aviary...) ou en dehors (au pif: Adobe Air, extensions et macros écrites en JavaScript dans Komodo...), et le cloud computing. Les deux ne vont pas nécessairement ensemble.
Florent V. a écrit :

D'autres le sont assez largement. Je pense par exemple à Tarik Krim, fondateur de Netvibes et qui va lancer prochainement Jolicloud, un OS dérivé d'Ubuntu GNU/Linux destiné aux netbooks et dont l'interface utilise des langages web.
http://www.jolicloud.com/

Tiens à ce propos, quelqu'un a déjà testé? Je le verrais bien prendre la place d'XP sur mon eeePc…
Benjamin D.C. a écrit :
Tiens à ce propos, quelqu'un a déjà testé?

«Jolicloud is still in private alpha and invitation only.»
Florent V. a écrit :

«Jolicloud is still in private alpha and invitation only.»

Ben oui je sais, je demandais s'il y avait un heureux beta testeur parmi nous. Smiley smile
Comme on dit, c'est un post qui fait pshit.

J'ai parcouru les sujets donnés en lien (puis ce truc de vendredÿ aussi Smiley langue ) faut croire que les positions sont plus modérés par ici ou que j'arrive après la bataille et que c'est juste un brin d'indiférence sur le sujet qu'il reste.

Jolicloud a l'air bien sympa en passant.
Ca doit être quand même vachement lent...
Vu la vitesse des connexions aujourd'hui, je n'y crois pas encore, c'est pas encore assez rapide pour charger des Go de données pour un OS complet.

Et on dira ce qu'on voudra, mais AJAX c'est lent, et le protocole HTTP est relativement verbeux par rapport à une connexion TCP avec un protocole optimisé, voire un protocole basé sur UDP. ON a beau avoir des ordinateurs de plus en plus performants, cette perte de performances réseau se fera ressentir un moment donné quand même.
@QuentinC: Il ne s'agit pas de charger des Go de données à chaque démarrage, déjà parce que c'est pas du binaire donc ça ne représente pas des Go et ensuite parce que le cache est crucial pour ce genre d'applications.
Par contre sur HTTP on est d'accord, ce n'est absolument pas adapté au développement d'applications, et quand on y pense, ce n'est plus adapté à la consultation de page non plus car on n'est pas averti lors d'un changement dans une page. C'est ce que je répète depuis quelques mois maintenant, et je continuerai de le répéter tant qu'on utilisera ce protocole. Mais quand on voit Mozilla on se dit qu'on est pas près de se débarrasser de HTTP, contrairement à Google qui a compris l'intérêt de XMPP …
Sur UDP je ne vois pas l'intérêt, la "complexité" de TCP est nécessaire.
Pour des appli web XMPP ouais, y'a de quoi faire y'a pas photo. Mais je suis quand même curieux de savoir en quoi ça aide à la consultation de documents. Si le document en question se met à jour tout seul et que l'on doit (/peut) être averti de sa modification, pour moi c'est plus un document, c'est un début d'application. J'ai probablement une conception un peu vieux jeu des documents, mais mes bouquins ne se mettent pas à jour tout seuls et y'a quand même pas mal de contenu statique sur le net.

Obliger tout ce contenu statique à bouger sur un protocol qui permet des trucs dont ils ont pas besoin, mouais…
Modifié par nod (04 Jun 2009 - 08:54)
Les limites ne sont pas technologiques, elles sont industrielles. La fibre optique nous libérera sous peu des problèmes de volumes de transactions. Mais le frein n'est pas là, il est dans la concurrence entre groupes puissants (Google et consorts) qui ne sont pas là pour faire du "service public" (faire ce qui serait le mieux dans l'intérêt de tous) mais du profit en situation dominante. Si Google investit dans XMPP ce n'est pas parce que c'est "mieux pour tous" mais parce qu'il espère imposer ce format pour des raisons stratégiques.
Quant à HTML il est évident que c'est un langage bien trop faible pour les besoins à venir. XMPP est-il beaucoup plus puissant, c'est probable si on considère que c'est un langage d'échange plus qu'un langage de description. Couvre-t'il pour autant l'ensemble des besoins des prochaines années ? Pas si sûr.
Pas sûr non plus qu'il faille absolument un "langage central fédérateur" : ce point de vue me semble aujourd'hui obsolète. Je crois qu'on va plutôt vers des langages spécialisés par tâches et que tout l'enjeu est dans la capacité de dialogue qu'ils entretiendront entre eux.

Je crois plutôt aux environnements immersifs où les échanges ne se font plus uniquement entre utilisateurs et contenus, mais entre "objets numériques" - que ces "objets" soient des utilisateurs en tant qu'entités, des objets réels ou des objets virtuels.
Juste comme exemple une anecdote arrivée il y a deux ou trois semaines : un Suisse, Oliver Goh, en déplacement à Hong-Kong entre dans OpenSim (un univers virtuel Open Source) et passe faire un tour virtuel chez lui. Ayant installé des sensors shaspa (des capteurs capables d'échanger des informations entre objets réels et objets virtuels) il se rend compte que sa consommation d'eau a anormalement augmentée, et qu'il y a donc une fuite ou un robinet resté ouvert. Il envoie son avatar couper l'eau à distance et hop, la conso retombe à zéro. Il aurait aussi bien pu faire ça depuis un navigateur, un mobile, etc.
On peut de la même façon imaginer que tout avatar en monde immersif soit capable d'interagir avec des contenus numériques quel que soit le langage utilisé, le tout est qu'il y ait un langage adapté au besoin.

Mais ça ne s'arrête pas là, à une gestion domestique. Shaspa (y'a aussi Pachube qui serait à suivre de près) est capable de "tagger" aussi bien des objets que des identités d'utilisateurs. Du coup ce sont tous les réseaux sociaux qui seront sous peu concernés.

Dans cette optique, le bureau virtuel est un univers numérique d'interactivités dans lequel on réalise toutes sortes de tâches. Le limiter à un desktop online est trop réducteur. Limiter le web de demain à des collections d'applications préservant la distinction entre utilisateurs et contenus aussi. You are part of the content... on est, en tant qu'individus, une partie du contenu.
Pour répondre à la question initiale, il n'y pas d'enjeu stratégique particulier entre HTML5 et XHTML2 sinon industriel (initiative WHATWG). Interagir avec un contenu numérique (le consulter, le transformer, dialoguer avec lui, etc.) ne s'appuie pas sur un langage particulier.

(normalement c'est vendredÿ le jour de moquette mais là j'entorse)
Vous m'intriguez de plus en plus avec votre XMPP (quand je dis vous, c'est en particulier changacco mais pas uniquement).
Je croyais pourtant que c'était « seulement » le pendant de MSN du côté du libre, c'est-à-dire un simple protocole de messagerie instantanée... je vais largement faire dévier le sujet initial avec cette question, mais en quoi XMPP peut ou pourrait supplanter (X)HTML, HTTP et le web ?

Sinon pour la notion de document, je suis assez d'accord avec Nod. Un document reste pour moi quelque chose d'assez statique, et dès le moment où il y a des parties de la page qui changent, c'est un début d'application. Par contre il faut s'entendre sur le terme « statique » : une page qui présenterait les cours de la bourse et qui serait actualisé en temps réel à condition d'appuyer sur F5 reste un document, malgré que son contenu change régulièrement à la demande. Par contre, ça devient une application si la mise à jour est automatique en temps réel sans avoir quelque chose à faire, par exemple via AJAX.
Pages :