Page 3 sur 4

Maps a écrit:
Téthis a écrit:Pourquoi est-ce que XHTML devrait être mauvais pour un logiciel libre ? Tout ce qui utilise XML n'est pas "corrompu" par les brevets. Tu n'aimes pas les bisounours ?

J'aime bien les bisounours, même si je ne vois pas le rapport

Il est là :

AntoineP a écrit:Il faut regarder les choses en face : ce n'est pas parce qu'IE le supporte mal que les webmestres n'utilisent pas XHTML. C'est parce que XHTML ne leur apporte que des inconvénients (rigidité syntaxique et structurelle accrue) et pas d'avantages (aucune nouveauté fonctionnelle intéressante par rapport à HTML).
Il n'y a que les bisounours du W3C pour croire le contraire...

Maps a écrit:Bon, sinon, c'est juste que j'ai pas envie de recoder mes pages en XHTML dans un autre langage pour de bêtes histoires de brevets... (d'où l'avis «philosophique et stratégique» demandé )

Tu ne peux pas écrire du XHTML avec autre chose que les règles XHTML.

AntoineP a écrit:Il n'y a que les bisounours du W3C pour croire le contraire...

Ah oui, il aurait fallu que je relise un peu le fil tiens...

Thétis a écrit:Tu ne peux pas écrire du XHTML avec autre chose que les règles XHTML.

Ah, je me suis encore mal exprimé... Je reformule différemment : j'ai une page web à créer. À l'heure actuelle, est-ce plus malin de le faire en HTML ou en XHTML ?
(sachant que c'est bien pour ne pas reécrire la page dans un autre langage un peu plus tard...)

Le plus malin, c'est de le faire dans le langage dans lequel tu es le plus à l'aise, sachant qu'aucun des deux ne disparaîtra à court terme, et qu'à long terme, tu auras largement l'occasion de refaire ton site pour diverses raisons plus ou moins bonnes (mais indépendantes du W3C).

Téthis a écrit:Tu n'aimes pas les bisounours ?

C'est moins croustillant que les chatons.

Téthis a écrit:Autrement dit, comme les données sont correctement structurées, le navigateur n'a pas à se soucier de fermer des balises oubliées et corriger des erreurs sur les balises. Ceci est la théorie.

Le coût de traitement de l'arbre est certainement dérisoire par rapport au coût du rendu graphique (calculs de positionnement, rendu des caractères anti-aliasés, blitting...).
On peut comprendre l'argument pour un moteur qui ferait du traitement massif en batch, mais pas pour un navigateur graphique (un parcours d'arbre HTML, c'est rapide de nos jours tu sais

).

AntoineP a écrit:Le coût de traitement de l'arbre est certainement dérisoire par rapport au coût du rendu graphique (calculs de positionnement, rendu des caractères anti-aliasés, blitting...).

Le rendu de la page peut s'effectuer en même temps que la réception de données, pas la peine d'attendre la fin. Gecko utilise différents modes de rendu dont un qui opère comme ça.

Bon, d'un autre côté j'ai été surpris de voir qu'il n'y avait pas de VM pour javascript et qu'on était resté à l'époque de qbasic et de son interpréteur.

AntoineP a écrit:C'est moins croustillant que les chatons.

C'est surtout plus difficile à trouver.

Téthis a écrit:Le rendu de la page peut s'effectuer en même temps que la réception de données, pas la peine d'attendre la fin.

Ce qui ne change rien à ma remarque

Bon, d'un autre côté j'ai été surpris de voir qu'il n'y avait pas de VM pour javascript et qu'on était resté à l'époque de qbasic et de son interpréteur.

Oui, et Ruby fonctionne pareil.
(et, vu les performances de PHP, cela ne m'étonnerait pas qu'il soit concerné itou)

Je suis d'accord avec *genium* et AntoineP : XML AJAX AJAJ JSON XHTML 1.0/1.1/2.0 PHP IETF SOAP OSI XUL XAML SAML c'est bien, alors que les WC c'est mal (car en informatique, avec un acronyme de moins de 3 lettres t'es pas crédible)