Quelques articles et réflexions sur le développement Web - Page 1

http://www.uzine.net/article1979.html
et
http://www.uzine.net/article2143.html
Deux articles un peu longs, mais très intéressants sur la (non)promotion de XTML et de ses dérivés. C'est marrant, mais parfois, j'ai l'impression qu'un type de comportement très décrié dans ces articles correspondrait assez bien à celui d'un des anciens membres du forum ^^.

Et http://www.uzine.net/article1802.html est une réflexion pas bête du tout sur les canons d'affichage des sites web.

y parait que j'ai 5 erreurs sur ma page; c'est un record je pense
( http://www.galaxoft.org/ )

corrigé, j'avais fait /br et pas br/ y manque juste le doctype je pense

L’apprentissage du XHTML seraient donc celui d’un langage rigide, complexe et n’acceptant pas les bidouilles. La construction des pages par patchs successifs, qui est la méthode simple pour apprendre soi-même le HTML, est bloquée.

faut pas déconner, un css ça se fait à coté à la mano; et incrémentalement, ça pose pas de problèmes! d'abord t'as une page moche et tu choisis les trucs dans le css nan? enfin je fais comme ça moi.
et pour les chieurs le w3c a fait un WYSIWYG (amaya) qui marche assez bien.

- Séparer le fond et la forme

Le XHTML revient, non pas parce qu’il utilise les recommandations chipoteuses du W3C Validator, mais uniquement lorsqu’il est utilisé d’une manière très spécifique, au principe de balises de structuration logique associées à des tables de mise en pages. Autrement dit, il facilite la stricte séparation du fond et de la forme.

L’évolution annoncée (à mon avis totalement mort-née) poussera cette logique encore plus loin : du XML contenant non seulement la structure logique des pages, mais du site lui-même ; une DTD personnalisée définira la liste des éléments logiques autorisés ; un ensemble de règles de mise en page (XSLT stylesheet) permettra ensuite de présenter à partir du fichier XML les documents au public. Du HTML on sera passé au XHTML puis au couple XML/XSLT [1].

Sauf que : on s’en fout.

j'aime bien la comparaison mathml/tex:

[a + b]^{260} + \{a + b\}_i

<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<msup>
<mfenced open="[" close="]">
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</mfenced>
<mn>260</mn>
</msup>
<mo>+</mo>
<msub>
<mfenced open="{" close="}">
<mrow>
<mi>a</mi>
<mo>+</mo>
<mi>b</mi>
</mrow>
</mfenced>
<mi>i</mi>
</msub>
</mrow>
</math>

il abuse un peu mais il a pas tort sur tout quand même
encore une vérité vraie:

La dernière mise à jour de la page du W3C consacrée au VRML, Virtual Reality Modeling Language semble remonter à... avril 1995. Voilà un langage purement et simplement enterré.
Cela est très paradoxal : le VRML a été très à la mode à une époque où les ordinateurs n’étaient pas capables d’afficher avec souplesse et élégance des modèles 3D en temps réel (c’était au siècle dernier) et où, surtout, les modems ne permettaient pas de télécharger rapidement le moindre fichier VRML (une centaine de kilo-octets, c’était déjà rédhibitoire). Aujourd’hui les machines se débrouillent parfaitement avec des modèles 3D de folaïe et le haut débit rend le téléchargement des méga-octets une partie de plaisir, pourtant la réalité virtuelle ne figure pas du rayon des normalisations prioritaires.

c'est clair

Grand sujet d’engueulades, doit-on mettre des accents sur les majuscules ? (Avec pour argument final : « j’ai appris à la petite école qu’on ne devait jamais en mettre ».)

Mais lol

Ouai enfin ceux qui osent dire aue le HTML est un bon langage... On a pas vu plus horrible.. il accepte tout et n importe quoi, et pour moi le XHTML est justement la pour remettre un peu d ordre dans ce grand dommaine de bidouillage...

mais c'est pas un langage, c'est pour ça que t'es pas satisfait.

le html est un système signalisation de mise en page. donc c'est pas comparable avec un langage de programmation

squalyl>par rapport à l'exemple mathml / latex
le truc c'est que latex tu va le taper à la main, et le mathml, c'est fait pour être édité par un logiciel. le xml offre une syntaxe effectievement longue à taper à la main, mais mon intérêt est qu'il existe un miriade de parser xml, de transformateur, de générateurs... etc, ce qui fait que tu peux faire bcp plus de chose.
Le xml est sensé être un format interne quand même.

D'ailleurs, quand ce dénomé Arno critique le xhtml comme quoi c'est élitiste et que le html c'est à la portée de tout le monde, franchement, aller éditer un fichier texte avec des balises est quand même bien plus geek que de créer son site web avec word !

je suis d'accord avec toi. il se met au niveau du nioob qui débute. quand on a pigé le html je vois pas trop la difficulté pour passer au xhtml

en gros son idée au mec c'est que le xhtml pour le moment fait la même chose que le html en moins souple et qu'il n'apporte rien de neuf.

pour mathml il parait qu'il n'existe aucun éditeur fonctionnant complètement. je sais qu'amaya le fait bien, donc je soupçonne le mec d'abuser un brin

Oui, mais est-ce qu'Amaya supporte vraiment de façon exhaustive les toutes les balises mathtml ?

squalyl>le xhtml apporte le xml au html, donc tous les parsers : ca permet de faire des pages web de type "ajax"

Oui, mais justement, combien d'années a-t'il fallu attendre pour voir arriver ce type de technologies alors que l'XHTML est défini depuis des lustres ? Ca fait plus de 5 ans que la norme existe. Or 5 ans, en temps informatique, c'est énorme. C'est habituellement la durée de vie maximale d'une technologie.

Non, 5 ans c'est court je trouve. Si elle dure moins de 5 ans, c'est qu'elle n'est pas interessante. Une technologie, faut d'abord qu'elle se fasse connaître, puis qu'on lui confère une certaine utilité, puis y'a la formation, et enfin l'utilisation. Les industriels vont pas s'amuser à changer de technologie tous les 5 ans.
Le html, le java, le c, même le xml ont tous bien plus de 5 ans, et le xml est en train de percer, ce qui a entrainé une évolution du html vers le xhtml.

le reproche que faisait le mec c'est de considérer html comme obsolète () alors que c'est une méthode très simple pour apprendre a creer des pages web sans que le parseur xml te crache à la geule que t'as oublié un / dans <br />

je suis d'accord que le xhtml est une bonne chose car il apporte la rigueur xml au langage html, mais ce dernier est encore intéressant pour les débutants et tous les cocos qui veulent faire leur site

ouai en meme temps c est pas en etant permitif sur les erreurs qu on tire la qualite des sites vers le haut...

c'est pas ça le truc.
bien sur qu'il faut débugger et passer en xml

mais pour commencer à développer c'est utile

bordel, zetes lourds hein

oui en meme temps apprendre a fermer les balises etc... et etre rigoureux, c est plus une aide pour le developpeur que de permettre des erreurs qui ont de fortes chances d avoir des consequences plus tard sur le code, et sur sa portabilite...

Enfin, je trouve cet article ridicule..

Moi non au contraire. Pour le grand public qui n'a pas envie de se prendre la tête ou les jeunes (9-15 ans) qui veulent bricoler un peu, le HTML est vraiment l'idéal (comme le fut le Basic avant de se complexifier en VisualBasic)

oui mais le basic est rigoureux...

Pas vraiment, en BASICA ou en QBasic, tu peux faire des choses très crades, l'appli fonctionnera très bien. Il n'y a pas de case matching, le transtypage fait que au niveau des variables tu peux faire n'importe quoi sans avoir d'erreur (même si au final ça ne fait pas ce qui était prévu - et le pire c'est que parfois ça marche quand même)... le parseur Basic de base est très "simple" au final. Et il autorise parfois des syntaxes incorrectes (au niveau des parenthèses, etc.)

Ce qui est bizarre c'est qu'il dit que le HTML c'est du SGML simplifié, alors que non, c'est du SGML tout court pas simplifié ; et c'est le XML qui est du SGML simplifié (et XHTML est à XML exactement ce que HTML est à SGML ). La principale différence entre XML et SGML étant que XML n'autorise pas les balises implicites (il faut tout fermer). Mais c'est pas parce que HTML autorise les balises implicites que c'est plus crade que XHTML, c'est juste plus compliqué à parser mais tout est bien défini dans la spécification...

Après ça, le fait qu'on soit tolérant sur les erreurs n'a rien à voir avec le fait qu'on utilise HTML ou XHTML. Rien n'empêche en particulier un navigateur de lire du XHTML en se contentant d'ignorer les balises qu'il ne connaît pas... et rien ne l'empêche non plus de lire du HTML en se bloquant à la moindre erreur. Le truc c'est qu'il y a simultanément une évolution vers le respect des standards et la volonté de passer de SGML à XML, mais les deux ne sont pas intrinsèquement liés.

Sinon le gros inconvénient de la suppression des balises implicites c'est que c'est plus lourd à éditer à la main (et ça fait des fichiers plus gros) et qu'une partie du travail qui était fait par l'interpréteur doit être faite d'avance, à la place, par la personne qui code. L'avantage qui va avec étant que le SGML était trop compliqué pour qu'il en existe des parseurs génériques, autant que je sache (ie les navigateurs lisent le HTML, mais HTML n'est qu'un des types de documents possibles en SGML et il n'existe pas de parseur générique pouvant lire n'importe quel document SGML), alors que pour XML c'est beaucoup plus facile d'en faire (et d'ailleurs ça existe ^^). XML supplantant SGML, c'est logique de vouloir reformuler HTML en XML pour standardiser. Mais c'est vrai que c'est une régression pour les utilisateurs dans la mesure où SGML est plus user-friendly tandis que XML est plus computer-friendly ; donc c'est normal qu'il gueule àmha.

squalyl^2 :
en gros son idée au mec c'est que le xhtml pour le moment fait la même chose que le html en moins souple et qu'il n'apporte rien de neuf.

Ben, oui, mais c'est pas seulement son idée, c'est exactement ça : xhtml n'est bien qu'une « reformulation » de html (et ça ne prétend pas être autre chose)

ben HTML est du SGML simplifié dans le sens où c'est une forme très particulière de document SGML... (pas vraiment du SGML, d'ailleurs : <a href=/yaro/plouf>)


enfin pour ce qui est de l'article qui fait l'apologie du fait que le HTML est 1000x trop permissif, je trouve ça un peu con... pour un débutant, mieux vaut une IDE adaptée qui signale les erreurs de manière claire (ou est conçue pour ne pas créer d'erreurs, cf wysiwyg) qu'une espèce de parseur bourré de cas particuliers qui même en faisant de son mieux ne va de toute façon pas systématiquement faire ce que pense l'utilisateur... le Basic est peut-être pas très élégant, mais il ne cherche pas à tout prix à cacher les erreurs pour que le navigateur d'en face se casse la gueule ^^