Indépendance des moyens techniques

Logiciels libres, standards ouverts

Dans la même rubrique

Logiciels libres, standards ouverts

28 septembre 2003

W3C go home !

26 octobre 2002

Pouvez-vous faire confiance à votre ordinateur ?

4 mars 2002

Les brevets et le W3C

17 mai 2001

Pourquoi et comment j’ai installé linux chez moi

23 février 2001

phpNuke, conte moderne de la société de contribution

17 octobre 2000

Les cyber-résistants du Libre

19 septembre 2000

Lettre de 2020

2 septembre 2000

Sémantique politique de l’informatique libre

Cyber-économie mon amour

Internet & Journalisme

Pressions & répression

lundi 23 mai 2005

Le HTML dans le potage

par ARNO*

Commençons par un constat : un petit tour sur le site Cool Homepages, qui sélectionne depuis des années des sites selon la beauté et l’originalité de leur graphisme et/ou de leur navigation (cela étant évidemment subjectif), devrait terrifier les amateurs de standards ouverts : quasiment tous les sites sélectionnés sont désormais réalisés en Flash. Le choix du graphiste serait donc, pour la réalisation d’un beau site, un format propriétaire, alors même qu’on nous vante un XHTML arrivé à maturité ? Cela devrait tout de même inquiéter... Le même constat peut être fait sur toutes les pages de sélection de « beaux » sites.

Cela est très paradoxal : depuis l’année 2000, les recommandations pour les nouvelles normes sont publiées et les navigateurs grand public ont largement eu le temps de les intégrer. Pourtant, le HTML semble planté en rase campagne, utilisé pour faire du Web à papa, les navigations rigolotes étant désormais réalisées avec Flash.

Tout un discours s’est développé autour des nouvelles normes, basé sur des dogmes pinailleurs et tâtillons, introduisant une rupture avec l’ancien HTML ; et pourtant, on se retrouve aujourd’hui à attendre désespéremment des « innovations » qui viendront récompenser nos efforts vers la « compliance ». Il serait bon, en effet, qu’on s’amuse autant avec le XHTML bien propret du docteur W3C qu’avec le HTML tout pourri dont nous gratifiaient les versions successives de Netscape 2, 3 et 4...


Des effets étonnants sur l’écosystème: La normlisation programmée des Css a coïncidé avec l’apparition d’une nouvelle espèce d’écureuil mutant (du désert), pris ici sur le vif en Arizona.

CSS

Commençons par la technique qui a le plus apporté au HTML, pour en dire du bien, mais aussi pour pointer les limites et les aberrations de choix dogmatiques dans la définition des normes.

Les styles (regroupés en feuilles de styles : CSS) ont été normalisés dès 1998 : il s’agit de séparer d’un côté le contenu structuré de l’information (indiquer que ceci est un titre, ceci est le texte principal du document, ceci est une liste de liens de navigation...) et, d’un autre côté, dans les feuilles de style, la présentation graphique de cette information (je veux présenter les titres de telle manière, dans telle taille, avec tel espacement au-dessus et en dessous, je veux que mon texte apparaisse à tel endroit de telle façon, je veux que les liens s’affichent de telle manière...).

C’est, pour l’essentiel, une belle réussite. Non seulement parce que l’on peut faire tout ce que l’on faisait auparavant avec un code plus lisible (donc plus facile à modifier par le webmestre), plus rapide à charger (les styles sont des fichiers communs à plusieurs pages, donc ne sont pas téléchargés pour chaque page), mais aussi parce que, de plus, on peut faire ce qui était difficile ou impossible auparavant (contrôle typographique beaucoup plus fin, interface différente pour la même page selon le support — principalement, selon que l’on voit la page sur l’écran d’un ordinateur ou qu’on l’imprime...).

Par ailleurs, pour peu que les CSS soient présentées sans dogmatisme (comme confondre l’utilisation des CSS et le passage à un XHTML ultra-compliant), elles s’intégrent dans la courbe d’apprentissage normale d’un webmestre sans trop de souffrance.

Les bienfaits des CSS sont largement détaillés par ailleurs, inutile de trop développer ici. Consacrons-nous à une tâche un peu plus originale : en dire du mal !

Les CSS souffrent d’un dogme originel : les CSS ne doivent pas devenir un langage de programmation. Cette volonté est très discutable (ce que nous allons faire immédiatement), et fait apparaître des limites dans leur utilisation.

Il existe des sélecteurs et des pseudo-classes qui permettent d’appliquer (au moins sous Mozilla-Firefox) des styles de manière intéressante. Cependant, on obtient des syntaxes très complexes pour des possibilités très limitées. Par exemple, on peut définir le style de la première lettre du premier paragraphe qui suit la fermeture d’un intertitre, ainsi que la première lettre du premier paragraphe d’un texte. C’est assez amusant à faire, d’autant que la définition du style est interminable (ici pour une page générée avec SPIP) :

div.principal>p.spip:first-child:first-letter { ... }
h3.spip+p.spip:first-letter { ... }

En revanche, vous n’avez pas accès à la seconde lettre du paragraphe, vous ne pouvez pas définir un style qui s’appliquerait à une ligne de tableau sur deux, vous ne pouvez pas tester si la première lettre est un guillemet ouvrant, auquel cas vous souhaitez appliquer le style, également, à la deuxième lettre (pour faire une belle lettrine), vous ne pouvez pas réduire la taille du texte en fonction du nombre de caractères, etc.

Dans le but d’éviter que les CSS ne deviennent un langage de programmation, leurs concepteurs se sont visiblement astreints à des limitations très importantes.
— Il n’y a pas de syntaxe pour des alternances, ou de positions relatives dans la structure (une occurence sur deux, la seconde occurence sur trois, l’avant-dernière occurence...).
— Il n’est pas possible d’appeler une définition depuis une autre définition, ce qui oblige à des doublons dans les définitions : par exemple, on définirait un style « police-helvetica », un style « taille-10 », et dans une autre définition on pourrait indiquer qu’on intègre les styles « police-helvetica » et « taille-10 », que l’on panacherait avec un fond coloré, etc.
— On manipule sans cesse des nombres et des dimensions dans les CSS (taille des caractères, espacements, couleurs RVB...), mais il n’existe aucun outil pour les manipuler ; il n’existe en particulier pas de « variables » réutilisables à différents endroits.
— Les choix conditionnels sont quasiment inexistants (limités à quelques pseudo-classes à la syntaxe très limitée ; les conditions ne se trouvent d’ailleurs pas à l’intérieur des définitions elles-mêmes). On ne peut pas, par exemple, utiliser telle couleur si l’environnement du style est dans telle taille de caractère, et telle autre couleur si le fond sur lequel il s’applique est de telle couleur. Voici un automatisme que l’on se condamne à réaliser « à la main », alors qu’il pourrait être pris en charge par les CSS : plaçons une image au début d’un paragraphe ; si cette image est de petite taille, il sera graphiquement avantageux de la faire « habiller » par le texte (float) ; si elle est d’une grande largeur, il faut la sortir du paragraphe et ne pas l’habiller avec le texte, sinon on aurait des lignes trop courtes pour que le texte soit élégant (display:block).
— Et aucune de ces limitations ne peut être résolue par le recours à Javascript dans les définitions des styles, puisqu’il n’est pas prévu de déclencher du javascript depuis les feuilles de style.

En réalité, c’est pire : il existe une solution partielle mais puissante. Ce sont les « comportements » (behaviors), et les « expressions » de Microsoft Explorer. Les comportements ne semblent pas avoir dépassé le stade de « working draft » du côté du W3C (août 1999).

Ces particularités de Microsoft Explorer sont très utilisées, bien que peu connues : elles sont habituellement utilisées pour combler les manquements de ce logiciel à la norme (les webmestres les considèrent quasiment comme des « hacks » pour faire « salement » ce que Mozilla ferait « proprement ») ! On les utilise pour lui faire accepter un « max-width » ou utiliser la transparence alpha d’une image au format PNG 24. Leur utilisation ne peut malheureusement que se limiter à cela puisque, ces éléments n’étant pas définis par une norme (encore une fois : il s’agit visiblement d’éviter à tout prix que les CSS ne ressemblent à un langage de programmation), il ne sont pas intégrés et il n’en existe pas d’équivalent dans les autres navigateurs.

Pour illustrer ce propos, il est intéressant de consulter une page du CSS Zen Garden. Je vous invite à afficher de code source de cette page.

Pour permettre aux graphistes de définir des rendus graphiques différents pour le premier, le second et le troisième paragraphe d’un groupe de paragraphes, chaque paragraphe utilise une classe différente (class="p1", "p2", "p3"). Cela parce qu’il n’est pas possible, dans les feuilles de style, d’appeler « le deuxième paragraphe par le groupe », ou bien « le dernier paragraphe ». On a donc une page codée pour un usage spécifique, usage non généralisable (que se passe-t-il s’il y a une classe "p7" non prévue par le graphiste ?), destiné à contourner une limitation des CSS.

Chaque grande partie du document bénéficie d’un identifiant (« id ») unique. Ce qui permet de traiter différemment chaque bloc, mais en même temps rend les possibilités de généralisation et d’automatisation impossibles. Si CSS Zen Garden change le contenu de ses pages, ou veut ajouter une deuxième page d’exemple, tous les CSS doivent être redéfinis (ce qui n’est vraiment pas l’idée derrière les CSS).

Le code de la feuille de style contient d’innombrables doublons, que ce soit pour des définitions de marges, mais aussi pour des définitions de couleurs. Certes cela aurait pu être codé différemment mais, comme indiqué, la norme pousse assez facilement les webmestres à définir différentes classes avec les mêmes éléments. Si le code HTML est, lui, très lisible et assez facile à « maintenir », la feuille de style ne l’est pas (c’est, dans la pratique, une conséquence très fréquente de la syntaxe des CSS).

Les intertitres, très jolis par ailleurs, sont réalisés avec des images (par exemple : « Requirements ». Ces images sont appelées par les feuilles de style, ce qui permet d’en changer en fonction de chaque feuille de style (les images ne sont pas codées directement dans le HTML). Cependant, leur appel est défini « à la main » dans la classe de chacun des intertitres. Cette méthode ne peut absolument pas être automatisée. Or, on pourrait imaginer que la définition générale des intertitres contienne l’appel à un script fabriquant lui-même cette image à partir du texte contenu dans l’intertitre (pour « <h3>Requirements</h3> », la définition de « <h3> » pourrait spécifier que le fond est une image fabriquée par un script transformant le texte en image typographique, à partir du texte compris entre ces balises, c’est-à-dire « Requirements »).

Toutes ces limitations font que, dans la pratique, il est très difficile de réellement séparer le fond et la forme.

Comme le code source de CSS Zen Garden le montre, c’est une démonstration non généralisable (pas « exportable »), parce que l’encodage est directement lié à l’effet recherché. On a à la fois des lourdeurs (un classe différente pour chaque paragraphe) et des définitions complètement liées au contenu de la page (on définit le style de tel intertitre ; ce qui, ici, donne l’effet très paradoxal suivant : on peut changer la feuille de style de la page de démonstration, mais on ne peut pas changer la page de démonstration elle-même ; le système tel qu’il est ainsi conçu, pour un vrai site (au sens : un site avec des contenus différents dans différentes pages), exigerait de définir une feuille de style différente pour chaque page du site Web !). On se retrouve souvent face à cette difficulté : il faut réellement coder ses pages d’une certaine façon pour parvenir à les contrôler finement avec des CSS ; une page Web vraiment très simple, avec une utilisation très logique et très simple (on pourrait dire « saine ») des classes, sera, justement, difficile à contrôler très finement avec les CSS.

L’utilisation principale de Javascript est le contrôle de l’interactivité, c’est donc une utilisation graphique. Javascript permet d’ailleurs, désormais, d’accéder simplement et de façon très standardisée, aux éléments contenus dans une page (DOM/Javascript). Or, en refusant par principe de lier les CSS et Javascript, on condamne les webmestres à des solutions bancales.
— La plupart des effets « de survol » sont codés dans les pages HTML par des « onMouseOver » et des « onMouseOut » qui déclenchent des fonctions Javascript nommées dans la page Web ; de fait, on se retrouve une fois de plus à devoir encoder directement l’interactivité à l’intérieur de la page Web, plutôt que de faire gérer cela par les CSS (selon la même logique que les :hover des CSS). Ainsi on constatera que les CSS Zen Garden sont très statiques, puisqu’il n’est pas possible de définir des comportements Javascript à l’intérieur des différentes feuilles de style.
— Pour éviter l’insertion de code à chaque balise du code, on peut tenter d’« atteindre » en Javascript certaines balises (par exemple, remplacer automatiquement des intertitres <h3> par leur image typographique, on se trouve contraint à utiliser des scripts très lourds (et, surtout, complexes).
— Beaucoup d’éléments de mise en page peuvent avantageusement profiter de calculs, les dimensions, positions et espacements se définissant en fonction des dimensions d’autres éléments de la page. Là encore, on est condamné à des scripts très lourds et inutilement complexes. Voici un exemple de tels « calculs » de mise en pages :


Avec Javascript, multicolonnage et multipage

(On trouvera une version nettement plus tarabiscotée de cet effet sur le site de l’International Herald Tribune.)

Cette longue explication essaie d’attirer l’attention sur une caractéristique de la « norme W3C » : une idée intéressante, qui répond à un besoin certain, mais limitée par une vision dogmatique de l’informatique. L’idée que l’on va séparer très strictement la structuration de l’information (la page Web elle-même), le graphisme (la feuille de style CSS) et l’interactivité (Javascript). Séparation qui ne correspond pas aux besoins réels du webmestre :
— le graphisme ne peut se faire réellement sans un minimum de test conditionnels et de calculs ;
— l’interactivité et le graphisme sont intimement liés.

Ce qui, dans la réalité des pages Web, se traduit par des solutions contraires à l’idée d’origine :
— les pages sont encodées en fonction des besoins des CSS, et non le contraire ;
— l’interactivité est également encodée à l’intérieur des pages (l’ergonomie n’est donc pas plus transposable que le graphisme) ;
— les CSS sont raremement un modèle d’élégance informatique, avec force redondances et lourdeurs ;
— les éventuels calculs de mise en pages se font « par l’extérieur » avec des scripts inutilement lourds, lents et compliqués.


Une « compliance »sauvage: Les recommandations s’étendent même à la taille des hotdogs, et l’usage restritif de la balise <moutarde>

DOM/Javascript, la faute aux webmestres

Évoquons maintenant une technologie qui existe, qui est implémentée, qui donne d’excellents résultats, mais qui n’est pas très exploitée... Il s’agit d’exposer non un manque technique ou une limitation dogmatique de la norme, mais un état d’esprit assez sidérant : à force de se focaliser sur le XHTML et le code « compliant », on perd de vue les possibilités intéressantes du HTML, au profit de Flash.

DOM/Javascript est la combinaison de deux techniques :
DOM, Document Object Model, standardise l’accès à la structure d’un document ; proche de l’usine à gaz, mais certaines utilisations assez simples sont valables sous tous les butineurs, ce qui permet de « manipuler » les différents éléments d’une page Web sans trop de difficulté ;
Javascript est ce vieux langage inséré à l’intérieur du HTML, et qui s’exécute chez le client.

Énormément de choses réalisées aujourd’hui en Flash peuvent être faites en HTML grâce à cela. Rappelons l’exemple de plusieurs colonnes sur plusieurs pages. On peut aussi réaliser de petites animations, ou des animations de grands blocs :


Animations de grands blocs: Une version finalisée est en ligne.

Une trifouillée de possibilités, qui devraient exciter le graphiste, mais qui se perdent dans des considérations techno-centrées et tristounettes. Alors que le DHTML (Dynamic HTML) avait provoqué énormément d’expérimentations (notamment au niveau des interfaces de navigation) de la part des webmestres, tout en se heurtant à l’époque à d’impossibles problèmes de compatibilité, la généralisation de DOM/Javascript permet de manipuler directement les styles et, pour les plus courageux, les nœuds de la structure, avec une compatibilité entre navigateurs assez simple à assurer ; pourtant, hormis un nombre sidérant de menus déroulants, le choix premier du graphiste pour animer ses pages et réaliser des navigations un tant soit peu rigolotes reste Flash.

Faut-il voir là un des dommages collatéraux des interminables pinaillages autour d’une utilisation fadasse du XHTML, les webmestres se retrouvant embringués dans des considérations interminables sur la « compliance », plutôt que sur une utilisation ludique et originale de ce qui se fait déjà ? (La consultation des forums est souvent dramatique : le webmestre qui vient demander un conseil pour ses animations se voit trop souvent imposer un « t’as qu’à faire ça avec CSS et :hover, tu peux me croire c’est vachement mieux — le tout tournant généralement aux considérations vaseuses sur MSIE qu’il est pas compliant et des conseils foireux pour des « hacks CSS » pour MSIE 5.)

On peut rapprocher cette partie des limites, évoquées ci-dessus, des CSS : ne pouvant gérer les « événements » (tels que les survols) directement depuis les feuilles de style, le recours intensif aux possibilités de DOM/Javascript impose soit de « salir » le code HTML avec une foultitude de « onMouseOver » et autres « onMouseOut » — ce qui rend la page difficile à maintenir — ou d’« attaquer » les balises depuis l’extérieur de la page à l’aide de scripts très lourds — également difficiles à maintenir, parce que quelques mois plus tard on ne sait plus trop comment ils fonctionnent...

Signalons, pour le plaisir du paradoxe, que les possibilités de DOM/Javascript, associées à certaines caractéristiques des CSS, telles que les positionnements absolus et les possibilités de masquages (display: none), embringuent très facilement les webmestres dans des constructions, impossibles avec les versions précédentes du HTML, et qui, pour le coup, détruisent complètement l’accessibilité : informations redondantes (puisqu’affichées ou masquées au besoin), structure non logique (puisque positionnement absolu)... Il y a un aspect pousse-au-crime de DOM/Javascript !

Le XHTML n’existe pas...

L’erreur la plus courante consiste à confondre, purement et simplement, le XHTML avec l’utilisation des feuilles de style (CSS). Fréquemment, les arguments en faveur du XHTML se résument à présenter la souplesse, la puissance, l’accessibilité... liées à l’utilisation de styles, en lieu et place des interminables balises qui prédominaient auparavant.

Or, et ce point est particulièrement important ici : les CSS ne définissent pas le XHTML. Les CSS s’utilisent parfaitement avec le HTML ; il n’y a rigoureusement aucune innovation en matière de CSS liée à l’adoption du XHTML. Oui, les CSS sont absolument formidables, souples, puissantes... elles rendent des services épatants (je ne détaille pas) ; mais, non, elles ne sont en rien l’apanage du XHTML.

Ce qui définit le XHTML par rapport au HTML, c’est l’extensibilité (« X »=« eXtensible »), ainsi que le définit le W3C dans sa recommandation de janvier 2000 (oui, ça commence à dater...) : « XHTML 1.0 : The Extensible HyperText Markup Language. A Reformulation of HTML 4 in XML 1.0 ».

Et c’est justement l’inexistence de ces « eXtensions » qui pose aujourd’hui problème pour vanter l’intérêt du XHTML. Aujourd’hui, ce qui existe, c’est du XHTML sans extensions - autrement dit du HTML « reformulé ». Et si l’on se limite à cela, on ne fera que confirmer la tendance de Cool Homepages : pour faire du Web sympa, passage par Flash - ce qui serait particulièrement dommageable, Flash présentant nombre de défauts rédhibitoires pour assurer une évolution saine du Web (Flash ne faisant pas évoluer le Web vers des habitudes « saines », telles que : automatismes simples, ouverture aux débutants, facilité d’interfaçage avec des logiciels libres, accessibilité et portabilité, échanges entre sites, etc.).

Revenons à CSS Zen Garden. Certes, tout cela est très joli ; mais il faut être clair : c’est une très mauvaise (si ce n’est une des pires) façon de « vendre » le XHTML : on se contente d’y réaliser, en XHTML 1.0 Strict, des choses qui sont tout aussi réalisables en HTML 4 (avec un code quasiment identique, puisque les CSS sont parfaitement utilisables en HTML 4). Le site milite donc pour un HTML propre et simple utilisant les CSS (elles, pas forcément propres et simples), mais en aucune manière pour un XHTML original (le site n’évoque d’ailleurs pas lui-même le XHTML : il met en avant les CSS).

En consultant le code source, on fera un constat supplémentaire, constat généralisable à quasiment toutes les pages qui adoptent un « DOCTYPE XHTML 1.0 Strict » : le « content-type » (le type de contenu) est défini comme étant « text/html ». Et non comme du « application/xhtml+xml », qui est la définition d’un contenu XHTML « extensible ». Cela n’est pas interdit, mais comme la recommandation du W3C l’indique, cela limite grandement l’originalité de ces pages : « The use of “text/html” for XHTML SHOULD be limited for the purpose of rendering on existing HTML user agents, and SHOULD be limited to [XHTML1] documents which follow the HTML Compatibility Guidelines. » Pour qu’une page exploite les extensions du XHTML, elle doit être en « application/xhtml+xml » (c’est le cas, déjà, pour afficher du MathML dans Firefox). De fait, si la syntaxe est bien du XHTML, dans la pratique l’utilisation se limite à une utilisable compatible avec le HTML. C’est donc une utilisation extrêmement limitée du XHTML, dont les effets, le rendu et les possibilités sont parfaitement réalisables en HTML (avec, d’ailleurs, un code quasiment identique).

On a vu perspective plus enthousiasmante.

Cela, de plus, semble lourdement influer sur l’évolution des butineurs. Comme nous allons le voir, les développeurs de butineurs n’ont, pour l’instant, proposé aucune solution utilisable des eXtensions propres au XHTML, et la référence permanente au CSS Zen Garden pousse à l’adoption quasi exclusive d’une norme définie en janvier 2000 (pour le visiteur, du Web à papa, mais avec des feuilles de style). C’est un principe assez habituel des développements du Web : une norme n’est utilisée que si les outils existent, et les outils ne se développement que si la norme est utilisée ; tant que la référence est CSS Zen Garden, alors les codeurs développent en pensant « selon » les besoins de CSS Zen Garden.

Pendant ce temps, sur Cool HomePages, c’est une déferlante de sites sous Flash, personne n’imaginant plus qu’on puisse faire des choses sympatoches avec du HTML (et c’est un tort).

Toujours sur les difficultés du XHTML à s’imposer, revenons un instant sur l’accessibilité, un des éléments les plus importants en sa faveur. Je l’ai déjà évoqué dans un article précédent, je pense que cela a été « vendu » de la pire façon possible, sur la base d’une vision dogmatique des normes. La plupart des arguments « contre » le vieux HTML étaient assez systématiquement retournables (parce qu’on peut faire du HTML crado mais accessible et du XHTML très compliant et pas du tout accessible). On peut ainsi reprocher au W3C, dans sa « promotion » des normes, d’avoir livré des validateurs indignes d’adresser la parole à un être humain. Jargoneux et abscons, ces outils ne valident que l’imposition d’une norme dogmatique, sans être ce qu’ils devraient être : des outils d’aide et de pédagogie. Pour s’en convaincre, on pourra visiter un validateur d’accessibilité, et constater la différence d’état d’esprit : conseils, indication du niveau des interventions, ton poli, description des problèmes pratiques que va rencontrer un mal-voyants... Les masochistes du code peuvent préférer se faire interpeller par un expéditif « This page is not Valid HTML 4.01 Transitional ! » (avec un point d’exclamation).

Le son, porté disparu

Parmi les grands absents du HTML (et du XHTML) : le son. Faire jouer un fichier musical sur un site Web oblige à utiliser des techniques spécifiques et, pour garantir la compatibilité entre les butineurs, à ne respecter aucune norme connue... Finalement, le simple fait de vouloir diffuser de la musique ou de la radio condamne le webmestre à (pour faire simple) installer une animation Flash dans sa page.

Quant à réaliser une chose aussi triviale que sonoriser les survols (« bip » quand on survole un bouton), cela n’est réalisable ni avec les feuilles de style, ni simplement avec DOM/Javascript.

Cela va sembler un peu compliqué, mais le W3C propose une solution : la norme SMIL (Synchronized Multimedia Integration Language). Voilà qui est intéressant, d’autant qu’un navigateur grand public est signalé comme capable de comprendre SMIL — tenez-vous bien — : Microsoft Explorer ! Côté Firefox, on ignore si SMIL sera intégré avec SVG (la FAQ de Mozilla semble indiquer que non).

On ne trouvera donc pas, avant un moment, de sites reposant sur XHTML+SMIL pour produire du son (surtout si Firefox intègre cela avec autant d’intransigeance que pour MathML — obligeant à passer en « application/xhtml » —, ou si Firefox implémente SVG sans SMIL, alors que le plug-in Adobe le permettait, ce qui ajouterait encore au difficultés de détection des versions de butineurs).

On peut voir dans cette situation un autre volet de la redéfinition de la norme (passage à XHTML). Plutôt que de privilégier la continuité, la rupture a amené les développeurs de butineurs à se lancer dans des développements énormes, selon des concepts très lourds. Jouer de la musique simplement, chose finalement assez simple si l’on utilise du HTML pas compliant pour deux sous, oblige en XHTML à recourir à des extensions lourdes : lourdes à la fois pour le webmestre, mais surtout pour le développeur de navigateur qui doit intégrer le fait de jouer un son dans le développement d’une norme complète (SMIL). On peut se réjouir, en théorie, de la naissance d’une norme qui permettra des choses très puissantes (pas uniquement faire bip quand on survole un bouton...), mais dans la pratique, il n’est pas possible de faire une chose aussi simple, et la nouvelle orientation privilégie l’entreprise qui peut aligner une équipe complète d’ingénieurs à temps plein pour implémenter la nouvelle norme (devinez...). Ce qui, par rapport au discours habituel autour du XHTML, est assez paradoxal.

Le vectoriel

Les graphismes vectoriels sont une idée absolument épatante pour le Web. Définir des graphismes par des coordonnées offre de nombreux avantages :
ils sont, à priori, légers ;
on peut zoomer ;
surtout : ils sont faciles à fabriquer avec des scripts, ce qui permet de présenter, par exemple, des informations techniques (courbes, etc.) à partir d’une base de donnée ;
très intéressant également : on peut y placer du texte facilement ; de fait, des graphismes vectoriels deviennent des éléments de navigation et d’interface ;
puisque les objets graphiques sont définis par des coordonnées, on peut modifier ces coordonnées par DOM/Javascript.

(Flash est d’ailleurs, à l’origine, un logiciel d’animation vectorielle.)

Il existe justement une norme pour cela : SVG, Scalable Vector Graphics, et elle est absolument enthousiasmante. Quand on a joué avec SVG, on n’est pas loin de penser que c’est là tout l’intérêt du XHTML, et que c’est là que se trouve l’évolution principale du Web (d’autant que, dans la logique d’Adobe et son SVG Viewer, SVG et SMIL sont liés). SVG est réellement excitant : facile à coder, facile à produire automatiquement (en PHP notamment), dans la logique du HTML (ou, évidemment, du XHTML), contrôlable facilement par Javascript, utilisant intensivement les CSS...

À lui seul SVG justifie de passer à XHTML.


Des webmestres déboussolés !: Kevin l’avoue lui-même : « avant j’avais deux passions le curling et le XHTML orienté objet, mais à présent, j’ai plutôt envie de trouver une meuf en fait... »

Mais les choses ne sont jamais aussi simples...
Le principal outil Wysiwyg permettant de fabriquer du SVG étant Adobe Illustrator, SVG est largement perçu comme un façon d’insérer des images vectorielles dans des pages Web, et non comme un grand « conteneur » multimédia fabriqué grâce à des automatismes. Ce qui donne des pages d’exemples généralement assez enquiquinantes à consulter...
Certaines démonstrations prouvant que SVG peut produire des animations « façon Flash », l’autre utilisation attendue du SVG est le « Flash killer » (un remplaçant complet de Flash), ce qui signifie que les graphistes attendent encore un éditeur Wysiwyg, à la façon de Flash, avant de s’y mettre. (Macromedia, créateur de Flash, et Adobe, créateur de SVG, venant de fusionner, ça n’est pas demain la veille.)
De fait, puisque cela n’a pas l’air bien excitant pour un graphiste (des images vectorielles peu animées, ou des animations moins faciles à réaliser qu’avec Flash), les développeurs de butineurs ne se sont pas empressés d’implémenter cette norme, alors même qu’elle est, à mon avis, la principale raison de « passer » à XHTML.

On nous promet pour très bientôt une version de Mozilla Firefox qui intègrerait SVG en standard (et non plus sous forme d’extension que l’utilisateur s’installerait lui-même). Tant que, au minimum, Firefox n’aura pas imposé cette utilisation standardisée de SVG, cette norme restera inexploitable par les webmestres.

Sachant que SVG est quasiment aussi vieux que XHTML — septembre 2001 pour la première recommandation officielle du W3C — il serait peut-être temps.

Dingue de maths

La seule autre eXtension existente qui dépend de la normalisation XHTML est MathML. Cette norme doit permettre d’afficher des formules mathématiques dans une page Web. C’est une norme tellement ancienne qu’elle est, sauf erreur, antérieure au XHTML. Sa dernière version, MathML 2.0, date de février 2001.

Mais, là encore, il n’existe pas d’implémentation standard de MathML dans les butineurs. Pas même Mozilla Firefox. MathML n’est utilisable qu’avec des extensions, à charge pour le visiteur de s’installer les logiciels nécessaires, ainsi que les polices de caractères mathématiques. Ce qui n’a rigoureusement rien évident (ces plug-ins de brouteurs ne permettant pas, d’ailleurs, au webmestre, d’être certain que son visiteur pourra ou ne pourra pas afficher les formules de mathématiques, et donc lui proposer une alternative automatiquement).

On retrouve ici le principe du serpent XHTML qui se mord la queue : il n’existe pas de butineur grand public permettant d’afficher du MathML à coup sûr, du coup :
— personne ne publie réellement des pages contenant du MathML,
— personne ne développe réellement les outils permettant de créer du MathML (notamment des traducteurs TeX vers MathML, ceux existants étant encore très insuffisants pour une utilisation réelle),
— et ainsi les développeurs de butineurs ne placent pas l’intégration de MathML dans leurs priorités.

Voici une anecdote qui illustrera mon propos, et qui permettra de faire le lien entre le présent article et l’article « W3C Go Home ».

Au cours du développement de la version 1.8 de SPIP, nous avons introduit un convertisseur de code LaTeX (une façon plus répandue et plus « humaine » de coder les mathématiques que la syntaxe de MathML) en image : SPIP extrait les formules en LaTeX et les transforme en une image de la formule mathématique.

Désireux de rentre le truc plus « Web », on a tenté de compléter cette méthode par transformation de code LaTeX en MathML, de façon à ce que les formules s’insèrent dans le texte en tant que texte MathML, et non plus en tant qu’image.

Premier obstacle : convertir du code LaTeX en MathML. Il existe un grand nombre d’outils, mais tous (absolument tous) sont inachevés. Cela est assez symptomatique : cela fait des années que MathML est défini, mais il n’est pas possible de l’afficher simplement ; ceux qui ont développé des convertisseurs se sont éreintés sur des développements inutilisables dans la pratique. Que ce soit en PHP ou en script sur un serveur, tous les outils ont donné des résultats très incomplets (on trouve même un convertisseur en javascript, mais là c’est encore pire). C’est le serpent qui se mord la queue déjà évoqué : pas d’outils pour fabriquer le format donc pas d’implémentation dans les navigateurs, pas d’implémentation donc pas d’outils.

Ensuite, parvenir à afficher, dans un butineur sur lequel on a installé un plug-in MathML, du MathML. C’est là qu’on constate l’intégrisme des implémentations. Sous Mozilla, l’affichage de MathML n’est accepté qu’avec un « content-type » (évoqué ci-dessus) de type « application/xhtml+xml » ; or, avec ces content-type, Mozilla suit la recommandation aberrante du W3C qui consiste à refuser une page à la moindre erreur de syntaxe HTML (ou plutôt : XHTML) — merci les enfants. Par ailleurs, ces « content-type » ne sont pas forcément acceptés par tous les butineurs grand public ; ces butineurs vous proposent de télécharger une telle page Web, et vous demandent avec quelle application l’ouvrir. Le problème est contourné en installant un javascript (un peu lourd par ailleurs) qui analyse la page Web, « isole » les parties en MathML, et permet de tout de même les afficher, quel que soit le content-type. Le choix de limiter l’affichage de MathML à un content-type intolérant n’est donc pas pratique, mais relève d’un choix quasi-idéologique.

Cela fait (en notant qu’à chacune des étapes précédentes, cela fonctionne déjà couci-couça avec des solutions bancales), il faudrait encore pouvoir déterminer, pour chaque visiteur, s’il a MathML installé sur son butineur (dans ce cas on lui envoie la version en MathML) ou non (dans ce cas on lui envoie la version « image »). Mission impossible : de toute façon les installations de MathML sont tellement problématiques qu’on a même des plug-in installés dans le butineur, mais sans les polices de caractères mathématiques, donc un affichage totalement illisible.

D’autres loufoqueries liées au charset, mais à la longue, le truc est déjà bâché.

Nous avons donc :
— une syntaxe qui nécessite l’utilisation d’outils spécifiques pour la créer (parce que, contrairement à la syntaxe de LaTeX, la syntaxe de MathML ne permet pas qu’on code une formule de mathématiques « à la main ») ; ces outils sont incomplets, puisque les navigateurs ne permettent pas facilement un affichage (même pas un affichage conditionnel : il n’est pas possible de déterminer si MathML sera affiché correctement ou non) ;
— la rupture totale d’avec le HTML, pour adopter une version extrêmement restrictive du XHTML strict (l’implémentation suit la recommandation du W3C : à la moindre erreur, la page ne s’affiche pas) ; or, puisqu’il est possible de « ruser » avec un peu de javascript, le choix d’un comportement intolérant aux erreurs n’a rien d’une obligation technique ;
— devant autant de limitations, l’implémentation de cette norme dans d’autres outils (comme SPIP) est reportée à des jours meilleurs.

Se pose alors la question suivante : pourquoi a-t-on une telle rupture dans la norme précédente (c’est le sujet du précédent article), avec obsolescence programmée et pinailleuse des tags HTML, alors même que les implémentations de la nouvelle norme sont soit inexistantes, soit inapplicables en pratique ? La rupture ne concerne donc pas que la « courbe d’apprentissage » évoquée dans l’article évoqué, elle est aussi dans le développement des outils : là où des outils existent pour afficher du MathML à l’intérieur du vieux HTML (y compris pas très compliant — MathML est réellement un langage de description très ancien), tel que le plugin MathPlayer, les nouvelles implémentations respectueuses de la norme limitent l’utilisation à un type de document très intolérant (nous l’avons signalé : même CSS Zen Garden passe un « content-type » qui interdit d’afficher du MathML).

Résultat : pas de MathML. (C’est même pire : ces traquasseries donnent le résultat suivant : la solution la plus simple consiste, en pratique, à développer son site pour Microsoft Explorer sous Windows, en demandant à ses visiteurs d’installer le plug-in MathPlayer. Sauf erreur, c’est exactement l’inverse de ce pourquoi le W3C existe.)

Reprenons. Les recommandations du W3C qui, réellement, utilisent l’eXtensibilité de XHTML et qui représentent un réel intérêt pour les webmestres, sont presque aussi anciennes que XHTML ; pourtant, elles ne sont implémentées en standard dans presque aucun des navigateurs de nouvelle génération (le moins à jour étant Firefox, qui sert de référence aux webmestres). Ce qui fait que, dans la pratique, il n’existe pas d’extension du XHTML, et l’utilisation du XHTML se limite aujourd’hui à ce qu’on peut tout aussi bien réaliser en HTML.

Quant à pleurer sur les limites des feuilles de style de Microsoft Explorer, c’est passer à côté du problème. Les butineurs présentés comme super-compliants (en gros : tous sauf MSIE) n’intègrent pas plus qu’Explorer les normes justifiant le passage au XHTML, normes pourtant définies il y a quatre ans. Pour vraiment être clair, faire la promotion de XHTML uniquement autour des CSS, c’est nuire à cette norme, qui ne deviendra réellement intéressante pour les webmestres qu’avec SVG, SMIL et MathML. Nuisible, car on démotive les webmestres avec des considérations pinailleuses, dans le but de leur faire coder « proprement » des pages qui, visuellement, peinent à dépasser ce qui se faisait déjà en 1998 ; nuisible car les développements de navigateurs (Firefox, Opera, Konqueror/Safari...) tardent franchement à implémenter ces normes vieilles de plusieurs années ; nuisible enfin parce que le grand public ne se voit jamais exposer l’intérêt réel de ces normes pour lui (quel magazine de presse informatique grand public a signalé à ses lecteurs que Opera 8 intégrait SVG en standard).

Les polices de caractères

Continuons avec nos lamentations de webmestre malheureux (malheureux puisque, vous l’avez compris, je ne peux pas me résoudre à faire avec Flash ce que je devrais pouvoir faire en HTML depuis belle lurette). L’autre sujet qui fâche dans le HTML (et, encore une fois, dans le XHTML), c’est qu’il n’existe pas de méthode normalisée pour y intégrer des polices de caractères.

Or, pour un graphiste, le choix de la police de caractères est l’une des premières méthodes pour créer l’ambiance de son site Web.

Là aussi, on trouvera des puristes pour assurer que (blah blah blah) le HTML n’est pas fait pour cela. Pour se convaincre du contraire, il suffit de constater que la moitié des exemples du fameux CSS Zen Garden utilisent des images pour réaliser les titres et les intertitres (voici un exemple parmi tant d’autres. L’utilisation d’un style CSS un peu particulier permet de ne pas afficher un <img src=...> dans le code source, mais ce sont bien des fichiers graphiques qui sont utilisés pour effectuer le rendu typographique si particulier (rien à voir, en tout cas, avec une « beauté » intrinsèque aux CSS).

Au rayon HTML/XHTML, on ne trouvera aucune norme ni recommandation. Il n’existe, côté « fontes embarquées », que des méthodes tordues à peu près inutilisables et totalement propriétaires. SVG, format vectoriel, permettra-t-il de contourner l’obstacle ?

C’est en tout cas encore un de ces aspects étonnants des développements du Web, axé sur des considérations techniques qui échappent au commun des mortels, au détriment des besoins simples des webmestres et des graphistes.

VRML, RIP

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.

Outre les modèles 3D complexes, il existe un besoin plus « automatisable » : les interfaces graphiques. On trouve ainsi, souvent, des animations Flash en fausse 3D (les possibilités 3D de Shockwave ont, en revanche, fait long feu) ; et on simule souvent un effet de relief (3D) pour présenter une information 2D. Techniques utilisables sur un site Web sans investir dans le développement d’un concurrent à Doom 3...

On dispose d’une norme XML, donc à priori promise à être utilisable en XHTML : X3D. Quant à l’implémentation en standard dans un navigateur grand public, à vue de nez vous pouvez attendre la dernière trilogie Star Wars (épisodes 7 à 9) pour plus tôt.

Flash versus XHTML

Comme je l’ai signalé en introduction, Flash est omniprésent dans les sélections de sites « beaux », et les graphistes y recourent dès qu’ils veulent réaliser une ergonomie un tantinet originale. Et la stagnation du HTML depuis quelques années, l’attente interminable de techniques qui n’arrivent toujours pas, devraient encore plus inquiéter de l’avenir d’une norme ouverte.

Cependant, même en ne se reposant pas sur la promesse de techniques promises mais pas encore exploitables, certains points sauvent le HTML du naufrage. Comprenez bien : le but du présent article n’est pas de comparer le XHTML et Flash (si vous êtes arrivé jusqu’ici, vous avez constaté qu’il n’est pas du tout consacré aux caractéristiques de Flash) mais, avant de conclure, de se demander pourquoi Flash n’a pas encore totalement supplanté un HTML qui peine à évoluer depuis plusieurs années.

Il est important d’éviter, coûte que coûte, le basculement complet vers Flash. Flash, en effet, n’est pas à même d’assurer une évolution du Web vers des habitudes « saines » : les pages sont « fermées » (les visiteurs ne peuvent pas apprendre en consultant le fonctionnement intrinsèque des autres sites, comme on le fait en consultant le code source du HTML), Flash n’est pas du tout accessible aux mal-voyants et aux non-voyants, Flash est très difficile à interfacer avec des logiciels libres, Flash ne promeut pas les échanges entre les sites, un site réalisé comme une grosse animation Flash n’est pas indexable et ne propose pas de « portes d’entrées » permettant de linker de l’extérieur des articles spécifiques, etc.

Mais ce ne sont pas ces considérations qui, dans la pratique, limitent le développement de Flash (ce genre d’arguments n’a d’impact que sur un nombre limité de webmestres à l’éthique janséniste sévère !). Plus prosaïquement :
— HTML reste infiniment plus simple que Flash pour publier vite et bien des documents textuels ; et cela, même, avec un contrôle typographique plutôt puissant grâce aux feuilles de style ; une chose aussi simple que mettre son CV en ligne, avec Flash, est long (pour une entreprise : cher) ;
— il est beaucoup plus simple de créer un site HTML avec des outils de gestion de sites qu’un site Flash ; interfacer Flash à une base de données n’est pas à la portée de la première bourse venue ;
— si cela peut paraître paradoxal, de part ses limitations, HTML tolère, visuellement, beaucoup mieux les petites approximations graphiques (images mal traitées, petites erreurs typographiques, placements pas toujours élégants des images...) qu’une page Flash où la « perfection » graphique qu’autorise le format rend les mêmes défauts graphiques impardonnables ; dit autrement : l’exigence visuelle que l’on a d’une page Flash fait que l’intégralité du site doit, quasiment, être réalisée par un professionnel, là où le HTML réalisé par des amateurs pourra tout à fait sembler « professionnel ». Cette exigence graphique allourdit encore les coûts d’un site en Flash ;
— un site en Flash repose toujours sur du HTML, du XHTML et/ou du XML pour s’interfacer avec une base de données, fournir un feed RSS, etc. ; de fait, alors qu’on peut parfaitement réaliser un site très pointu avec le HTML sans développer la moindre compétence en Flash ; à l’inverse, un site très pointu en Flash impose d’excellentes compétences dans les autres formats. Dans tous les cas, l’apprentissage passe par les formats « texte » ;
— tout de même, l’accessibilité est un point important pour nombre de webmestres hérétiques, ne serait-ce que pour les associations, les administrations et les services publics, qui représentent un volume important des publications en ligne.

Deux autres éléments ont beaucoup joué, également, pour continuer à promouvoir un HTML devenu assez plan-plan :
— la généralisation de PHP sur les hébergements grand public ; une bonne partie de ce que les normes ne font pas (ou pas encore) du côté des navigateurs, est réalisé grâce à PHP du côté du serveur ; des choses anodines comme le redimensionnement et le placement des images, la création d’images typographiques, enrichissent considérablement les mises en page (permettant d’automatiser ce qu’on faisait « à la main » précédemment, et qui était peu viable sur un site aux mises à jour régulières) ; le contrôle des logiciels clients permettent d’affiner ce qui est envoyé au visiteur ; citons aussi les feuilles de style modifiées avec PHP, pour palier les manques des CSS (changer automatique toutes les couleurs dans une feuille de style, inverser « right » et « left » pour faire fonctionner une même feuille de style en affichage « Droite à gauche » comme en arabe...) ;
— le développement des CMS libres a mis à disposition du grand public ces automatismes, permettant le développement de « gros » sites, entièrement basées sur le HTML (et non sur Flash, le développeur d’un logiciel libre n’allant pas, par définition, privilégier un format propriétaire).

Pour beaucoup d’entre nous, c’est de ce côté que se sont déroulées les évolutions « rigolotes » et excitantes, que l’on peut attendre d’un média jeune comme l’internet, alors que le HTML, lui, n’a pas évolué dans le même temps. Il serait temps que le plaisir de « faire » de l’internet passe aussi par le HTML, comme ce fut si longtemps le cas.

ARNO*

format impression

ARNO*

Vainqueur 1982 du concours « Chateau de sable » du Club Mickey des Pingouins à Sainte-Cécile.

Flip-Zone

31 juillet 2002

Petit guide typographique à l’usage de l’internet

28 septembre 2003

W3C go home !

30 août 2001

Qu’est-ce qu’un troll ?

4 juillet 2002

La lecture facile à l’écran

1er octobre 2001

La régulation était fermée de l’intérieur

6 octobre 2003

Le Blues du businessman

17 septembre 2000

Pourquoi critiquer l’action de l’UEJF et de la Licra ?

> Le HTML dans le potage

22 août 2007, message de stefdn

Bonjour,
Chanson trouvée sur Standblog après la lecture de ce très bon article. Je crois que je vais la mettre en "bgsound"...

en ligne : Chanson CSS

> Le HTML dans le potage

26 novembre 2006, message de coratogia

finalement je dois comprendre que mon projet de site "musicologique" (basé sur MySql, Php et "un" player ...a du chemin à tracer !

en particulier autant le rayon "images" est pléthorique autant la manipulation agréable et performante de petits bouts de Mozart ou de Rameau est , encore’ un parcours du combattant.

cela me désole car je trouvais que des bonnes choses sur le chemin des outils dits libres.

effectivement "entrer dans le flash et n’en sortez plus" est innacceptable.

quel player serait envisageable ?? (avec peu de skill en coding pointu)

en attendant , merci pour votre topo

> utiliser d’autres polices

17 octobre 2006

http://www.grafactory.net/blog/2003/11/18/9-des-beaux-titres-a-la-volee-avec-gd

Pour la conception d’un site, on est toujours limité dans le choix des polices de caractère aux polices de périphérique (Verdana, Times, Georgia...). Donc, c’est souvent pratique ce petit truc avec la librairie graphique GD qui permet de créer des images de texte à la volée.

Par exemple sur un site ou les titres sont dans une police un peu "originale" (voir les exemples à la fin) cette technique évite de créer toutes les images correspondantes aux textes dans photoshop. Encore plus pratique quand le site est multilingue car les textes des images sont traduits à la volée. Au lieu d’avoir 50 images, on a seulement un fichier !

Voici en gros ce que ça donne, à modifier à votre convenance. On passe la taille de la police et le texte du titre en paramètre

On intègre les images avec un simple

Et le fichier titres.php

<? header("content-type: image/png"); if (empty($s)) { $s = 22; } //la taille du texte on peut la passer en paramètre //la police de caractère à placer dans un repertoire accesible en écriture en (ici /font/) $font= dirname($_SERVER['DOCUMENT_ROOT'].$_SERVER['SCRIPT_NAME'])."/font/arial.ttf"; $size = imagettfbbox($s,0,$font,$text); // taille de l'image $dx = abs($size[2]-$size[0]); $dy = abs($size[5]-$size[3]); $xpad=5; //espacement x $ypad=18; //espacement y $im = imagecreate($dx+$xpad,$dy+$ypad); $white = imagecolorallocate($im, 255,255,255); $blue = imagecolorallocate($im, 129,35,69); imagettftext($im, $s, 0, (int)($xpad/2), $dy+(int)($ypad/2), $blue, $font, $text); imagepng($im); imagedestroy($im); ?>

en ligne : http://www.grafactory.net/blog/

> Le HTML dans le potage

3 octobre 2006, message de LeBen

Je pense qu’il faudra se tourner vers la technologie AJAX pour des amélirations graphiques sans environements prioritaires ... AJAX qui est une utilisation conjointe d’un ensemble de technologies couramment utilisées sur le Web : HTML (ou XHTML) pour la structure sémantique des informations, CSS pour la présentation des informations, DOM et JavaScript pour afficher et interagir dynamiquement avec l’information présentée, l’objet XMLHttpRequest pour échanger et manipuler les données de manière asynchrone avec le serveur web et le XML - XSLT

j’ai pas eu le courage de tout lire, dez, vachement long l’article !

travail sympa en tout cas, je trouve qu’il y en a qui se la pète grave et qui ont la critique bien facile alors que ça doit être des banquignoles incompétents ou juste arrogants ...

keep on moving

> Le HTML dans le potage

15 août 2006

Les photos sont biens ! D’ailleurs c’est à peu près ça !

Je suis développeur et informaticien depuis bien longtemps et j’avoue sans honte ne pas faire de w3c. Pourquoi ?

Entre le hamburger sauc ketchup (ou la cuisine mondialisée style W3C ) j’aime autant offrir à ceux qui me font confiance un cassoulet à la graisse d’oie.

Le pur W3C c’est la page d’accueil de Spip.net ! Pas très jojo et c’est bien dommage pour un CMS de cette qualité..Si Spip c’est la fameuse saucisse de tout à l’heure et le site le pain et le ketchup W3C, je prétends garder la saucisse, mettre des haricots blancs flash, de l’ail HTML et des balises graisse d’oie ! Bref c’est lourd, c’est beau, c’est bon et ça plait toujours..

Finalement après la mal bouffe, la mondialisation, le W3C, l’Euro, il ne manque plus que des informaticiens génétiquements modifiés !!

> Le HTML dans le potage, MKe, 21 septembre 2006

Vraiment nawak comme comparaison, àmha.
On pourrait plutôt comparer les standards à l’Espéranto - mais un espéranto en passe de réussir à s’imposer, en l’occurrence.

Et si la page d’accueil de Spip est tristoune, ça n’a rien à voir avec le w3c...

Quelques exemples sympathiques, mitonnés aux petits oignons http://www.w3csites.com

en ligne : W3Csites are neat

> Le HTML dans le potage

29 juillet 2006

Merci ARNO* pour ce très bel article bien argumenté et bien plus constructif que W3C Go home que tu commis de manière plus impulsive :-).

Le W3c devrait se remettre en cause pour nous aider à faire des sites plus aisément multi-média sans retomber sur le html d’antan.

> Le HTML dans le potage

16 mai 2006, message de malandrin

je cite : « Flash n’est pas indexable et ne propose pas de « portes d’entrées » permettant de linker de l’extérieur des articles spécifiques, etc. »

Un site dynamique développer (comme il se doit) en actionscript utilisera forcement des fichiers xml pour récuppérer le contenu d’une bdd. XML pas indexable ? N’est-ce pas l’interet des normes que tout le monde se comprenne ? Que de foutaise sur ce site. Et je me marre en voyant le code source de la page.

Trollez bien ... See u

> Le HTML dans le potage

7 mai 2006

Je sais bien, votre article date du 23 mai 2005, mais juste pour info : quand vous dites...

"un site réalisé comme une grosse animation Flash n’est pas indexable et ne propose pas de « portes d’entrées » permettant de linker de l’extérieur des articles spécifiques, etc."

Déjà utilisable en 2004 sur google, la possibilité de rechercher des fichier flash :

swf:cequevousvoulez

En ce qui concerne le "linkage" vers des articles spécifiques sont tès facile à réaliser, à l’aide de variables récupérées par le fichier flash (monfichier.swf ?mavariable=) (google ou yahoo accepte 2 variables dans l’url).

> Le HTML dans le potage

6 mars 2006, message de Alarc’h

Oui tout ceci exprime bien pas mal de frustrations que je rencontre au quotidien sur le web.

Parce que sur le web il y a tout le monde, et aussi des gens comme moi qui se foutent un peu de l’habillage et du code du moment qu’il y a un riche contenu. Et dans ce sens, flash est assez synonyme pour moi d’esbrouffe pour faire joli, mais qui ne sert à rien (mais j’avoue que je n’ai pas poussé beaucoup sur le sujet, je donne une réaction brute d’internaute).

En gros pour les gens de mon espèce l’important c’est de pouvoir publier fracilement sur le web ce qu’on a à dire, sans avoir à se prendre la tête. Et je préférerais toujours un site crado plein de contenu intéressant, à une jolie coquille vide, mais qui arbore toutes ses vignettes W3C... Bien entendu si on a à la fois la "propreté" et le contenu, tant mieux.

Et pour détendre l’atmosphère bien lourde de ce débat, un point de vue un peu ironique sur ces "grands problèmes" :

en ligne : Le web, ses standards et la pensée théologique

> Le HTML dans le potage

27 février 2006, message de e-maje

Pourquoi les sites graphiques sont-ils essentiellement en Flash ?

La réponse est évidente et crève les yeux, même de ceux qui ne veulent pas voir :

Les pages flash sont affichées de la même façon quelque soit le navigateur.

Il n’est pas obligé que la fonte utilisée se trouve sur l’ordinateur du lecteur de la page internet.

Pas la peine de jongler avec un langage informatique quelconque pour que votre mise ne page soit alignée au pixel prêt. Tout se fait de visu (je n’aime pas l’usage intempestif de l’anglais...)

Flash est souvent réservé aux purs graphistes, là où se perdent dans le code des informaticiens purs et durs habitués à mettre les mains dans le cambouis... Mais en celà je les rassure l’actionscript est là pour eux...

Les œuvres sont aussi mieux protégées et évite un pillage maintenant monnaie courante sur internet...

La liste est longue...

Maintenant pourquoi le html résiste-t’il ainsi ?

Là aussi la réponse est facile à trouver : les entreprises informatiques et les autres engagent dans leur majorité, pour des postes de conception de sites internet, des diplômés d’écoles informatique où le code et les marhématiques sont inculqués comme étant le summun de ce que peut apporter la technique. Dans ce choix le graphiste est relégué au rang de subalterne...

Je suis en informatique ce que beaucoup appellent un dynosaure. J’ai commencé l’informatique en 1972, mes premières lignes de code je les ai tapées sur des cartes perforées... Dos faisait ses débuts et windows était loin... Tout çà pour dire que je sais de quoi je parle...

Il n’est venu à l’idée de personne que le summum de l’informatique c’est qu’il soit transparent ? Que l’utilisateur final ne voit rien des efforts de programmation ? Que l’utilisation des programmeurs ne devrait-être qu’en amont de l’utilisateur ? C’est pourtant ce que l’OS de mac, Windows et toutes les autres interfaces graphiques qui ont suivis devaient en être : des précurseurs.

Mais la plupart des décideurs sont issus d’écoles techniques ou commerciales ou l’ingénieur est plus représentatif que le graphiste. Il est évident pour ces personnes que ce dernier n’apporterait moins de profits que ’l’ingénieur... C’est uniquement pour cette raison que nous sommes encore à l’âge de pierre dans l’internet... Il faut laisser les programmeurs à leur place en amont de l’utilisateur et laisser les graphistes faire ce pour quoi ils sont doués : créer des œuvres d’art !

Ce que devrait être la conception internet de demain ?

Des graphistes utilisant des logiciels graphiques où l’effort de programmation aurait été si intense et si bien pensé en amont qu’aucun utilisateur n’aurait à connaître le moindre morceau de code quel qu’il soit et que seul l’œuvre graphique serait leur seule préoccupation...

Dans l’instant et dans ces lignes je n’ai vu que la préoccupation de préserver des acquis, de préserver un domaine que vous avez volé aux graphistes. Pour innover, comme vous semblez le souhaiter, il vous faut être en amont, construire des logiciels où le langage informatique serait entièrement transparent. Des logiciels comme Flash justement demandant à être encore améliorés pour que la programmation qui reste encore visible en soit totalement évincée.

Vous êtes des accros aux langages, soit, aux langages liés à internet, soit, alors faites qu’ils soient si puissants que seul le clic du créateur reste.
En un mot vous vous trompez de combat, l’internet de demain ne doit pas se conjuguer en code limitateur de création qu’est la connaissance de langages multiples de programmation (perl, ASP, Coldfusion, C++, Java, html, dhtml, xhtml, xml,... et même action script) mais en code si transparent, si puissant que lui seul serait capable de transender la création !

Mon propos peut paraître agressif, j’en convient, mais il faut de temps en temps recadrer. L’informatique n’est pas une fin en soit, l’informatique ne doit être et rester qu’un outil, ce que qui a été largement oublié dans ces lignes...

Si je suis venu sur ce site, c’est simplement qu’il est donné en exemple pour l’utilisation du logiciel SPIP. Ce qui me ramène à mon exposé : ce type de réalisation est et doit rester le but de tout programmeur : être le plus transparent possible à l’utilisateur.

Et les utilisateurs ce n’est pas vous, mais ceux qui justement ne connaissent rien à la programmation et qui ne devraient jamais en avoir besoin, parce que vous avez été très bons.

Cordialement.

> Le HTML dans le potage, pX, 9 mars 2006

Juste mes deux cents, pour répondre à cette réponse :

Il n’est venu à l’idée de personne que le summum de l’informatique c’est qu’il soit transparent ? Que l’utilisateur final ne voit rien des efforts de programmation ?

Je crois que justement, on en parle suffisament pour qu’on ne puisse pas dire ça. Oui, c’est venue à l’idée d’autres que vous. On réfléchit, aussi, vous savez ?

Que l’utilisation des programmeurs ne devrait-être qu’en amont de l’utilisateur ?

? J’ai du mal à vous suivre... Déjà c’est bizzarement rédigé... Supposons que vous ayez voulu dire quelque chose comme "d’abord on code le truc, et qu’après il n’y a plus que l’utilisateur qui "utilise" le produit dudit code"... Heu... Vous avez lu l’article ? Ca parle de pages web. Par définition, le code va changer.

Et quand bien même, comment envisagez-vous cet eden ? Le mien, de Paradis (tant qu’on est dans les limbes, reston-y) c’est un monde où il n’y a plus de programmation. Où les ordinateurs font ce qu’on leur demande parce qu’on leur a demandé en humain. Ou non tiens, ya plus d’ordinateurs, on est devenu aussi forts qu’eux pour faire des trucs pénibles. Je n’aurai d’ailleurs plus de boulot, mais c’est un détail.

Ce qui m’échappe, c’est comment vous arrivez à faire rentrer l’utilisation de technologies propriétaires dans ce cadre (les programmeurs avant les utilisateurs) ? Non décidément, ça m’échappe totalement. Et pourtant je suis les deux ! Programmeur (Oh, si peu) et utilisateur (grave) !

C’est pourtant ce que l’OS de mac, Windows et toutes les autres interfaces graphiques qui ont suivis devaient en être : des précurseurs.

Ca aussi, je ne comprends pas..? Et mon Amiga3000 (qui va très bien depuis 1990, merci), là, c’est quoi ? MacOS et Windows, des précurseurs ? Et ce que ces aneries ont à voir avec le potage ?

Maintenant pourquoi le html résiste-t’il ainsi ? (en gras, genre titre, NDR)

Là aussi la réponse est facile à trouver : les entreprises informatiques et les autres engagent dans leur majorité, pour des postes de conception de sites internet, des diplômés d’écoles informatique où le code et les marhématiques sont inculqués comme étant le summun de ce que peut apporter la technique. Dans ce choix le graphiste est relégué au rang de subalterne...

Ce truc n’a rien à voir avec la réalité.

"des diplômés d’écoles informatique" ? Vous ne devez pas fréquenter beaucoup de boites qui font du site web (on dit web-agency, et moi aussi ça m’énerve).

Là aussi, ça m’épuise d’avance de me justifier, je préfère relire l’article ci-dessus, le passage qui parle de l’impossibilité pour un site Flash d’être réalisé par autre chose qu’une entreprise payée pour ça (sans ressembler à un immonde truc carrément buggé, ce qu’aucun site en HTML ne sera à ce point). Renseignez-vous, celui qui bosse le plus, dans ce genre de site, c’est justement le graphiste.

Donc ça, dans cette acceptation :

Ce que devrait être la conception internet de demain ? (en gras, genre titre, NDR)

Des graphistes utilisant des logiciels graphiques où l’effort de programmation aurait été si intense et si bien pensé en amont qu’aucun utilisateur n’aurait à connaître le moindre morceau de code quel qu’il soit et que seul l’œuvre graphique serait leur seule préoccupation...

Dans l’instant et dans ces lignes (l’article d’Arno, NDR) je n’ai vu que la préoccupation de préserver des acquis, de préserver un domaine que vous avez volé aux graphistes.(...)

C’est carrément n’importe quoi, ça. De l’étude du problème aux propositions de résolution, c’est n’importe quoi.

Bon, on passe totalement à coté du sujet, là ! C’est justement ça le but, au final, de "transcender la création", même si d’autres utilisent un vocabulaire un peu plus heu, disons technique ;)

Alors c’est facile après de dire "Flash c’est bien pasque c’est transparent" sauf que Flash *appartient* à une société privée c’est si difficile à comprendre ? Il pourra faire les choses aussi bien qu’il veut, et aussi "transparentes" (hum) tant que ce ne sera pas un standard de l’ordre de ce que prétend être le (x)HTML, ça ne vaudra pas un pet de lapin !

C’est tout, c’est uniquement ça, avoir le choix.

Je ne vais pas vous balancer mon CV, ça me fatigue d’avance, et même, je me demande comment on peut prétendre "savoir de quoi on parle" en commentaire d’un article évoquant TANT de technologies différentes, sans parler de celles qu’impliquent lesdites technologies. Je suis dans ce business depuis trop longtemps déjà, et plus ça va, et moins je je peux dire sans être certain de dire une connerie aussi grosse que moi "je sais de quoi on parle".

j’aimerai juste dire que j’ai vraiment beaucoup apprécié cet article, remarquablement documenté, linké, argumenté et drôle, et que moi aussi, plus je vois de sites en flash, à fortiori "beaux" et ergonomiques (heureusement c’est rarissime, voire inexistant) plus j’ai envie de m’arracher une barette de RAM.

en ligne : hallucinet

> Le HTML dans le potage, Mr. Voyer V., 10 avril 2006

Euhh pour les polices sous linux si tu n’as pas installé les polices windows tes animations flash tu peux leur dire byebye.
Il faut se placer du point de vue libre et propriétaire.
Exemple shocwave sous linux = interdit.

en ligne : Wouaren s’enmerdre au boulot et est valide xhtml1.1 hyper strict

> Le HTML dans le potage, Calvus Mons, 16 mai 2006

Ce que devrait être la conception internet de demain ?

Des graphistes utilisant des logiciels graphiques (...)

Désolé, mais cette approche est complètement idiote. Heureusement, Internet n’est pas uniquement le terrain de jeu de graphistes. Le texte y est extrêmement important et bien traité (cf les expériences Wikipédia, Wiktionary par exemple), et pour cela Flash est un nain. Tout le système hypertexte est conçu pour pouvoir effectuer des liens entre des pages et sous-pages d’un site Web. Or un site Flash n’a qu’une adresse http par définition, alors accrochez-vous pour y effectuer des liens à l’endroit que vous voulez ! Quant à copier-coller un bout de texte, macache.

Nous sommes en 2006... et je lis encore des trucs comme ça.

> Le HTML dans le potage, Lanza, 2 février 2007

Ce que devrait être la conception internet de demain ?

Des graphistes utilisant des logiciels graphiques[...]

Oué, mais non.
Le Web, c’est pas du graphisme, c’est du contenu.

Un peu d’espoir ?

11 novembre 2005, message de Damien Ravé

Je suis désolé de lire que l’on puisse perdre son enthousiasme en matière de design web. Il y a tant de choses à faire et de sujets à explorer !

Je ne suis pas du genre "idéologue", plutôt pragmatique. Le XHTML strict en soi, c’est certes pas exaltant, mais autour de ça, il y a des choses qui commencent à apparaître et qui peuvent redonner une vivacité au développement "non flash". Il me semble qu’il y a un mouvement d’ensemble dans l’adoption de XML/XHTML-CSS-DOM-Ecmascript au sein des navigateurs qui élargit les possibilités par petites touches et ça me paraît positif.

Je pense en particulier à Ajax, qui existe grâce au développement du DOM, de XML et de Java/Ecmascript. Ça ouvre des perspectives en remettant en cause le principe de chargement successif des pages. Je travaille actuellement à un jeu de stratégie basé sur ce système et c’est autrement plus "dynamique" que simplement PHP+HTML où il faut recharger toute la page à chaque action. Ce n’est certes pas forcément 100% mature, mais prometteur. Et son adoption par Google (GMail, GoogleMaps) va jouer en faveur d’une standardisation rapide.

Par contre je partage l’avis selon lequel il y a des choses dans les CSS qui pourrissent la vie au quotidien, et qui mériteraient une amélioration pour faciliter leur usage et concurrencer Flash sur son propre terrain :
incorporation des polices de caractères (CSS 3 ? Quel siècle ?) et antialiasing débrayable.
multiples bordures + backgrounds + ombres portées
Sans compter des fonctions de positionnement aussi simples conceptuellement que les tables (pour aligner un layer au centre, il faudrait pouvoir spécifier horizontal-align : center ;). Soyons réalistes, dans un contexte purement économique (càd non "artistique", cf. CSS Zen Garden), la guerre TABLE contre DIV sera vraiment gagnée uniquement lorsqu’il sera possible de faire des positionnements 3 colonnes en DIV en quelques minutes, comme c’était possible avec les tableaux...

Quant aux :hover, ils sont déjà de l’ordre du behavior, pas simplement du graphisme. Pourquoi alors ne pas aller à fond en intégrant du comportement dans le CSS, et les utiliser pour déclencher des déroulements de menu, ou agir sur un autre élément (quand je passe sur le bouton, l’élément enfant devient visible) ?

Enfin, pour aller dans le sens d’Arno sur l’idée d’introduire des tests conditionnels et du calcul dans le CSS, je serais tout excité à l’idée de définir des variables à réutiliser (pour régler la largeur d’un élément par rapport à celle d’un autre), et pourquoi pas de disposer de variables sur le client (WINDOW_WIDTH pour la largeur de la fenêtre par ex.).

Existe-t-il un site où les webdesigners pourraient recenser leurs doléances à l’intention des fabricants de navigateurs ? Histoire de voir ce qui est le plus activement demandé... Si ça existe pas, y’a un truc à faire, non ?

> Un peu d’espoir ?, keusta, 18 novembre 2005

moi je suis bien d’accord avec toi, il ya quelquechose a faire.. le webdesign ne doit pas etre une contrainte mais un plaisir et se heurter à chaque fois à des heures de débuggages parceque tels plateforme ou tel navigateurs n’affichent pas le même résultat c’est quelquefois déroutant ...
donc si tu veux lancer l’initiative, je te suis !!

> Un peu d’espoir ?, Damien Ravé, 2 janvier 2006

Il y a des petites choses qui existent, pour les anglophones. En parcourant le site http://www.webstandards.org (un groupe de webdesigners qui vont boire des cafés avec les programmeurs de Microsoft, donc des gens sérieux) je suis tombé sur le blog des développeurs d’IE7. J’ai à peine entamé la lecture des milliards de contributions sur la page où ils abordent les fonctionnalités pour les webdesigners (cf. lien).

Peut-être qu’il est un peu tard (le post date de juillet), peut-être que c’est has been de développer des sites en pensant à un navigateur qui ne représente que 85% des visiteurs, mais c’est dans ce genre de situations que les designers peuvent espérer apporter une pierre. Et on y apprend déjà des trucs rassurants sur le respect des standards par Microsoft (même si la question de la compatibilité descendante va demeurer). A vos Harrap’s !

en ligne : Lire le post "CSS" du 29/07/2005 sur le Blog d’IE7

> Le HTML dans le potage

9 novembre 2005, message de keusta

c’est bien beau tout ça mais il ya trop de défilement à éffectuer pour lire le texte, un sommaire qui permettrait d’accéder aux différents points que tu abordes ainsi qui lien vers le haut de page...

en ligne : mon site

> Le HTML dans le potage, 20 janvier 2006

Pour quelqu’un qui critique un design propre comme celui-ci, je trouve ton site bien peu ergonomique (couleurs des menus trop sombres, scroll horizontal, polices trop petites...)

this site is not W3C compliant ?

5 novembre 2005, message de phroy

Cette article vante les bienfaits de la normalisation , or sur la page d’accueil d’Uzine on peux voir la promotion l’attitude inverse (this site is not W3C compliant).

Est-ce une erreur de jeunesse (pulsion rebelle autonomiste, esprit de contradiction borné, niveau de compréhension faible des premiers apprentissages, ...) ou une réelle position/posture (qui est alors en contradiction avec le présent article) ?

> this site is not W3C compliant ?, pX, 9 mars 2006

Non, pas vraiment de contradiction, juste un discours complexe, il faut le dire :) (les gars, à votre place, je linkerai ce W3gif sur l’article, ce serait + clair)

en ligne : hallucinet

> Le HTML dans le potage

18 octobre 2005, message de David Latapie

J’y suis allé de ma petit critique (au sens premier, neutre, du terme) sur mon blog. Pour résumer affreusement, je dis qu’il y a du bon et du moins bon.

en ligne : Critique de Le HTML dans le potage

> Le HTML dans le potage

8 septembre 2005, message de Faden

“La plupart des effets « de survol » sont codés dans les pages HTML par des « onMouseOver » et des « onMouseOut » qui déclenchent des fonctions Javascript nommées dans la page Web ; de fait, on se retrouve une fois de plus à devoir encoder directement l’interactivité à l’intérieur de la page Web, plutôt que de faire gérer cela par les CSS (selon la même logique que les :hover des CSS). Ainsi on constatera que les CSS Zen Garden sont très statiques, puisqu’il n’est pas possible de définir des comportements Javascript à l’intérieur des différentes feuilles de style.”

1) Il est très simple en Javascript d’externaliser les événements. On accède à l’éléments avec getElementById par exemple puis on associe l’élément avec une fonction. Simple et efficace et facilement généralisable à plusieurs éléments puisque le pointeur this de la fonction se rapporte à l’élément qui génère l’événement.

2) On peut très bien changer la nom de la class d’un élément via Javascript ce qui permet de garantir le découplage totale xHTML/CSS/Javascript.

En résumé, CSS peut être totalement externe à la page, Javascript aussi donc on peut faire exactement ce que l’on veut avec ces technos et toujours avec un découplage total. Tes arguments ne tiennent pas la route.

en ligne : un exemple de découplage total xHTML/CSS/Javascript

> Le HTML dans le potage, ARNO*, 8 septembre 2005

L’article indique, au paragraphe suivant :

Pour éviter l’insertion de code à chaque balise du code, on peut tenter d’« atteindre » en Javascript certaines balises (par exemple, remplacer automatiquement des intertitres <h3> par leur image typographique, on se trouve contraint à utiliser des scripts très lourds (et, surtout, complexes).

L’exemple que tu fournis fait exactement ce que j’ai écrit : un script (initMenu) déclenche l’« écoute » par Javascript des événements de la page, et certains de ces éléments déclenchent des fonctions.

C’est parfaitement faisable, ce que j’avais déjà écrit, et libre à toi de prétendre « Il est très simple... ». Surtout avec un exemple consistant en un menu déroulant tout simple.

Accessoirement, l’exemple ne me semble contredire un autre point concernant les CSS : on a certes une page HTML particulièrement lisible, propre, compréhensible, maintenable et tout ; mais à côté de ça, un fichier CSS plus long que le fichier HTML lui-même, constitué d’un code moche, peu clair, plein de doublons (et un fichier jaja également plus long que le code HTML qui l’appelle, m’enfin ça, ça n’a rien de nouveau ni de surprenant).

> Le HTML dans le potage, 8 septembre 2005

“Surtout avec un exemple consistant en un menu déroulant tout simple”

Ce n’est pas si simple que cela. Ce menu est pensé pour être compatible avec beaucoup de navigateurs. De plus il gère un petit retard de fermeture.

“un fichier CSS plus long que le fichier HTML lui-même”

Le fichier CSS fait 1769 octets alors que le fichier HTML totalement vide de contenu fait 3449 octets.

Étant le développeur de ce menu, je dois avouer que le développement de la feuille de style m’a pris beaucoup plus de temps que je ne l’avais prévu. Le javascript ne pas posé autant de problèmes de compatibilité.

“constitué d’un code moche, peu clair, plein de doublons”

Le code n’est peut-être pas clair pour toi car j’utilise le positionnement absolu + des décalages à l’aide de marges. C’est peut être moche mais c’est une technique qui a l’avantage de bien fonctionner et de poser un minimum de problèmes.

Pour ta gouverne, tu peux ajouter autant de niveaux que désirez à ce menu et il est censé se comporter correctement. C’est quelque chose que même des solutions commerciales merdiques n’offrent pas forcement. Et ça c’est contenu un fichier CSS de 2ko ... Je sais pas ce qu’il te faut.

Pour les doublons... ben désolé, je regarde mais j’en vois pas.

“et un fichier jaja également plus long que le code HTML qui l’appelle, m’enfin ça, ça n’a rien de nouveau ni de surprenant)”

Ben ça n’a rien de surprenant vu le contenu de la page ... rien que la licence GPL dans le script doit dépasser la taille de la page HTML.

Pour ce que ce script fait, j’estime sa taille tout à fait honorable. Sans les commentaires et la licence. Je suis sûre que la taille du fichier est inférieur à cette page HTML vide de contenu.

Salutations

> Le HTML dans le potage

5 septembre 2005, message de Bobito

Avant j’avais deux passions, le curling et le XHTML orienté objet, mais à présent, j’ai plutôt envie de trouver une meuf en fait..

> Le HTML dans le potage

23 août 2005, message de Sébastien

Arno,

Dans « Le XHTML n’existe pas... » tu pointes vers une note du W3C avec le mot « recommandation ».

Le document http://www.w3.org/TR/xhtml-media-types/xhtml-media-types.html n’est pas une recommandation, bien que ce soit un document intéressant et fréquemment cité en tant que tel .

Une note n’est pas une recommandation. Ce n’est pas important pour ceux qui méprisent a priori tout le travail du W3C, mais pour les autres ce détail a son importance.

La position du W3C n’est à ma connaissance toujours pas entièrement clarifiée sur la question du type MIME « kosher » du XHTML, à part pour XHTML 1.1 pour lequel tout le monde s’accorde sur application/xhtml+xml et rien d’autre.

J’ai traduit cette note en français pour ceux que ça intéresse :

en ligne : Les types de média XHTML

Tierce voie

19 août 2005

A l’heure où chacun campe sur ses position, je trouve constructif que cet article rappelle que la voie des développeurs n’est pas celle de la sentinelle, mais de l’explorateur.

Les pro-libres comme les propriétaires sont en train de s’enliser dans une lutte intestine qui ne peut que désintéresser et même exclure l’utilisateur.

Le "fun" dont parle Arno, ça fait longtemps qu’on ne l’a pas vu passer, si ce n’est avec PHP.

Depuis peu de temps, je consulte des blogs sur les standards du web. Tous pinaillent sur Acid2 (Safari vainqueur, mais grillé au test anti-dopage), fustigent la bêta d’IE7 ("On s’y attendait !"), se rappellent qu’Opera existe, et lisent l’avenir dans les 80 millions de spreadFirefox ("la petite bête qui monte"), le "Valid XHTML 1.0" en bannière (ou en berne, même le microcosme a ses rebelles).

Que ce soit en pour ou en contre, ce sont ces questions qui sont au centre du débat à l’heure actuelle, bien plus que de savoir si SVG sera enfin lâché au grand public. Que cherchent donc à satisfaire les formats ouverts ces derniers temps ? L’égo du microcosme, ou les utilisateurs de la toile ?

Merci pour cet article passionant.

pour ou contre arno*, une question d’avenir pour le web, 19 août 2005

Après avoir lu les autres commentaires, je m’autoréponds.

Je ne suis ni un développeur ni un utilisateur lambda. Je programme sur internet depuis quelques années, et je découvre au fur et à mesure les formats en cours sur le web.

Depuis peu, j’ai aussi été gagné par la fièvre "Valid". Je dois avouer qu’une page propre à un charme indéniable, je n’échangerai pas mon Strict contre un 4.01, et j’évite soigneusement les attributs style="".

Mais ce que je vois du microcosme des développeurs à l’heure actuelle, c’est de l’élitisme pur et simple, et les quelques commentaires (Lester, puisque c’est le premier nom que je trouve), qui se contentent de mépriser cet article sans prendre la peine de donner d’avis constructif ne font que confirmer, à tort ou à raison cette opinion. (Pour ceux qui se contentent d’apporter des rectifications, merci.)

Parce que à vrai dire, que l’article crache sur Flash ou pas par démagogie, se trompe sur ce que font ou ne font pas les CSS, et puis qu’il dise qu’Opera implémente SVG alors qu’en fait non non pas du tout, Opera implémente TinySVG attention rien à voir, mais vous avez quel âge pour recentrer le débat sur un simple "Arno est con" ? Est-ce que j’en ai quelque chose à foutre moi d’Arno, de ses opinions, et de sa vie ?

Il y a une réalité : certains standards ne sont pas implémentés, et le respect strict de la norme, s’il compte, n’est pas nécessairement la priorité du moment. La priorité, ce serait plutôt d’allécher l’utilisateur moyen (moi par exemple), avec des outils qui concurrencent la puissance de flash.

Le démarrage de Firefox était réussi : un navigateur léger, gratuit, et propre. Mais en moins d’un an, la petite bête qui monte fait confondre à certains les ballons et les mongolfières. Firefox a quoi ? entre 5 et 10% des parts de marché ? Je crois pas qu’il soit encore en position d’imposer la norme W3C. Alors à quoi bon pinailler ? Pendant que le microcosme se préoccupe de compter les poils de l’Acid2 sous IE7b1 en se flattant le firefox, le commun moyen utilise IE.

Et l’entre-deux, en attendant un vrai progrès, comme le SVG ou le style dynamique, ne décidera-t-il pas d’abandonner les jolis standards au profit de quelque chose qui marche ?

L’article d’Arno rappelle que valide, pas valide, la question n’est pas encore primordiale, vu le boulot qu’il reste à côté. Et je ne crois pas qu’on puisse l’en blâmer.

> pour ou contre arno*, une question d’avenir pour le web, 19 août 2005

Pour conclure : il ne s’agit pas d’un combat pour ou contre le support des normes mais de l’innovation contre la sclérose.

Bravo !, Henri, 27 août 2005

C’est exactement ça : l’innovation contre la sclérose. Et les ayatollahs des normes du W3C sont en train de se fossiliser à la vitesse grand V. De vrais petits vieux. Le problème, c’est qu’ils fossilisent aussi le web. Revenons à l’esprit de progrès des années 80/90.

> Bravo !, pX, 9 mars 2006

C’est exactement ça : l’innovation contre la sclérose. Et les ayatollahs des normes du W3C sont en train de se fossiliser à la vitesse grand V. De vrais petits vieux. Le problème, c’est qu’ils fossilisent aussi le web. Revenons à l’esprit de progrès des années 80/90.

Super ! Ouais, je te suis ! C’est par où ?

> Tierce voie, Lanza, 2 février 2007

Le "fun" dont parle Arno, ça fait longtemps qu’on ne l’a pas vu passer, si ce n’est avec PHP.

Et plus récemment Ruby on Rails. Les codeux qui veulent s’amuser devraient essayer, franchement.

en ligne : Ruby on Rails

> Le HTML dans le potage

17 août 2005, message de Michel Valdrighi

« (quel magazine de presse informatique grand public a signalé à ses lecteurs que Opera 8 intégrait SVG en standard) »

Aucun, puisque ce n’est pas le cas !
Opera 8 supporte TinySVG, un sous-ensemble de SVG. On est loin du support "en standard" de SVG.

...Et voilà, un exemple de bêtises parmi tant d’autres dans cet article (que d’aucuns ont déjà commenté plus bas).
Autant je suis d’accord sur le fait qu’il y a du boulot pour arriver à un vrai support des normes W3C, autant je ne crois pas qu’enrober une tonne de vieilles méconceptions et de clichés de développeur frustré avec un soupçon d’argument valable suffisse pour faire un bon article.

> Le HTML dans le potage

9 août 2005, message de bofy

Sans une normalisation des pas de vis (bien qu’il existe toujours l’US), aucune industrie mécanique n’aurait vu le jour, quant aux bricolos n’en parlons pas !
HTML est un peu de cette nature : un standard qui permet l’assemblage de morceaux différents à des fins différentes avec des pièces ayant les mêmes propriétés.
Est-ce répréhensible ?

Il y a un vice dans le raisonnement : les plus beaux sites sont avec flash. Ne faudrait-il pas plutôt dire : seuls les sites avec flash peuvent être considérés comme beaux ?

Merci Arno et la discussion : c’est très rafraichissant de voir que le totalitarisme propriétaire ne s’est pas (encore ?) imposé partout.

> Le HTML dans le potage

7 août 2005

les CSS ne doivent pas devenir un langage de programmation

Impossible puisque déjà le html n’est pas un language de « programmation » mais de « mise en page ».

> Le HTML dans le potage, 17 septembre 2005

Surtout pas, le html est un langage de diffusion de données, la mise en page, la présentation ect. c’est le boulot de css.

> Le HTML dans le potage, 20 septembre 2005

HTML est un langage de description de page...

Tu dois vouloir parler d’XML...

A bas l’electricité

5 août 2005, message de blaireau mutant

Que les réfractaires au progrès qui s’entêtent à refuser les nouveaux outils qu’on leur propose soient pris d’une insurmontable panique quand ils s’aperçoivent que leur combat est vain peut se comprendre dans bien des domaines.

Mais en ce qui concerne le web j’avoue que je suis sacrément surpris qu’on puisse déjà brandir des "vieilles valeurs sûres" avec un média aussi récent.

Le web a été défriché entre autres grâce au html et c’est très bien, mais bon les faits sont là, on utilise de plus en plus le plugin flash pour faire des trucs que le html faisait en moins bien : flash est facile d’utilisation, est le seul plugin à lire l’actionscript contrairement aux lecteurs html qui pour bien faire chier les concurrents se démerdent pour interpréter chacun le html/css/javascript à leur manière et au final font VRAIMENT chier les webmasters, il est plutôt joli, et bien plus rapide, ergonomique et 10 fois plus léger que des pages html/php qu’il faut recharger dès qu’on clique sur un bouton, flash n’envoyant/recevant que quelques variables en dialoguant avec de petits scripts serveur.

Le succès du flash n’est aucunement dù à un effet de mode ou à je ne sais quel complot, il est dù au fait que les internautes apprécient ce plugin par sa légèreté, son esthétique ou sa sécurité contrairement aux lourds java ou shockwave, donc tout le monde l’installe, c’est aussi bête que ça.

Un beau jour, dans quelques années arrivera probablement un plugin web meilleur que flash (parce que flash a encore bien des défauts), et je serai bien content d’avoir des outils meilleurs que les précédents. Mais je suis sûr qu’il y aura une tripotée d’imbéciles pour s’indigner que "c’était mieux avant quand on faisait du flash, bouuuh le nouveau truc nouveau ça pue caca c’est la mode c’est mal".

Gros incovénient du flash : google n’en lit pas le contenu c’est pourquoi on utilise souvent une conbinaison flash/html et l’on s’en porte très bien.

Enfin à vrai dire je trouve tout bonnement absurde de se poser des question du type "html est-il mieux que flash ou l’inverse", ça n’a pas de sens...
Dejà en général on est obligé d’utiliser les deux, le premier pour le contenu écrit et l’image fixe, et le second pour le multimédia, c’est pas du tout soit l’un soit l’autre, et SURTOUT, surtout, l’un est un langage, l’autre un plugin, en bref cette question a autant de sens que de se demander si turbopascal est mieux que windows media player.

...

Bref j’ai grand mal à expliquer cette révolte contre un plugin qui a pourtant séduit le public et les professionnels du web, sinon peut-être parce que toutes les grosses boîtes qui vivent du html-microsoft y compris-flippent pour leurs parts de marché.

Une preuve ? Vous vous êtes probablement aperçu de cette RIDICULE alerte du nouveau internet explorer, qui à chaque fichier flash chargé informe l’internaute que "attention ce truc en flash peut endommager votre ordinateur" si ça se trouve c’est même un virus, on peut sûrement faire des virus avec flash, allez savoir avec ces enfoirés qui font du flash. Quand on sait les dégâts que peuvent faire du java ou même du javascript sur un ordi alors que flash est plutôt bien gentil, c’est à se taper le cul par terre. ou à pleurer de honte.

La meilleure c’est que microsoft et d’autres sociétés ont monté un procès bidon contre macromedia pour obtenir le droit d’afficher cette pitoyable alerte accusatrice en dénoncant une soi-disant grave faille de sécurité de flash (hallucinant quand on sait à quel point iexplorer est dangereux pour un pc), en bref des manoeuvres concurrentielles bien dégueulasses comme on sait les faire.

Bref, cessez de vous effrayer devant ce ptit plugin joli et pratique qu’est flash... Et ne vous inquiétez pas le html ne passera pas à la poublelle (et quand bien même cela arriverait je ne vois pas où est le malheur mis à part la flemme d’apprendre les nouveaux outils).

Au lieu de jouer les défenseurs de la lampe à pétrole qui s’indigne devant un innocent plugin qui n’a jamais mordu personne, mettez-vous plutôt au flash (pour les puristes du langage gratuit utilisez mtasc + swfmill qui servent à développer du flash gratos et à la manière oldschool), vous verrez c’est plutôt agréable à utiliser :)

Et histoire de rappeler que je ne prends pas parti "du html contre flash", sachons que tout comme les croisés du html il existe des ayatollahs du flash qui ne supportent pas qu’on puisse critiquer ce plugin et je les fous un peu dans le même sac. Je bosse ou surfe avec flash et html comme tout le monde ou presque, et si un jour des outils encore mieux fichus apparaissent et se popularisent hé bien ça sera tant mieux :)

Excusez la virulence de certaines de mes phrases mais c’est usant d’entendre cracher sur notre boulot tout ça parce que c’est du flash bouuh caca - et ce bien souvent de la part de gens qui ont refusé d’apprendre à utiliser ce plugin, et par conséquent ne savent pas de quoi ils parlent.

bien le bonsoir.

> A bas l’electricité si c’est pour construire de nouvelles centrales nucléaire, Faden, 8 septembre 2005

Le flash c’est sympa mais j’ai de la peine à trouver des applications utils à ce plugin. J’en fait une liste :

* Publicité tapageuse/interactive

* Jeux

* Vidéos (pkoi pas)

* Contenu didactife interactif/animé

En fait des trucs qui m’attire pas trop si ce n’est les jeux vidéos.

Il ne faut surtout pas faire :

* Menu de navigation (quelle idiotie)

* Site tout en flash

* Contenu texte en Flash

En plus Flash c’est hyper lourd à développer. Les outils sont propriétaires. 80% des gens détestent les intros Flash et j’en passe. Le son est souvent intrusive tout comme ces publicité pseudo transparentes toute pourrie qu’on doit se farcir sur les sites de nouvelles.

Enfin pour moi Flash a sonne plus comme une technologie propriétaire utilisée le plus souvent de manière bancale et intrusive. Un appât à déchet informatique et à animateur amateuriste. Flash c’est pas ergonomique car ceux qui développe avec ça on une logique de détraqué.

Mes 2 centimes d’euros.

en ligne : http://dosimple.ch

> A bas l’electricité si c’est pour construire de nouvelles centrales nucléaire, 10 septembre 2005

flash est victime de ses contradictions au depart fantastique outil d’animation graphique pour le web c’est pris de vouloir remplacer les standards web, résultat les outils graphiques de flash sont pratiquement les mêmes depuis flash 5 et il est plus que jamais un simple plugin dont une grande partie des gens continue utiliser 2 a 3 versions de retard, rencontrant une difficulté de plus á la « gueguerre » des navigateurs.

> Le HTML dans le potage

29 juillet 2005, message de SL

bon je vois qu’il y a un grand débat la dessus a première vue !
tout ce que je sais c’est que je découvre linux, w3c et xhtml ! et je ne vois que des applis à la fois moche et pensé et utilisé que par des master class de l’informatique ! vous voulez que vos standards soient acceptés et bien rendez lez clairs exploitables direcement par tous et simple, ce n’est pas parce que l’on donne un aspect abscons et complexe a quelque chose que l’on ait intelligent !
en tout cas sur cet article je n’y vois rien d’autre qu’un fatras d’idées recues et du peu d’ouverture d’esprit de l’auteur !

je suis navré mais un site en flash qui a de la gueule me fait plus d’effet qu’une belle merde html programmé par un génie, parce que sur internet c’est comme pour les voitures on est pas la tete dans le moteur pour avancer !

> Le HTML dans le potage, 19 août 2005

1°) Je ne suis pas certain que le flash soit plus facile à maîtriser que le HTML+CSS.

2°) L’informatique n’a jamais été simple. Les outils et notions sont continuellement simplifiés mais dans le même temps de nouveaux outils et notions aparaissent.

3°) Au moins ces idées reçues sont elles rédigées dans un français convenable et avec une orthographe à l’avenant !

> Le HTML dans le potage, Expert, 10 septembre 2005

Je suis bien d’accord moi, un site en flash programmé par un génie qui a de la gueule fait plus d’effet qu’une belle merde html programmé par un branquignol !
Et inversement, un site en html qui a de la gueule fait plus d’effet qu’une belle merde en flash ! ;-)

> Le HTML dans le potage, Pierre, 6 octobre 2006

Linux est moche ?
Windows doit être beau... ???

Perso, le bleu et le vert ensemble ça m’a toujours paru une faute de goût.

Linux n’est pas réservé aux génies ; la preuve ? je l’utilise...

Il existe des distributions de Linux très abordable (et très "qui on de la gueule") pour les utilisateurs lambda et nombre de leur limitations sont justement dûes aux formats propriétaires et non standard comme... flash.

vous voulez que vos standards soient acceptés et bien rendez lez clairs exploitables direcement par tous et simple

Le but des standards est justement la transparence et que ça marche quel que soit le matos, le système d’exploitation ou le navigateur que tu utilises.

Libre à toi d’utiliser Windows, internet explorer et tout le toutim mais laisses le choix aux autres d’utiliser ce qu’il veulent.

> Le HTML dans le potage

11 juillet 2005

je partage ton avis arno, flash doit rester un accessoire, pas une fin en soi.
Je pense que l’immobilisme n’est qu’apparent, puisque nous savons qu’en terme de cohérence, inter-opérabilité, et surtout portabilité, il faut respecter des règles hiérarchiques simples, et il semble évident qu’appeler du javascript ou du flash par autre chose que ce que l’on considère comme la source du document serait une erreur.

ou sinon bien sûr, vous pouvez résumer tout à une suite de plug-in.. agrafés sur une base pauvre mais connue contrairement aux formats proprietaires.
Ce n’est pas comme ça que l’on conçoit le net j’en suis sûr, mais c’est comme ça que le rêvent nombre de requins.
A ceux qui ralent ici : vous avez deja vu une voiture vendue qu’avec les pneus parce qu’ils sont plus jolis que la carosserie ?

bon, en fait c’est vrai qu’il ne faut pas se trainer pour autant un côté trop draconien, un juste milieu doit etre la.

mais vous ne déclencheriez pas l’airbag parce que le klaxon marche depuis plus de trois secondes, on est d’accord ? pourtant c’est ce qu’on arrête pas de faire avec ces work-around pour des "drole de" navigateurs.
c’est ce qu’on ferait aussi si on developpait les standards trop vite.
c’est ce que font les formats proprietaires, mais eux ils cachent leur incompetence derriere leur marketing.

en fait le problème, c’est que nous trainons des boulets là où les formats propriétaires trainent des clients.
certains le savent mais confondent le chemin et le boulet.

pour finir, je suis déçu de constater que des webmasters ayant répondu ici misses some simple concepts.

> Le HTML dans le potage

30 juin 2005, message de Alex

J’ai travaillé un an dans le but de résoudre le problème ci-dessous en transformant le MathML en SVG.

Des résultats par ici :
http://ms800.montefiore.ulg.ac.be/~stevens/pMML2SVG/

"On retrouve ici le principe du serpent XHTML qui se mord la queue : il n’existe pas de butineur grand public permettant d’afficher du MathML à coup sûr, du coup :
personne ne publie réellement des pages contenant du MathML,
personne ne développe réellement les outils permettant de créer du MathML (notamment des traducteurs TeX vers MathML, ceux existants étant encore très insuffisants pour une utilisation réelle),
et ainsi les développeurs de butineurs ne placent pas l’intégration de MathML dans leurs priorités."

en ligne : MathML vers SVG

> Le HTML dans le potage

24 juin 2005, message de bouzin

Arno* accepte que tout le monde ait sa propre vision de son propre travail. Est-il moins cohérent pour autant ?

Je ne suis pas un spécialiste autant que j’aimerais l’être, mais j’arrive cependant à bien comprendre, dés la première lecture, les arguments de cet article... Sans doute je ne comprends pas du premier coup certaines nuances, mais en tous cas ils recoupent des questions pratiques que j’ai bien été bien obligé de me poser car elles se sont présentées dans mon expérience de concepteur de sites.

Pour moi, ce ne sont donc pas là 40 pages pour ne rien dire... Cet article possède, au contraire, le mérite d’énumérer des questions que l’on n’ose même plus poser à haute voix, de peur de devenir désormais ridicule, vilain et sale...

Les manitous normalisateurs autoproclamés continuent à donner des leçons aux "petits" et à gagner à leur cause normalisatrice un maximum de public. Tant mieux pour eux. Cependant les embouteillages qui se produisent sur l’autoroute finissent un jour ou l’autre par fatiguer...

Qui que l’on soit, on peut réfléchir par soi-même. On découvre par la même occasion, des accès nouveaux et des cohérences plus solides. Arno* en est un bon exemple. Merci pour cet article.

> Le HTML dans le potage

23 juin 2005, message de titou

Une question, le w3c, c’est qui ? le début de la réponse est peut-être là... les milieux uniformes quelqu’ils soient, sont des milieux assez stériles, qui ont du mal à apréhender les problèmes en dehors de leur propre problématique. Demander à 30 informaticiens (j’en suis un, je précise...) de comprendre les besoins d’un graphiste, c’est structurellement illusoire (et l’inverse serait tout aussi vrai). Ce qui manque au w3c, c’est un peu de pluralité dans les compétences (des informaticiens, des graphistes, des webdesigners, des ergonomistes, des sociologues, etc), mais aussi, sans doute, dans les sexes . Ils appréhendent d’une manière strictement technique (comme un langage informatique), ce qui est média.

Bon, je relativise tout de suite mon propos (lâche que je suis) :
Je n’ai aucune idée de la composition du w3c. Mais comme, j’ai déjà lu des spécifications w3c, je me doute que les littéraires ne court pas les couloirs du w3c...
Il ne faut pas jeter le bébé avec l’eau du bain : le souci de normalisation est qqchose d’indispensable. Le fait que certaines normes ne furent jamais appliquer tient plus de considération commerciales (les temps héroïques de l’affrontement IE/Netscape) que techniques.

> Le HTML dans le potage

2 juin 2005, message de pX

Globalement d’accord, même la taille de ce pensum ne m’a pas géné.
Bravo Arno, keep stompin’ that KB.

en ligne : hallucinet - reality processing

> Le HTML dans le potage

29 mai 2005, message de Romuald

Quand on voit ce que nous réserve le XHTML2 c’est un vrai bonheur, ceci dit, il faut faire des efforts de sémantique.
Ce n’est pas bien compliqué, on doit juste se dire que tout les tags on un sens logique, et qu’une page html ne se fait pas que de div ou de table.

J’ai par habitude de faire du xhtml et du css, et dans les plus stricts standards, et je n’y trouve rien de bien complexe, même si les compatibilités des navigateurs est un peu casse bonbon.

Bref, le Web devient plus intéressant ainsi, et moins en proie des charlatans du coté professionnel.

Romuald.

en ligne : http://ckkoshi.free.fr

Du besoin d’être logique, esc, 30 mai 2005

C’est vrai que si une page est structurée de façon logique, cela peut aider à en extraire automatiquement du contenu.

(Au fait, pourquoi veut-on extraire automatiquement du contenu ?)

Je rebondis sur ce que tu nous dis, Romuald, pour noter également qu’il n’y a pas qu’une seule logique dans l’univers, et qu’en se donnant tel ou tel standard, on s’en tient à telle ou telle logique... au détriment de toutes les autres.

Je peux développer ce point si des gens sont intéressés ;)

> Du besoin d’être logique, Romuald, 31 mai 2005

Il y a toujours des divergance d’opinion sur la logique certes. D’un autre coté, les standarts actuel sont d’un coté bien, mais d’un autre limité part l’évolution des butineurs.

Puis, c’est pas vraiment de la logique, mais de la sémantique (bon oui c’est la même chose), on appel un titre un titre un paragraphe un paragraphe et un bloc un bloc.

Je n’ai pas trouvé très compliqué l’utilisation du xhtml/css, même si, j’ai commencé il n’y a pas si longtemps (à l’époque de Mozilla 1.0 en gros).

Sinon, oui, pourquoi pas plus développer ? Tout les points de vue sont enrichissants à écouter !

en ligne : c’est n’a moi

> Le HTML dans le potage

28 mai 2005, message de Calimo

Un article très intéressant, il y a beaucoup de choses très justes là dedans. Dommage qu’il soit continuellement émaillé de petites imprécisions :(

Dans le désordre :

[limitations des CSS]

Peut-être faudrait-il déjà que les navigateurs implémentent vraiment les CSS actuelles. Parce qu’actuellement c’est une catastrophe, pas un navigateur n’a une implémentation complète de CSS 2 (même si certains n’en sont pas loin). On va sur la Lune et sur Mars et on est pas capable d’implémenter correctement une bête norme CSS...

Alors pour moi, le plus important c’est de commencer par implémenter correctement les CSS actuelles, et après (dans 10 ans) on rediscutera pour les faire évoluer ;-)

il n’existe pas d’implémentation standard de MathML dans les butineurs. Pas même Mozilla Firefox.

Sisi, Gecko (Mozilla, Firefox et cie) implémentent très bien le MathML.

la recommandation aberrante du W3C qui consiste à refuser une page à la moindre erreur de syntaxe HTML (ou plutôt : XHTML)

Ce n’est pas aberrant du tout, les erreurs de syntaxe sont un véritable cauchemar pour ceux qui font les implémentations. Et après chaque navigateur les interprète différemment, c’est exactement ce qui s’est passé avec le HTML.
Alors tant mieux si le W3C a tiré les leçons du passé et si le XML n’autorise pas les erreurs.

Le fait qu’un navigateur bien connu propose de télécharger les fichiers application/xhtml+xml vient uniquement du fait que celui-ci ne connaît pas le XHTML. Comment pourrait-il afficher quelque chose qu’il ne connaît pas ? En soit c’est un comportement tout à fait correct et souhaitable.

L’autre sujet qui fâche dans le HTML (et, encore une fois, dans le XHTML), c’est qu’il n’existe pas de méthode normalisée pour y intégrer des polices de caractères.

La police de caractère c’est de la présentation, donc c’est normal que le W3C n’ait pas mis de mécanisme au niveau du (X)HTML. Tu dois t’être mal renseigné, car ce mécanisme existe en CSS 2 (mais a été retiré du CSS 2.1). Malheureusement les seules implémentations existantes utilisent des formats de polices propriétaires :-|

Ma conclusion : webmasters, faites du XHTML (en application/xhtml+xml), mettez-y des CSS avancées, intégrez-y du SVG, du MathML, des XForms et du SMIL, poussez les fabricants de navigateurs à implémenter ces normes et faites évoluer le web !

> Le HTML dans le potage, jyes, 7 octobre 2006

N’étant ni designer ni programmeur, j’ai pourtant assez vite appris les règles régissant les standards du W3C, et suis convaincu de leur intérêt profond. En effet, je pense que la finalité d’un site c’est de diffuser un contenu, et qu’en ce sens la normalisation est importante pour que l’accès à ce contenu soit simple en toute circonstance. Je crois que nous n’aurions pas à débattre autant si l’histoire d’internet avait commencé par une normalisation. J’utilise couramment XHTML Strict et CSS dans ce sens, parce-que même si aujourd’hui ils présentent peu d’intérêt par rapport au vieil HTML de 1998, ils sont la direction à suivre pour un avenir accessible à tous.

Cependant, je trouve l’article d’Arno* extrêmement intéressant car il illustre parfaitement les écceuils auxquels on se heurte en suivant cette démarche et démontre bien l’insuffisance de support en ce sens. Concrètement, pour déffendre l’accessibilité pour tous, j’ai bien été obligé de fournir des versions alternatives pour les utilisateurs de butineurs qui interprètent suffisamment mal mes CSS pour rendre les pages illisibles. Ensuite il faut le script qui va avec pour déterminer quelle version apporter à quel navigateur, etc ... C’est loin d’être simple !

Reste que je suis bien content d’avoir codé du XHTML Strict, parce-qu’il m’a alors été très facile d’automatiser sa convertion en HTML via des petits scripts persos, et que j’en tire même une version texte brute téléchargeable dans le pire des cas. Et si moi je peu sucer la substantifique moëlle de mes pages avec autant de facilité, c’est que leurs formats sont pensés en ce sens. À chaque conversion que je fait, je perds un peu d’information, mais je sais que j’ai quelque-part mon fichier XHTML qui contient tout.

C’est ici la grande supériorité d’XHTML sur HTML, c’est qu’il se comporte comme n’importe quel XML, format de structuration d’information par excellence ... et le jour où je devrai écrire des formules mathématiques, j’utiliserai MathML pour les stocker, quitte à devoir les convertir pour certains utilisateurs.

En ce sens, le défaut de Flash n’est pas que Google ne vois pas dedans, c’est que personne n’accède à son contenu sauf ceux qui peuvent se plier à ses règles (installation de plugins etc, fussent-ils les plus nombreux) ! Donc Flash n’est pas un moyen d’afficher le contenu, c’est un frein à se diffusion.

Pour mon attachement si fort à la politique de normalistaion du W3C, et pour mon utilisation courante de logiciels non-commerciaux (voire libre c’est tellement mieux :) ), je suis d’accord avec l’idée que l’utilisation massive des standards est le meilleur moyen de voir leur support se développer, et je reste sur la conclusion du post précédent :

webmasters, faites du XHTML (en application/xhtml+xml), mettez-y des CSS avancées, intégrez-y du SVG, du MathML, des XForms et du SMIL, poussez les fabricants de navigateurs à implémenter ces normes et faites évoluer le web !

> Le HTML dans le potage - le projet TeSQue

25 mai 2005, message de Escape

Salut *ARNO.

Je crois que je perçois l’interrogation derièrre ton texte. En gros, bien que tu ne le dises pas ainsi, tu estimes que la sémantique mise en oeuvre dans les divers formats (HTML, CSS, XHTML, Flash) est un gachis.

J’ai l’impression persistante que tu souhaiterais quelque chose qui 1°) épousât mieux la fluidité de l’univers ambiant, 2°) fût joli, 3°) à échelle humaine, et 4°) hautement génératif (i.e. programmable).

Cela t’intéressera peut-être de savoir que je bûche sur quelque chose qui s’efforce de répondre à ces quatre points à la fois.

Tout est expliqué sur la page qui est donnée en lien. Cette page se trouve sur le site suivant : Blue Moon = http://www.bloumoune.org

Les pages de Blue Moon sont écrites à l’aide du format susnommé (TeSQue), et on peut voir comment ce format fonctionne en faisant "Voir le source" (ou en tapant la touche V de son clavier) depuis n’importe laquelle des pages du site...

Ciao
— esc

en ligne : Plusieurs états du format TeSQue

> Le HTML dans le potage - le projet TeSQue, 19 août 2005

internal server error.
C’est donc un langage basé sur le numéro 50x ? :)

> Le HTML dans le potage

25 mai 2005, message de zerchove

haaaa la démagogie a deux balles d’uzine, toujours présente !

Bon si tu t’étais un peu sorti les doigts, tu serais au courant que le code du CSS Zen Garden n’a pas du tout vocation a etre parfait, c’est un exercice de style lancé par Dave Shea, et il est tout à fait conscient de la pauvreté de son code HTML sur cet exemple. Donc c’est pas la peine de faire une thèse dessus.

Arretez gueuler contre le grand complot W3C kiveuvoufèrdumal.

> Le HTML dans le potage

25 mai 2005, message de bersace

C’est pas très rigoureux ton analyse de la flemme des développeur de navigateur.

Gecko implémente bien CSS, XHTML et voilà que SVG et XForms arrive. Et toi tu pinaille avec MathML, le truc que Mr Robert n’en a que faire !!!

Allez, dommage que ton article (long et répétitif comme un CLUF) soit si biaisé car tu as raisons dans de nombreux points.

Pour ma part, Javascript dans le CSS, ça me parait fumeux.

> Le HTML dans le potage

24 mai 2005

Bonjour arno*. C’est peut-être pas la peine d’écrire un article de 40 pages rempli de conneries si c’est juste pour pouvoir sortir l’argument magique "tu n’as pas lu jusqu’au bout". Bah non j’ai pas lu jusqu’au bout, je me suis arreté à la fin de ta partie sur les feuilles de style (qui font ce qu’on leur demande, mais c’est un défaut à tes yeux).

Je voulais simplement te témoigner ma compassion, je croyais sincèrement que les rectifications apportées à l’article w3c go home de septembre 2003 t’avaient éclairé.

Mais non. Dommage.

> Le HTML dans le potage

24 mai 2005, message de bersace

Pourquoi attacher tant d’importance au son ???

J’écoute ma bibliothèque musical et c’est le cas de plus en plus d’utilisateur avec la banalisation de la musique en ligne (iTunes, etc.). Si j’ai mon rythmbox ouvert (ou mon iTunes, WMP®, Winamp, etc.), je n’ai pas envie d’avoir du son d’un site web.

De plus, si j’ai 20 onglets ouverts sur 3 fenêtre, j’ai pas envie que 5 site webs me fasse du boucan ou même m’en propose ! Si je travaille sur OpenOffice, Emacs ou au toilettes avec Mickey Mag, j’ai pas envie que la page ouverte sur le site de Robert fasse du boucan !!!

Est-vraiment interressant d’avoir un Web si intrusivement multimedia ?

> Le HTML dans le potage, jean-marc, 25 mai 2005

Salut Bersace,

Je vais répondre d’une manière personnelle à votre propos.

Selon moi le son est quelque chose de bien plus important et dynamique qu’un langage basé sur l’écrit où chaque graphe écrit correspond à une unité sonore précise détachée de toute représentation sensible soit la lettre.

Tout comme vous je n’aime pas ces sons bruits inclus dans les programmes et les OS, tout simplement effrayants.

Il existe des chartes graphiques (design), sémantiques (structure de l’écriture) mais je ne crois pas qu’il existe quelque chose pour le son.

Un son bien pensé, bien travaillé peut être magnifique. Certes il est plus largement utilisé dans la musique ou dans les films. Plus dur à utiliser dans une page web (à cause du poids).

Mon rêve, un web sonore sans images... Tout le problème du son dans notre société vient de ce que nous n’arrivons pas à le détacher d’une représentation sensible.

C’est pour cela que le son est un petit peu délaissé.

Bon j’arrête là sinon je ne finirai pas...

Le son, c’est bon, André Mertens, 26 mai 2005

Le son sur le web, ce serait délicieux si les navigateurs avaient un bouton "modifier le volume du navigateur" et/ou "couper le son des autres programmes".

> Le HTML dans le potage, bofy, 9 août 2005

le web sonore sans image, ça existe : ça s’appelle la radio...

> Le HTML dans le potage, damino, 16 janvier 2006

Salut, pour ma part je blame effectivement le fait que certains sites "imposent" du son alors que l’on n’en veut pas ou ne s’y attend pas (tout comme les popup). Mais je suis assez d’accord que le fait que dans les normes actuelles, c’est plutot le désert et c’est dommage.
Pourquoi du son : ben je construit des sites pour des artistes musicaux et autant on peux s’amuser avec la charte graphique, autant c’est la bidouille ou les trucs sans saveurs (un lecteur simple) pour la musique. Voilà et ici il s’agit de sites que l’on vient consulter pour écouter de la musique, jouer avec.

> Le HTML dans le potage

24 mai 2005

"Arno*" n’a décidément rien d’autre à foutre que pondre ce genre de document... ya quand même plus intéressant dans la vie hein...

> Le HTML dans le potage, Lester, 24 mai 2005

Il nous avait proposé un articulet (bien sympathique au demeurant) sur la conchyliculture (son autre domaine de prédilection), on a réorienté (prétextant un hors sujet uZine) ce tapuscrit sur l’autopsie du XHTML (mais le cadavre bouge encore, qu’on se le dise)

Une erreur de notre part ?

Arno*, tu l’as encore ton psaume sur les bivalves ?

> Le HTML dans le potage, Matcheux, 31 août 2005

"Arno*" n’a décidément rien d’autre à foutre que pondre ce genre de document...

C’est vrai ça, n’importe quel webmestre est capable de maintenir au plus haut niveau un gestionnaire de contenu comme spip les doigts dans le nez et en même temps réfléchir à l’avenir du web, au pourquoi du comment, avoir une excellente rigueur de codage sans faire chier les autre avec ça etc...

Félicitation Arno* pour cet article passionnant.

> Le HTML dans le potage

24 mai 2005, message de Mithfindel

Il ne faut pas oublier que quoi qu’on puisse dire et trouver en navigant au hasard sur notre cher médium électronique, une réalité s’impose : les standards sont peut-etre parfois lourds à utiliser et pas toujours supportés, mais ils favorisent l’apparition d’outils de génération et de moteurs de sites - je pense à tous les softs de CMS qui ont vu le jour ces dernières années, à des choses comme SPIP, phpBB et Zope.

Il ne sert à rien de s’apitoyer sur la pauvreté des technologies existantes, la nouveauté est promue par les utilisateurs. Vous voulez le support de SMIL, SVG et CSS3 dans Firefox ? Très bien ! Tout le monde a les capacités d’aider dans cette entreprise. L’utilisateur simple en testant et en soumettant des rapports de bugs. Le développeur en offrant ses services à l’équipe de développement. Tout le monde enfin, en donant, même si d’autres causes sont peut etre plus justifiées.

Et ce qu’il faut bien voir, c’est que quand les standards sont ouverts, des outils gratuits existent pour les utiliser, tandis que des formats fermés comme Flash nécessitent des softs lourds et CHERS surtout pour l’utilisateur moyen.

> Le HTML dans le potage, 26 mai 2005

Ah oui tiens bonne idée.

Arno tu ne voudrais pas collaborer à un projet open-source, un CMS par exemple ? :)

> Le HTML dans le potage

24 mai 2005, message de Minh Ha Duong

Je trouve que la prolifération des syntaxes genre wiki, style {{ gras }} dans SPIP est le signe d’un retour en arrière certain. Avant on mettait tranquillement <b>, maintenant c’est devenu compliqué ça dépend jargon du site.

Pour les maths, j’ai lu la norme MathML ça me rappelle le vietnamien avant l’écriture alphabétique. A l’époque il y fallait deux caractères pour chaque mot, un pour le sens et un pour la prononciation (l’annotation des caractères rares pour préciser la prononciation se pratique encore dans certaines langues extrême orientales, il y a même une http://www.w3.org/TR/ruby pour ça). Ceci rendant l’accès au savoir plus difficile, il était réservé à une certaine élite... Pour en revenir au MathML, le côté hallucinant c’est à quel point ce langage mélange présentation et contenu.

Le compromis sensé à mon avis c’est la balise <math> qui contient du TeX (et non du LaTeX).

> Le HTML dans le potage, Trif, 3 juin 2005

L’idée de la balise serait d’une grande simplicité.
Ce que je ne comprends pas, c’est que ma calculette formelle affiche des maths si bien (comme une grande hein, pas besoins de caractères d’orientation). Quel est la problème pour integrer le même algo à nos naviguateurs ?

> Le HTML dans le potage

23 mai 2005, message de jlb

Ouah j’ai bien rigolé !

> Le HTML dans le potage

23 mai 2005, message de Raphaël Wils

Lecture rafraichissante qui confirme ce que je me murmure devant mon miroir tout les matins : nous ne devons pas avoir de scrupules à utiliser javascript pour peu que certaines bonnes pratiques soient respectées comme ne pas gener l’accessibilité et avoir un code pas trop fouilli.

Raphaël

en ligne : r-wils.com

> Le HTML dans le potage

23 mai 2005, message de jean-marc

Bonjour,

En gros il y a deux voies :

Le html, javascript, css de type propriétaire celui que l’on aurait tendance à nommer soupe.

L’autre html, css, javascript séparés clairement. Chacun à sa place !

Pour le débutant amateur bricoleur que je suis. La question se pose : quelle voie choisir ?

J’ai choisi la seconde, elle me semble plus claire à comprendre.

Cela fait-il de mon site un meilleur site ? Cela donne-t-il une meilleure connaissance supposée ? Non !

J’aimerai inclure des animations, du son surtout du son ; une ambiance sonore est bien plus intéressante qu’une animation selon moi. Vu le peu de possibilités, j’ai vite abandonné l’option.

Reste javascript. Mais là encore deux chemins :
Le dhtml
le DOM.

En gros on reprend les mêmes idées et on l’applique à javascript. Un script n’est plus appelé dans la page HTML mais dans la page de script lui-même (le fameux window.onload par exemple).

Le DOM, plutôt ardu pour insérer quelquechose dynamiquement (document.createElement) avec les fameux noeuds. Chaque élément doit être décrit tandis qu’avec un "document.write" on écrit un bloc HTML complet, plus simple surtout s’il y a une page complète à générer.

A force, je m’y perds et je ne sais plus quoi utiliser et lequel est le meilleur des deux. Heureusement, il existe quelques bons sites de codeurs (quirksmode, onlinetools, sitepoint) qui aident beaucoup à faire la part des choses.

Pour reprendre l’exemple atteindre tel élément de la structure d’une page : je veux que chaque second paragraphe soit souligné en bleu. C’est possible avec javascript mais là, hop, quelqu’un affirme qu’il ne faut pas confondre javascript de présentation et javascript d’aide à l’utilisation sans parler des applications javascript.

Je trouve cela confus. Cette confusion est aussi dépendante de mon apprentissage.

Finalement, je comprends ceux, celles qui n’ont pas envie de s’embêter et choisissent le premier chemin. Rien n’est véritablement fait pour attirer le débutant. il n’y a pas une voix identique ni une explication très claire. Chacun fait sa sauce même si on arrive à dégager quelques tendances.

C’est dommage parce que encore un autre chemin finit par s’imposer, celui du CMS. Une fois de plus, cela devient une création de spécialistes et on laisse un espace d’utilisation au final très simplifié et un tantinet restreint à l’utilisateur (les fameuses trois colonnes).

Tout cela me laisse dubitatif.

> Le HTML dans le potage

23 mai 2005, message de Raphael

« En revanche, vous n’avez pas accès à la seconde lettre du paragraphe, vous ne pouvez pas définir un style qui s’appliquerait à une ligne de tableau sur deux, vous ne pouvez pas tester si la première lettre est un guillemet ouvrant, auquel cas vous souhaitez appliquer le style, également, à la deuxième lettre (pour faire une belle lettrine), vous ne pouvez pas réduire la taille du texte en fonction du nombre de caractères, etc. »

Ah oui en effet, on ne peut pas faire ça directement en CSS, avec un sélécteur.
Mais, question bête, ce paragraphe sous-entend qu’on pourait le faire autrement ? Comment donc ?

A part en ajoutant de la structure ou une balise, je ne vois pas trop comment on pourrait faire autrement non-plus.

Sinon, effectivement, si on veut désigner la 86è lettre de la 8è ligne du 3è paragraphe, je crois qu’il est un peu plus simple et plus logique de lui attribuer une classe ou un id, parce que si on commence à chipoter pour inventer des sélecteurs aussi poussés, la critique va devenir que les CSS sont trop compliqués ! :P

> Le HTML dans le potage, ARNO*, 23 mai 2005

Ah oui en effet, on ne peut pas faire ça directement en CSS, avec un sélécteur. Mais, question bête, ce paragraphe sous-entend qu’on pourait le faire autrement ? Comment donc ?

Si tu prends un exemple qui ne correspond à aucun besoin, évidemment. Il me semble pourtant que je donnes des exemples plus concrets, dont la structure même de CSS Zen Garden, qui recourt à un encodage spécifique justement pour réaliser ce genre d’effet :
— les classes "p1", "p2", "p3", "p4, "p5" pour différencier les paragraphes successifs, justement parce qu’il n’y a pas de sélecteur CSS permettant de le faire ;
— le recours à PHP, en amont, pour adapter le code au besoin graphique et parvenir à réaliser les effets directement avec les CSS (tu veux une lettrine « propre » ? alors tu fais passer ton texte par PHP, qui va isoler le premier caractère et regarder si c’est une lettre et, si ça n’est pas une lettre — un guillemet ouvrant, une parenthèse...—, aller prendre le second caractère pour le placer aussi dans la lettre ; systématiquement vérifier le caractère suivant, parce que si c’est une apostrophe, il faut aussi l’intégrer dans la lettre ; enfin, si tu veux une belle lettrine graphique comme dans l’exemple de CSS Zen Garden, tu passes le tout par une moulinette PHP) ; il s’agit de solutions de contournement des limites des CSS, qui font que le code n’est finalement pas réellement « portable ».

Autre exemple (déjà ancien) : SPIP fabrique des tableaux (à l’intérieur du texte) en insérant une classe différente une ligne sur deux, pour permettre aux webmestres de définir des rendus (généralement la couleur de fond) différents selon la ligne. Ce genre de choses devrait être réalisé directement par des sélecteurs CSS.

Dans tous les cas, ce genre de méthodes rendent caduques une réelle séparation du contenu et de la forme : si CSS change le contenu de sa page de démonstration, les feuilles de style devront être redessinées, ce qui est absolument l’inverse de l’intérêt des CSS ; si tu veux un graphisme une ligne sur trois, ou avoir des comportements qui dépendent de l’existence de lignes spécifiques (une ligne de « séparation »), bref un contrôle chiadé des tableaux, alors soit tu recodes le script de SPIP, soit tu codes entièrement à la main.

la critique va devenir que les CSS sont trop compliqués !

— Tout d’abord, c’est perdre de vue que les CSS sont déjà compliquées. Je te conseille l’excellente page QuirksMode CSS (déjà signalée dans l’article) pour voir une liste de sélecteurs et de pseudo-classes particulièrement cotons (un exemple est fourni dans l’article). Ne pas se tromper, hein : ces sélecteurs et ces pseudo-classes sont épatants ; simplement j’expose des limites.

— La complexité n’est pas en soit rédhibitoire si elle s’insère dans une courbe de progression continue. Les CSS et les exemples des QuirksMode l’illustrent : tu peux commencer les CSS de manière très basique et cela donnera déjà des contrôles typographiques sympathiques, et progressivement découvrir et comprendre des syntaxes nettement plus balaises.

> Le HTML dans le potage, bohwaz, 23 mai 2005

"— les classes "p1", "p2", "p3", "p4, "p5" pour différencier les paragraphes successifs, justement parce qu’il n’y a pas de sélecteur CSS permettant de le faire ;"

Justement si, regarde du côté des sélecteurs "+", exemple : p+p ...

Cf. Chessboard sur LiteraryMoose.info (bon c’est implémenté correctement que sur Opera et Mozilla 1.8b mais bon c’est toujours le même problème avec les standards : c’est mal implémenté et Firefox est pas près de le faire...)

Lien dans la doc W3C : Adjacent Sibling selector

> Le HTML dans le potage, HoPHP, 23 mai 2005

Oui, mais euh, NON !

Si ton paragraphe commence par un guillemet ou une parenthèse (ce qui, selon toi, justifierait l’utilisation de PHP) c’est parce que ce paragraphe n’est pas construit de manière sémantique. Pourquoi besoin de guillemets ? Citation ? -> La balise q (ou blockquote ) est là pour ça. Pourquoi commencer un paragraphe par une parenthèse ? Selon moi, un paragraphe ne devrait pas débuter par une parenthèse. Question de goût (ou de sémantique...) peut-être !?

Pour ce qui est des paragraphes "p1", "p2", etc, il y a une explication. Avec le sélecteur +, il est possible de sélectionner le n-ième paragraphe (forcément, avec 37 paragraphes, ça commence à faire long). Le problème étant qu’il faut, pour faire la promotion des CSS, créer des designs qui s’affichent sur tous les navigateurs post-brontosauriens, dont MS-IE. MS-IE qui ne reconnaît pas complètement la norme CSS. Par conséquent, le CSS Zen Garden se retrouve à tarabiscoter une soupe de balises pour que MS-IE affiche correctement ce qu’on lui présente.

Bref, bref et re-bref.

++, HoPHP

> Le HTML dans le potage, Eric Daspet, 25 mai 2005

Euh oui mais non.

Si ton paragraphe commence par un guillemet ou une parenthèse c’est parce que ce paragraphe n’est pas construit de manière sémantique.

Ah ? pourquoi ? si en français un paragraphe peut commencer par une marque typographique, il le peut aussi en HTML, il n’y a aucune raison du contraire. Pas la peine de rajouter le mot sémantique partout, ça n’a rien à voir avec la possibilité ou pas d’avoir une parenthèse en début de phrase (sauf à vouloir marquer tous les groupes gramaticaux d’une phrase mais c’est heureusement hors de question)

Pourquoi besoin de guillemets ? Citation ? -> La balise q (ou blockquote ) est là pour ça.

Et pour un mot "hors contexte" pris distance ? qui n’est pas une citation ? et pour une dénomination type tes paragraphes "p1" ou "p2" ? et pour un terme à expliciter ?
Rien à voir avec une citation, rien avoir avec Q et BLOCKQUOTE, pourtant il faut bien des guillemets.

Quid aussi d’un texte en espagnol ou une marque de ponctuation peut initier une phrase ? quid aussi de ta signature qui justement commence par "++" ?
Tu pars d’une assertion non justifiée et completement fausse pour justifier à postériori un manque de fonctionnalités (certes largement négligeables comme fonctionnalités mais manque réel tout de même)

> Le HTML dans le potage, HoPHP, 26 mai 2005

Bon, bon, on respire !

Je ne peux pas te laisser dire tout ça. Qu’on me corrige si je dis une ânerie (ce qui est tout à fait possible, soyons clairs) !

Pour ce qui est de mes guillemets autour de p1 et p2, ils se justifient totalement. J’écris à travers SPIP, pas en HTML. Je viens de tester, je ne savais pas qu’il était possible de mettre des balises HTML dans un message posté dans SPIP. Erreur corrigée dans ce message. J’aurais balisé mes p1 et p2 par la balise code. p1 et p2 sont du code informatique (du (x)HTML, en l’occurence), pas du français.
Pour ce qui est du texte en espagnol, il faut utiliser les attributs propres à l’HTML, lang="es" dans la balise de paragraphe, comme suit : <p lang="es">Un poco del texto español.</p>. À mon sens, il faut exploiter les possiblités offertes par le langage (x)HTML. On n’écrit pas du (x)HTML comme on écrirait du français. Il est faux de penser que si j’écrirais un guillemet en français, il me faut l’écrire dans le code (x)HTML. Ce qu’on écrit en (x)HTML n’est qu’une image de la réalité, un moule dans lequel on peut classer les choses avec une certaine rigueur (ou pas, visiblement). Cette réalité est mise en forme par le butineur pour une part et par les feuilles de styles (CSS). C’est à ces deux acteurs de décider conjointement (selon les règles de priorité définies dans la norme des feuilles de styles) comment on affiche une citation, un passage du texte en espagnol ou un bout de code. C’est la même chose pour un mot pris hors contexte. Il faut baliser les quelques mots mis hors contexte avec une structure adéquate (<span class="hors_contexte">, par exemple) et c’est ensuite le rôle de la feuille de style de définir comment ce texte pris hors contexte doit être affiché (ici en rouge). Je conviens cependant que pour le cas des parenthèses, il manque une balise, quoique !
On pourrait penser qu’un tel balisage à outrance est barbant ou inutile, mais je pense que son utilité se fait comprendre si l’on imagine un programme devant lire un fichier HTML. Comment ce logiciel pourrait-il (aisément) deviner qu’un tel bout de texte est en espagnol si on ne le lui dit pas ? Ainsi, il pourrait modifier la manière de lire le texte en fonction de la langue (plutôt logique, non ?). Dans l’optique (certes future) d’un tel logiciel, ainsi que dans l’optique d’une certaine rigueur de conception et de sémantique, il me paraît important de concevoir des pages en HTML qui correspondent au mieux à un classement rigoureux dans les balises correspondantes du texte (et autres) à présenter.
Pour ce qui est (finalement, après j’arrête) de la signature (et pour revenir à la problématique de la lettrine), je dois avouer qu’il manque une balise pour une signature. Il faut donc combler ce manque (et se prémunir contre la mise en lettrine) en balisant notre signature correctement (<span class="sign">(...)</span>, par exemple).

Bref, je suis fatigué. Bonne nuit.

Cordialement, HoPHP

> Le HTML dans le potage

23 mai 2005, message de Juh

Merci d’avoir eu le courage de mettre tout ça sur le "papier", j’ai l’impression d’ailleurs que ça a du te faire du bien. On va encore dire que les français sont raleurs, mais il faut bien quelqu’un pour dire que le roi est nu...

Seulement, quels sont les moyens d’action ? J’attends un commentaire de Tristan Nitot... Oui, bon il va répondre qu’il faut aller coder tout ça dans le cvs de Firefox... Je ne suis pas si sur que son developpement soit si ouvert. Il va falloir se mettre à faire un fork de Firefox, ou des plugins, mais tu en montre les limites... La prise en compte des "standards" doit être installé en "standard" dans les navigateurs...

Et de plus c’est bien un état d’esprit qui pêche. Ces standards, que l’on aime bien pourtant, ont une sorte de raideurs dans leur recherche de pureté qui ne rend pas simple leur intégration à l’existant, et tout simplement leur application au quotidien. Pour qu’un auto-proclamé "standard" se "standardise" vraiment, il faut qu’il soit simple à mettre en oeuvre. Et que Marcel et Roger, pour faire leur homepage l’appliquent sans avoir à faire des études d’informatique.

Est-ce que quelqu’un dans la salle a des pistes d’actions ?

> Le HTML dans le potage

23 mai 2005, message de hCanan

Bonjour,

xhtml n’est que tu html respectant la syntaxe XML. En gros du html propre (on ferme ses balises et on quote les paramètres).
Pourquoi ?
Pour pouvoir traiter les fichiers avec tous les outils et parser XML.
Pourquoi ?
Pour récupérer facilement l’info contenue dans une page.

Ceusses qui militaient pour un html de la france d’en bas (faites pas ch--- avec vos normes petites bourgeoises qui empêchent le populo de prendre la parole) au début du siècle sont obligés d’admettre que cela permet l’interfaçage avec d’autres outils.
De plus cela permet de récupérer ces vielles pages pour les relooker avec moins d’effort.

> Le HTML dans le potage, RastaPopoulos, 23 mai 2005

Mais on peut tout à fait avoir le même (oui exactement la même) propreté en faisant du HTML (strict bien entendu). Le xHTML permet seulement d’imposer cette rigueur à des gens qui ne comprendraient pas la raison d’un code propre. Mais en rien la propreté n’est l’apanage du xHTML, tout comme pour le CSS (voir explication dans l’article).

> Le HTML dans le potage, François Parmentier, 23 mai 2005

Le fait de pouvoir parser du XML pourrait pousser à l’utilisation du XSL.
Je m’étonne de ne pas en avoir vu la trace dans cet article.
XSL a des possibilités que CSS n’a pas.

Les navigateurs modernes semblent capables de passer du xHTML par une « feuille de style » XSL (cette dénomination n’est-elle pas symptomatique ?).

On peut même transformer du XHTML en SVG, non ?

> Le HTML dans le potage

23 mai 2005, message de Bertrand

Paradoxalement, le refus d’affichage d’une page XHTML incorrecte a un aspect positif.
Le développeur sait tout de suite que sa page est incorrecte.
Cela promeut des sites de meilleur qualité.

Personnellement c’est ce qui me permet de faire la première validation des mes développement Web.

Cela dit c’est un réel problème pour les fora et autres sites interactifs. Le wiki
est une solution partielle.

Sinon les limitations des css sont vraiment frustrante.
Si on pouvait déclencher un javascript depuis un motif css, quel progrès, quelle amélioration des applis web.

Sur le (x)Html, les propostions de Ian Hickson d’Opera (je ne suis pas sur de bien me rappeler son nom !) concernant les formulaires auraient été un vrai ballon d’oxygène.

Mais le W3C est durablement parti dans une direction théorique et dogmatique qui laisse le champ libre aux formats proriétaires.

L’espace de liberté d’expression qu’est le web est pourtant directement lié à l’aspect simple et ouvert des technologies employées.
Mais est ce que cette liberté d’expression n’est pas perçu comme une menace par les sociétés et organismes membre du W3C ?

> Le HTML dans le potage, 23 mai 2005

C’est fou comme sur internet il y a toujours quelqu’un pour tourner ça en grand complot planétaire et comme tout semble une menace à la liberté d’expression.
Allons, on peut juger que le W3C fait les choses bien ou pas, mais laisser sous-entendre qu’il s’agit d’un complot des multinationales contre la liberté d’expression sur Internet c’est tout de même osé.

> Le HTML dans le potage, P.A., 24 mai 2005

"Sinon les limitations des css sont vraiment frustrante. Si on pouvait déclencher un javascript depuis un motif css, quel progrès, quelle amélioration des applis web."

Le problème après c’est pour les failles de sécurité ou autres choses comme ca que des petits malins vont s’empecher d’utiliser ...

> Le HTML dans le potage

23 mai 2005, message de Eric Daspet (Ganf)

Rahh, merci, parce que c’est bien plus argumenté que le dernier W3C go home, et bien plus intéressant à discuter. J’y lis beaucoup de mes frustrations à l’égard de ces technologies.

Je me permets juste d’ajouter mes petites précisions :

Sur le passage des limitations CSS.
Certaines sont connues et sont en passe de tomber, notamment les "une ligne sur deux" ou "second paragraphe". Ces choses là sont prévues dans la prochaine version de CSS. Bon, ce n’est certainement pas pour tout de suite, ça arrivera certainement trop tard, mais au moins ils connaissent le problème et tentent de le corriger.
D’autres limitations (besoin de répéter plusieurs fois la même valeur ou couleur sans possibilité de la rappeler par exemple) sont assez frustrantes et ne semblent pas prêtes de disparaître.

Sur les behavior de MSIE.
Tout d’abord Mozilla et MSIE ont le même système. La syntaxe diffère un peu, l’un s’appelle HTC et l’autre XBL, mais c’est kifkif. Là où ça commence à être intéressant c’est que XBL (l’association de code javascript via une syntaxe proche de CSS) est en train d’être intégré à SVG.
Tout ceci veut dire que bientôt le SVG sera bien moins limité coté interactions. Bon, ça ne sera pas flash, loin de là, mais ça corrigera le plus gros manque pour un développeur (je parle bien de développeur et pas de graphiste).

Reste que effectivement toutes les technologies ont des contrecoups. HTML, XML, CSS et les autres ne sont pas plus parfaites que Flash. Pire, toutes ces technologies ont une sphère d’application et ne résolvent pas tous les problèmes.
Maintenant des problèmes et limitations on en trouve aussi (à la pelle) sur flash ou sur ce que tu appelles le "bon vieux HTML pas compliant".
Par exemple, avec Flash, est-ce que tu peux définir un type d’objet qui a la police "helvetica" et un type d’objet avec la police "taille 10pt" et fusionner les deux dans certains textes ? Tu te plains que ce n’est pas faisable en CSS mais, pour autant que je me rappelle (mon flash est loin, je peux me tromper), ce n’est pas non plus faisable dans flash ou dans ta vieille soupe proche du HTML.

> Le HTML dans le potage, RastaPopoulos, 23 mai 2005

Par exemple, avec Flash, est-ce que tu peux définir un type d’objet qui a la police "helvetica" et un type d’objet avec la police "taille 10pt" et fusionner les deux dans certains textes ?

Oui c’est tout à fait possible car désormais ActionScript, le language de programmation intégré à Flash, est plutôt orienté objet. D’où en découle de nombreuses possibilités telle que celle-ci...

> Le HTML dans le potage, ARNO*, 23 mai 2005

Merci pour ces infos. Cependant (sauf erreur), il faut préciser que XBL (XML Binding Language) n’est pas plus un standard avalisé par le W3C que HTC.

> Le HTML dans le potage, Eric Daspet, 23 mai 2005

Je confirme à moitié pour XBL.
En l’état tu as raison. Ceci dit XBL est en passe d’être normalisé pour l’utilisation dans SVG (http://www.w3.org/TR/sXBL/).

Ils en sont encore à l’état de brouillon mais ça permet d’espérer un peu pour l’avenir.

Beaucoup espèrent aussi avoir XBL ou un système similaire de manière générique, pas que pour SVG. Je n’aime pas jouer les madame Soleil mais l’intégration dans SVG forcera peut être un peu la main aux autres groupes pour une normalisation globale.

Reste que tout ça aurait du être déjà présent car ça manque ...

> Le HTML dans le potage, laurentj, 23 mai 2005

XBL est une note du W3C, et sa normalisation est prevue (via SVG)

> Le HTML dans le potage, thierry, 26 septembre 2006

Bonsoir,

Quelle tchatche ! excellente synthèse du bon et du moins bon du web d’aujourd’hui. Au fait... SVG fait-il partie de Firefox maintenant ?

à bientôt

Thierry

en ligne : my site

> Le HTML dans le potage

23 mai 2005, message de Sergio

C’est bizarre, c’est exactement ce que je répète à longueur de forum...

Les tergiversations du W3C, le non-support du SVG, les incompatibilités notoires des navigateurs pour le support du son et de la vidéo (t’as oublié ça la vidéo) et tout ça ont fait le lit de Flash.

> Le HTML dans le potage, Cédric, 25 mai 2005

>et tout ça ont fait le lit de Flash.

Et en meme temps, entre du Flash ou une vidéo en un format proprio breveté, je ne veux ni de l’un ni de l’autre...

Idem pour le son...

Donc bon, le multimedia sur le web, ca voudrait dire une interoperabilité entre tous les systemes d’exploitation et cela n’existe pas !

Alors certe, flash le permet mais sous Mac, windows et linux... Pour le reste, il faut soit se toucher soit passer par une couche d’émulation moisie...

Alors dire je fais du flash parce que y’a rien d’autre, ca me fait penser aux gens qui disent : "Mais on y peut rien, le système est comme ca !". Ben si t’y peux quelque chose, le boycot !

Apres, tu peux regretter que ton site web fasse pas de bruit, mais il faut faire la part des choses, ce qui est important : l’information présente sur ton site, et ce qui est de l’ordre de l’habillage : faire chier tes visiteurs en jouant des sons sur leur pc...

ps : le "tu" dans ce message ne s’adresse pas directement la personne à qui je répond ;)

> Le HTML dans le potage, juju, 7 juin 2005

Apres, tu peux regretter que ton site web fasse pas de bruit, mais il faut faire la part des choses, ce qui est important : l’information présente sur ton site, et ce qui est de l’ordre de l’habillage : faire chier tes visiteurs en jouant des sons sur leur pc...

Mettre du son sur une page web ne veut pas dire « imposer à tous les visiteurs d’écouter ce son » ! Rien n’interdit d’implémenter la même chose dans un navigateur...

Si tu utilises un navigateur en mode texte, les images sont inutiles. Pourtant elles ne font pas forcément « chier »...

Tous les liens hypertextes que tu trouves sur une page sont manipulés comme tels par ton navigateur. Cela t’oblige-t-il à les cliquer tous ?

Un conseil : réfléchis mieux !

> Le HTML dans le potage, Audiofeeline, 28 août 2005

« Mettre du son sur une page web ne veut pas dire « imposer à tous les visiteurs d’écouter ce son » ! »

Mais pourquoi diable n’ont-ils pas fait une balise ?...

en ligne : lol