fastclemmy.com

Article original du 15.10.03 - Ca y est, j'ai officiellement soumis ma participation au CSSZenGarden. Dans le formulaire de soumission, j'ai dû improviser un titre alors j'ai choisi le clin d'oeil avec HoriZental.

Après cette soumission, j'ai un peu regardé l'ensemble des designs du jardin japonais. Si je suis fan de quelques sublimes designs, j'ai découvert avec horreur et stupéfaction deux perles d'illisibilité que je vous recomande chaudement.

Je croise donc les doigts pour que mon design soit retenu, ce qui n'est pas chose évidente étant donné le très haut niveau des dernières soumissions. Avec un peu de chance donc je serai le deuxième représentant tricolore de la sélection officielle du Jardin. D'ailleurs pourquoi a-t-on comme le Danemark et les Pays-Bas un plus petit drapeau que les autres ?

Mise à jour du 21.10.03 - Ca y est ! Ma proposition de design pour le CSS Zen Garden a été validée parmi les design officiels !!! D'ailleurs David Shea le qualifie de "beautiful horizontal scroller". Un grand merci à vous de m'avoir permis de l'améliorer !

Mise à jour du 20.02.04 - Comme le signale Dave Shea, l'initiateur de CSS Zen Garden, j'ai l'immense privilège de me voir cité pour ma participation au CSSZenGarden parmi nombre d'autres designs officiels.

Encore plus gratifiant, savoir dans cet autre post que je fais partie des 5 designs sélectionnés pour illustrer cet article australien. Se retrouver aux côtés de webdesigners aussi talentueux que Dave Shea ou Andy Budd, voilà de quoi faire gonfler mon ego !

#xhtmlCSS

Voici quelques mois maintenant que je suis avec intérêt l'actualité des standards du web par le biais des nombreux weblogs francophones ou anglophones. Plus récemment encore, je prenais modestement part à l'aventure en ouvrant ce blog. Voici venu le moment de vous livrer mon analyse personnelle sur l'évolution possible de ce microcosme bouillonnant.

Constats d'échecs

  • On a une blogosphère éclatée, avec une multitude de weblogs au contenu assez similaire.
  • La différenciation des blogs vient uniquement de leur charte graphique, de leur fréquence de mise à jour ainsi que du ton général du blog.
  • Chaque blog repose sur un rédacteur unique avec ses convictions, ses oeillières, sa disponibilité variable.
  • La stabilité d'un blog est toute relative, sa périodicité est souvent aléatoire, ponctuée par des pauses plus ou moins longues, parfois même des fermetures définitives et des renaissances.
  • L'archivage des informations est très problématique à cause de l'ordre chronologique inverse et de l'insuffisance du système des catégories.
  • De manière générale on sent une tendance à "tourner un peu en rond" à cause du domaine très (trop) pointu traité.

Quelles évolutions possibles ?

La tendance à la syndication de contenu (RSS, Atom, etc.) devrait nous pousser à réfléchir à un nouveau système de publication. Pourquoi pas un site fédérateur où tous les acteurs de la blogosphère se réuniraient pour enfin centraliser les informations ? C'est d'ailleurs un mouvement qui émerge de manière embryonnaire chez Cybercodeur où Denis co-écrit avec Bleizig ou chez Znarf où les wiki-commentaires ont presque autant d'importance que les billets eux-mêmes.

Fédération, le mot est lâché. Quel intérêt en effet de voir sur 10 weblogs différents que Mozilla Europe vient d'ouvrir ? Quelle chance a une personne qui s'intéresse aux standards de tomber sur le lien concernant les bugs d'IE Mac si celui-ci est signalé quelque part dans les archives d'un weblog peu connu ?

On pourrait donc imaginer un système de publication bénéficiant des nombreuses plumes existantes, des liens que chacun peut dégoter tout en offrant ce contenu dans un lieu unique, connu de tous (au même titre qu'un Pompage ou qu'un OpenWeb).

Libre ensuite à tout le monde de récupérer ce contenu commun pour le placer sur son propre weblog, avec sa charte graphique.

Un atout de poids permet d'envisager cette fédération de contenus : un quasi-standard de fait dans la forme des weblogs (titre, date, catégorie, texte du billet). En s'entendant sur les formats, on pourrait rapidement mettre cela en oeuvre.

D'ailleurs, cette initiative montrerait pour une fois que les nouveautés dans la blogosphère peuvent naître ailleurs que dans la sphère anglophone...

#nombril

Certains ont déjà écrit çà et sur les arguments avancés par les anti-standards. Malheureusement, la plupart du temps, inexactitudes, contre-vérités et trolls venaient discréditer lesdits articles. Voici donc ma vision critique de la conception par blocs, vue par un farouche pro-standards.

La conception par blocs a tous les atours de la méthode idéale, une abondante littérature nous détaille avec force et conviction tous les avantages induits par cette façon de procéder. Pourtant, l'expérience nous prouve que non, ce n'est pas (encore ?) la solution idéale.

Des normes en gestation et longues à mettre en place

Tout d'abord, les spécifications édictées par le W3C sont des recommandations, ce qui laisse toute latitude aux navigateurs pour faire n'importe quoi, d'ailleurs qui ira leur taper sur les doigts ? L'établissement des nouvelles versions des standards HTML et CSS est un processus long car il se décompose en trois étapes. Tout d'abord, un petit groupe réfléchit aux améliorations que l'on pourrait apporter, discute, rédige des brouillons de spécifications et aboutit finalement à une recommandation finale. En plus de ce long temps de gestation, il faut (et c'est souvent là que ça coince) que les navigateurs prennent en compte ces nouvelles normes. Si les développeurs réactifs de Mozilla, Safari ou Opera font leur maximum pour coller au mieux aux dernières specs, Internet Explorer est à la traine dans ce domaine. Enfin, il faut attendre que le grand public adopte les derniers navigateurs sortis. Quand on sait qu'il y a encore des parcs informatiques entiers qui tournent sous Netscape 4, on se rend compte du hiatus entre le microcosme établissant les standards du web et la réalité des outils utilisés pour y accéder. L'idéalisme de la conception par blocs doit bien se confronter à cette dure réalité.

Du côté des insuffisances en matière de normes, tout le monde les reconnaît, c'est d'ailleurs pour ça que le W3C travaille sur XHTML 2 et CSS 3. Parmi les fonctionnalités les plus attendues, on pourrait citer le téléchargement des polices ou bien le support des blocs multicolonnes. Deux exemples parmi d'autres qui prouvent si besoin était que les recommandations actuelles ne satisfont pas encore tous les besoins des designers web.

La promesse du support multi-navigateurs

Utiliser les standards du web devait mettre fin au cauchemar du webdesigner que Tristan appelle la balkanisation du web. Pour faire rapide, il s'agit de ne ne plus devoir développer des versions spécifiques pour l'un ou l'autre navigateur en utilisant pour chacun des balises propriétaires. Tristan mentionne que le seul frein à cette évolution majeure reste l'antédiluvien Netscape 4 et prône l'idée de Zeldman (datée de 2001 !) de l'envoyer paître. L'astuce consiste donc pour la majorité des sites faits en XHTML/CSS à ignorer purement et simplement les informations de style pour NN4 en employant une syntaxe spécifique lors de la déclaration de la CSS. Mais voilà, c'est un peu l'arbre qui cache la forêt. La promesse d'un site qui passe correctement sur tous les navigateurs est subordonnée à leur conformité aux normes, or les différentes versions de l'hégémonique Internet Explorer ont de graves lacunes dans ce domaine. La nécessité de ruses multiples pour y remédier créé de fait une nouvelle balkanisation. Et avec les 90 à 95% de parts de marché d'IE ce n'est malheureusement pas demain que cette donnée changera...

La promesse de la séparation contenu/présentation

Philosophiquement, la conception par blocs consiste à faire une séparation nette entre structure (dans le fichier HTML) et présentation (dans le fichier CSS). On comprend vite l'intérêt que cela présente quand on veut modifier la mise en page rapidement, partager un fichier HTML pour le proposer sur un autre site "en marque blanche" ou bien encore pour faciliter la maintenance. Pourtant là encore, à l'épreuve des faits, on se rend compte que la promesse n'est pas tenue. J'en veux pour exemple l'utilisation du positionnement flottant où l'on se rend rapidement compte que l'ordre des éléments dans le fichier HTML a une incidence sur le comportement flotant des blocs. Dans certains cas on doit intervertir des éléments dans le fichier HTML pour arriver à ses fins en termes de présentation.

La promesse de la réduction/clarté du code

Argument souvent avancé pour promouvoir les standards : un code plus léger et plus clair. Il est évident qu'une page construite avec un squelette XHTML propre est très nettement plus limpide qu'une page équivalente construite à base de tableaux, voilà l'un des bénéfices de la séparation contenu/présentation. Là où le bât blesse (et c'est l'un des très rares points auquel je donne crédit dans l'article d'EMMA), c'est dans la clarté du fichier CSS. Du premier coup d'oeil impossible de voir la construction de la page, la description linéaire des styles impose un investissement important pour comprendre les grands concepts de la mise en page. Voilà qui paraît très obtus au débutant qui tente de percer les secrets d'une mise en page en affichant la source. De même, pour ce qui est de la réduction du code, si mathématiquement il est avéré qu'un site en XHTML/CSS est moins lourd qu'un site équivalent en tableaux, dans la pratique le fichier CSS d'un site est toujours lourd et indigeste. A ce titre, la maintenance des fichiers CSS révèle qu'on est loin de la promesse initiale de clarté du code.

Tous ces arguments démontrent bien que la méthode que nous autres pro-standards défendons n'est en aucun cas la panacée. La réalité du marché du web, les insuffisances des normes et de leur implémentation, notre expérience de la conception XHTML/CSS doivent nous amener à prendre conscience de ses limites.

Toutefois, en regard de la seule alternative consistant à créer des sites web "à l'ancienne" (mise en page en tableaux, balises propriétaires, astuces et détournements divers), la conception par blocs apparaît comme la seule méthode valable. Chaque jour qui passe nous rapproche un peu plus de l'avènement programmé des standards du web.

#xhtmlCSS

Au voleur !

# 03-02-2004

Article original du 15.09.2003 - Une chose dont on parle assez peu sur les blogs XHTML/CSS (mon obsession de parler de choses originales me pousse donc à en parler), c'est le piratage de design facilité par l'utilisation de la conception par blocs.

Je dois avouer que c'était pas une chose à laquelle je n'avais pas pensé, mais le problème a été soulevé par un ami sur un forum. Il se plaignait de la non "sécurisation" des CSS : en volant la feuille du style d'un site, on peut très facilement faire la mise en page d'un autre site en changeant quelques images et en insérant son contenu dans la page HTML. Certainement plus simple que de repiocher dans le code fouilli d'un site fait à base de tableaux (encore que ?).

Preuve faite avec Openweb, référence francophone en matière de conception par blocs qui se faisait plagier à de nombreuses reprises. Preuve aussi avec le créateur du CSSZenGarden qui a tergiversé quelques jours pour déterminer sa position sur les conditions de mise à disposition des designs créés pour le CSSZenGarden. Dans les deux cas, les propriétaires des sites plagiés ont laissé globalement faire, se disant à juste titre, AMHA, que le préjudice subi n'était pas si terrible au fond.

Cela dit, cette problématique ne peut que nous faire réfléchir sur le degré de malhonnêteté de certaines personnes...

Mise à jour du 03.02.2004 - Un petit tour dans mes référents m'a fait tomber sur ce site de danse. Pas vraiment un voleur, puisque je suis cité en tant qu'auteur du design original, mais comme quoi, personne n'est à l'abri...

#conceptionWeb