fastclemmy.com

Quand les initiatives sont excellentes, il faut que ça se sache ! Je dépoussière donc mon admin pour vous parler de la pétition pour l'accessibilité numérique mise en ligne par Vincent Aniort, Aurélien Levy et Franck Galey

Elle vise à mobiliser nos chers politiques pour enfin mettre en œuvre la loi pour l’égalité des droits et des chances, votée il y a plus de 3 ans maintenant (souvenez-vous !). Malgré l'implication de nombreuses bonnes volontés, le concept est encore flou voire même inconnu de nombre de décideurs ou, pire, d'acteurs du monde du web.

Pour que cela change, il est impératif que l'accessibilité devienne une obligation légale, pour les sites publics dans un premier temps. Et que peut-on faire pour que ce décret sorte enfin et que l'on commence à prendre conscience de ce pilier fondamental du web ? Signer bien sûr !

#xhtmlCSS

ParisWeb 2007, c'est fini. 2 jours de conférences + 1 journée d'ateliers pratiques, de quoi se régaler en termes de standards et de qualité web en général. J'ai pour ma part assisté pour vous aux 2 journées de conférences et je profite de l'occasion pour vous livrer mes impressions sur ces débats très enrichissants.

Les conférences du jeudi

Couché un peu tard à cause de la mise en ligne du nouveau lilolipop.com (mais je vous en reparlerai), c'est mon réveil qui a fait la grève jeudi matin. Résultat, en me réveillant à 9h30, j'ai assez vite émis l'hypothèse que je ne serai probablement pas à 8h30 à La Défense ;-) L'avantage, c'est que le taux de compression sur la ligne 1 n'était que de 95% à l'heure où j'ai pris le métro...

Retrouvant à peu près sans encombre mon chemin jusqu'à la Tour IBM Descartes, j'ai juste le temps de prendre mon badge pour assister à la fin de la deuxième conférence (snif, j'aurais loupé celle de Sam...) : celle de Michèle à propos des contenus web. Je ne sais pas si c'est parce que j'ai manqué le début, mais j'avoue que je suis resté un peu sur ma faim, l'idée principale que j'en ai retenue étant que Promovacances mettait plus en avant le prix qu'un tour opérateur "culturel" comme Excursia, en effet.

A peine installé que c'était déjà l'heure de partir en pause déjeuner. L'occasion d'échanger avec d'autres aficionados du web : Denis, Elie, Stéphane et les autres.

Pour digérer, Myriam nous a fait un point sur les contraintes entre les demandes des utilisateurs et des décideurs, rarement en phase.

Ensuite, les choses sérieuses ont commencé avec une explication du contexte et de la mise en place du RGAA (référentiel général d’accessibilité des administrations). En gros, ce sont les règles d'accessibilité qui vont s'imposer à tous les sites publics d'ici à 3 ans. Cela se matérialise par une batterie de principes généraux validés par une centaine de tests unitaires (ex : "Toutes mes images possèdent-elles un équivalent textuel ?" Oui/non). Le chantier s'annonce énorme, donc si vous ne savez pas quoi faire dans les quelques prochaines années, je vous suggère de vous former à l'accessibilité et de créer votre boîte spécialisée pour profiter du gâteau !

Avant-dernière conférence de la journée, c'est Jean-Louis qui nous a fait un très intéressant point sur les solutions de sous-titrage pour les vidéos avec différentes technologies (Real, SMIL, Flash, etc.). Le plus bluffant était certainement ProTitle (très mal référencé sur leur site !), qui fait de la reconnaissance vocale pour faire du sous-titrage en quasi-temps réel.

Enfin, the last but not the least, Mister Daniel Glazman himself, nous a fait un excellent état des lieux sur HTML 5. On voit que les choses ont bien changé depuis l'an dernier, c'est bon signe. Comme d'habitude, son oeil d'expert allié à un discours sans langue de bois nous a bien éclairé sur l'avancement de cette nouvelle norme (d'ici 2010 !). Côté implémentation dans les navigateurs, il a souligné le fait que certains éléments cette nouvelle norme commencent déjà à faire leur apparition dans Safari, Firefox et Opera. Nous pourrions donc en retirer les bénéfices plus vite que prévu !

Les conférences du vendredi

De bon matin, c'est Denis qui nous a donné les grandes lignes de l'accessibilité de Flash et de PDF (en gros : si vous pouvez faire du HTML, ça sera toujours mieux !). Excellente mise en bouche.

Stéphanie nous a ensuite éclairé sur les différentes problématiques liées à la localisation et à l'internationalisation. Conclusion : prévoyez cela bien en amont de chacun de vos projets !

Décidément, cette édition 2007 de ParisWeb aura fait la part belle à l'accessibilité, avec une présentation de Michel sur la question avec un focus sur AJAX, même si cela est resté assez général.

L'après-midi, place à la superstar de Yahoo!Angleterre, Chris Heilmann avec une excellente remise en perspective du travail en équipe autour des standards du web. Tous les responsables de studio ou les chefs de projet techniques en agence devraient la lire et la mettre en pratique chez eux.

Dominique, membre du W3C, a ensuite déroulé les grandes lignes des bonnes pratiques pour le développement sur mobile (si vous faites du bon travail pour le web, ça devrait vous faciliter le travail).

Et pour terminer la journée une table ronde avec une discussion à bâtons rompus entre quelques orateurs et un public avide de débat !

Vous pouvez retrouver les photos de l'événement en attendant la mise en ligne des slides de toutes ces conférences.

En conclusion, une grande cuvée de ParisWeb, très centrée sur l'accessibilité, vivement la prochaine !

#xhtmlCSS

Approchez mesdames, messieurs, la conférence francophone incontournable sur le web et ses multiples enjeux approche à grands pas : c'est l'édition 2007 de ParisWeb.

Comme l'indique très justement François, c'est le moment de parler autour de vous de ce rendez-vous unique dans le monde du digital. C'est l'endroit où des intervenants remarquables (comme dirait l'autre) viennent à la rencontre d'un public mixte de décideurs, de communiquants, de développeurs, de webdesigners, pour leur parler d'un meilleur web.

Vous aviez loupé l'édition 2006 ? Pas d'excuse pour louper celle de 2007. Jetez un oeil au planning, dites-vous que ce seront 100 + 10 euros bien investis et venez échanger pendant 3 jours avec la crème de ceux qui font le web aujourd'hui (et surtout de demain).

Alors, vous êtes encore là à me lire ? Cliquez, je vous dis !

Paris Web 2007, 15, 16 & 17 novembre

#xhtmlCSS

Il suffit parfois d'un petit déclic pour redonner envie de bloguer, c'est le cas avec la sortie d'une application bien pratique, K-HTML, offerte par l'excellent Normand Lamoureux.

Pour présenter l'outil, je laisse l'auteur vous en faire la description :

K-html est un outil léger destiné aux webmestres pour ajouter rapidement du code HTML à l'aide de raccourcis clavier dans n'importe quel éditeur de texte. Ces raccourcis peuvent être mémorisés pour plus d'efficacité ou retrouvés grâce à l'Aide-mémoire conçu à cet effet.

Et c'est l'un des gros avantages de K-HTML, il ne vous impose pas un outil d'édition HTML en particulier, puisqu'il vient en surcouche à celui auquel vous êtes habitué. Votre éditeur de texte sous Windows ainsi boosté aux amphétamines n'aura plus à rougir face à un TextMate sur Mac.

Le seul inconvénient du programme, mais comme tout nouveau logiciel, c'est la courbe d'apprentissage des nouveaux raccourcis clavier. Une fois que vous les aurez apprivoisés, votre code s'écrira presque tout seul ! A vous argent, gloire et conquêtes féminines ! Mais n'oubliez pas de remercier Normand...

Dernier petit commentaire, le nom du programme qui peut prêter à confusion avec le moteur de rendu HTML éponyme, un petit changement s'impose-t-il comme lorsque Phoenix puis Firebird ont finalement abouti à Firefox ?

#xhtmlCSS

J'ai enfin un peu de temps pour vous rendre compte de mes impressions sur l'événement majeur qui a animé le microcosme des standards du web : la première édition de Parisweb organisée de main de maître par Eric Daspet, Stéphane Deschamps et Adrien Leygues.

J'ai tout d'abord un regret, celui de n'avoir pu me libérer que pour la 2e journée, à savoir celle du vendredi. Néanmoins, j'ai ainsi eu l'occasion de suivre attentivement les présentations successives de Denis Chêne ("Design for all"), Rémy Birambeau (gestion de projets en milieu associatif), Daniel Glazman (historique d'HTML & CSS), François Nonnenmacher (le redesign de capgemini.com), Denis Boudreau (pour un développement web durable), Karl Dubost (introduction au web sémantique) et des intervenants de la table ronde technique.

J'aurai l'occasion dans les prochains jours de revenir sur chacune de ces présentations pour vous restituer ce que j'en ai retenu et prolonger la réflexion avec vous.

Réglé comme du papier à musique

C'est sans réserve que je participe au cirage de pompes généralisé (et mérité !) des organisateurs de Parisweb 2006. C'est d'autant plus rafraîchissant que les 3 compères apportent du renouvellement par rapport aux "barons" des standards du web, preuve que quand on veut, on peut !

Désolé d'en remettre une couche pour les absents, mais c'était vraiment le pied ! L'organisation était réglée comme une horloge : accueil parfait, horaires respectés, enchaînements fluides, une vraie gageure pour une première édition.

Presque parfait !

Comme les organisateurs l'ont réclamé, voici les quelques points, en vrac, que l'on pourrait éventuellement améliorer pour la prochaine édition :

  • Des problèmes techniques l'ont empêché cette fois-ci, mais avec un peu de chance on aura une connexion Internet la prochaine fois !
  • Ce qui pourrait d'ailleurs permettre plus de réactivité sur le blog officiel. On pourrait par exemple avoir un groupe de rédacteurs qui donneraient leurs impressions en direct ?
  • Parisweb 2006 a trouvé un large écho au sein de la blogosphère des standards du web, mais rien n'a filtré en dehors de ce petit cercle d'initiés, aucune mention dans le Journal du Net, dans la lettre de l'Atelier ou autre publication dans le domaine du (web)marketing. Que faut-il en conclure ? Que ces publications préfèrent faire la promotion de leurs propres événements à 850 € minimum la journée ? Ou qu'il faudra faire plus du côté des relations presse dans ce domaine l'an prochain ?
  • Il manquait peut-être un petit côté informel à ces conférences. J'ai dans la tête l'image de conférences un peu anarchiques, avec des gens assis dans des couloirs avec des portables sur les genoux, des sortes d'ateliers improvisés.

En attendant mes billets suivants concernant les conférences données à Parisweb, je vous recommande de jeter un oeil aux vidéos et aux photos de la conférence. Et vous, vous y étiez ?

#xhtmlCSS

Remise au goût du jour d'un des premiers articles publiés sur ce blog (30 juillet 2003). Vous pouvez également le retrouver sur le Wiki de W3Québec, riche en informations sur les standards.

L'idée qu'un site web conforme et/ou accessible ne soit pas esthétique est un lieu commun souvent entendu dans la bouche des détracteurs des standards du web. Pourtant, cette assertion ne repose sur aucune réalité tangible. Elle est seulement le fruit de circonstances liées au mouvement des standards du web.

Les normes, une affaire de programmeurs avant tout

La sensibilisation aux standards du web a commencé historiquement dans le milieu des programmeurs/intégrateurs Internet. Assez logique finalement, car appliquer les standards du web, c'est avant tout un travail qui se fait au niveau du code (X)HTML.

Aux premières loges pour découvrir tous les bénéfices que peuvent apporter un code conforme et accessible, ce sont donc eux qui ont été les premiers moteurs de la prise de conscience, ont construits les premiers sites (X)HTML/CSS. Sensibilisés aux normes, mais n'ayant pas forcément une sensibilité graphique. D'où le reproche de sites web "trop carrés".

Une mise en oeuvre restreinte au domaine des weblogs

Un autre facteur qui a renforcé le sentiment que la conformité avait une influence sur l'aspect graphique d'un site est que les premiers sites conformes étaient essentiellement des carnets web (weblogs).

Il ne s'agit là encore qu'un concours de circonstances.

Il se trouve que le mouvement autour des normes a coïncidé (participé ?) avec l'émergence du phénomène des weblogs. Les différentes plateformes de blogging ont d'ailleurs rapidement adopté des structures (X)HTML valides en conséquence. Avec leur sempiternelle structure barre de menu/articles triés par date/liste de liens, on en est abusivement venu à penser que l'utilisation des normes imposait une structure spécifique (2 ou 3 colonnes).

Heureusement, l'initiative CSSZenGarden lancée par Dave Shea a démontré que les possibilités graphiques n'étaient en rien limitées par XHTML ou CSS. En changeant simplement la feuille de style et les images, on peut ainsi visionner le même site avec des mises en page totalement différentes.

Une approche nouvelle

Enfin, il est bon de signaler que la conception aux normes est encore très jeune, les meilleurs exemples de sites conformes et beaux sont donc sans doute à venir !

Des sites conformes, accessibles... et beaux !

Pour consulter des ressources prouvant qu'on peut faire des sites conformes et accessibles sans sacrifier l'apparence, je vous invite à consulter le log intitulé Classious Style Sheets.

#xhtmlCSS

Petite nouveauté sur fastclemmy.com, un invité de marque a bien voulu prendre un peu de son précieux temps pour répondre à quelques questions portant sur les normes et les standards du web. Découvrez ci-dessous le point de vue éclairé d'Eric Daspet sur le sujet.

"Norme" et "standard", ces deux termes recouvrent-ils des réalités différentes dans le domaine du Web ?

"Pour moi normes et standards sont indissociables. Une norme c'est un ensemble de règles qu'une réalisation se doit de respecter (normes de qualité par exemple). Le terme de standard recoupe lui l'idée de l'établissement de conventions communes ou générales (format standards des feuilles de papier par exemple).

Or pour échanger avec les autres, ce qui est le but du Web, parler tous la même langue est un impératif. Une application se doit de respecter tout standard établi. Dans une optique d'échange d'informations standard et norme cernent à mon avis le même concept, celui de l'intéropérabilité. Ils prennent juste ce concept par des optiques différentes et complémentaires."

Dans quelle mesure les "standards de fait" ont-ils une légitimité ?

"Tout d'abord je n'aime pas cette expression, c'est accoler volontairement une connotation d'usurpation au mot "standard". Le terme contient déjà une notion d'illégitimité quand on lui accole ce suffixe. Je vais donc parler de "standard", peu importe d'où il vient ou comment il a été établi.

Le but c'est de communiquer ensemble. Un bon parallèle que j'aime utiliser c'est celui de la langue. Dans notre langue parlée on utilise beaucoup d'expressions qui ne sont pas vraiment correctes, de mots qui sont inventées ou construits sur le moment. Même si on ne les retrouve pas dans le dictionnaire, si tout le monde les comprend notre but est atteint. Inversement, si j'utilise des mots du dictionnaire qui sont inconnus par la majorité, je n'aurai pas atteint mon objectif.

Pour le Web notre but est aussi de communiquer. Tout ce qui peut nous faire communiquer ensemble est de fait légitime. Le standard, la convention commune, l'est donc aussi.

Maintenant, si le standard est légitime, n'allez pas penser que ça rend illégitime ou inutile la démarche normative. Les deux sont complémentaires et nécessaires.

Si j'invente des nouveaux mots ou que j'utilise une expression propre à ma région, mes interlocuteurs ne me comprendront pas forcément. Si ce mot est dans le dictionnaire ils auront au moins la même base que moi pour en comprendre le sens.

Sur le Web c'est la même chose. Le problème des "standards de fait" comme on les appelle sur le Web, c'est qu'ils ne sont écrits nulle part. Personne ne peut les consulter comme un dictionnaire. C'est d'autant plus important sur le Web où tout est interprété par des machines, donc les sens ne peuvent être devinés à partir du contexte ou des usages. Ce qu'il faudrait c'est un texte qui décrit tout ce qui est utilisé pour en connaître le sens et le rôle : une norme.

L'idéal c'est d'utiliser le recoupement du standard et de la norme. On utilise des mots dont le sens est défini (dans la norme), en privilégiant ceux qui sont dans la base commune couramment utilisée (le standard)."

Peut-on dire que la standardisation du Web a échoué ? Si oui, pourquoi ?

"Echoué ? Non. La plupart des pages sont "lisibles" et leur code semble quelque chose de compréhensible. La standardisation a réussi, nous avons bien un langage unique utilisé par tout le monde. Dans d'autres industries ou technologies il existe plein de langages ou de règles incompatibles parmi lesquelles choisir. Pensez par exemple aux graveurs DVD avec leur DVD+R et DVD-R incompatibles. Là, effectivement, on peut dire que la standardisation a échoué, pas sur le Web.

Je dirai plutôt que c'est le processus de normalisation qui avait échoué ("avait" parce que c'est en passe de changer). Les gens utilisent bien un même langage, mais pas de la même façon, avec des expressions "locales" et non connues par les autres. Ce qu'il manque c'est justement un dictionnaire pour dire ce qui existe et le sens que ça a. En réalité ce dictionnaire existe, mais peu de gens le connaissent, l'utilisent et s'en servent comme référence (ce qui au final revient au même qu'un dictionnaire qui n'existe pas).

Ceci dit, rien n'est jamais perdu. On peut faire revenir les gens vers un processus normalisé, c'est justement ce qui est en train de se passer doucement sur le Web. On peut le faire en profitant d'un saut technologique, c'est par exemple ce qui est souvent fait grâce à XHTML. On peut aussi le faire en montrant aux intervenants les avantages du respect d'une norme commune, c'est ce qu'il risque d'arriver avec la montée de Mozilla Firefox. Cette seconde démarche me semble d'ailleurs beaucoup plus pérenne pour le long terme."

Un peu de prospective, quel avenir pour les standards du Web ?

"Je prend la question de manière vague : standard, recommandations, normes et tutti quanti. Je dirai que l'avenir est plutôt bon. Les moyens d'accès se diversifient tous les jours, les internautes sont plus exigeants sur la présentation et l'accessibilité du contenu. Coté français on a aussi le point positif de l'état qui commence à imposer des choses sur l'accessibilité de ses propres sites Web. Tout ça remet au goût du jour l'utilité d'un langage commun et recentre la problématique de l'interopérabilité. Si je devais faire un pari ça serait que dans quelques année le nombre de développements qui n'ont pas les normes en tête lors de la conception devraient se retrouver minoritaires.

Si je devais jouer les Madame Soleil je dirai que ça risque de suivre la même courbe que toutes les technologies. La standardisation est en passe de devenir une préoccupation majeure de pas mal de monde, peut être même de façon un peu extrême. On a déjà des exagérations de tout bord. Le soufflé risque donc de retomber un peu quand la phase de découverte sera passée. Les gens vont se rendre compte que non, respecter une norme ne rend pas directement beau, accessible, fort, intelligent et ne résoudra pas la faim dans le monde. Après viendra la phase de pérennisation où on va se recentrer sur ce qu'apporte réellement ces normes, pourquoi elles sont là et quelle place elles doivent avoir.

Ce que j'espère c'est que les gens ne feront pas monter le soufflé trop haut et réduiront la phase de découverte au strict minimum. Plus on exagère dans la première phase, plus on tombe de haut et moins la dernière phase risque de s'établir au bon niveau. N'exagérez donc s'il vous plaît pas trop le rôle des normes : elles sont indispensable, les respecter est nécessaire, mais non ça n'est pas de la poudre magique qui résoudra tous vos problèmes et qu'il faut traiter aussi cérémonieusement que le saint suaire."

Un grand merci à Eric Daspet de s'être prêté au petit jeu des questions/réponses. N'hésitez pas à réagir dans les commentaires et à vous manifester si vous souhaitez retrouver d'autres rendez-vous de ce genre sur fastclemmy.com.

Je rappelle par ailleurs, toujours dans le domaine des technologies web, que l'excellent PHP 5 avancé dont Eric est le co-auteur est toujours disponible à la vente et que je vous le recommande chaudement.

#xhtmlCSS

Mauvaise impression

# 26-08-2004

Par le miracle de la séparation contenu/présentation, on est en mesure de créer une version imprimable d'un document HTML sans avoir à refaire deux fois le travail. Ca, vous le saviez sans doute déjà, car vous avez bien entendu lu les articles de référence sur le sujet.

Pourtant, il y a quelques petites choses à savoir avant de s'aventurer dans le domaine...

Pas de bras, pas de chocolat

Ca peut paraître idiot, mais si vous ne spécifiez pas de feuille de style pour l'impression et bien votre site risque fort de s'imprimer... sans style ! Autant dire que ça ne ressemblera pas à grand chose. Ma grande fainéantise sur fastclemmy.com vous donne un exemple concret du résultat que cela peut donner. Donc, même si cela prend quelques minutes, prenez le temps de faire une feuille de style pour avoir un rendu correct à l'impression. Ceci consiste généralement à mettre une police à empattements type Times New Roman plutôt que bâtons, de cacher les éléments de navigation et de spécifier des marges cohérentes. C'est bon ? Testez maintenant !

background-visibility:hidden;

Jusqu'à présent, il y avait deux types de méthodes. Soit l'auteur du site avait prévu une version spécifique pour l'impression s'affichant généralement dans une nouvelle fenêtre, soit l'utilisateur imprimait la page telle qu'il la voyait à l'écran. Dans les deux cas, pas de doute possible, il y avait une concordance entre la mise en forme de l'information sur son écran et sur son imprimante.

Avec l'utilisation des feuilles de style pour l'impression, cette similarité est très souvent mise à mal. Cela est dû notamment au fait que, par défaut, le navigateur désactive toutes les informations concernant les éléments d'arrière-plan (background-color et background-image). La conception par blocs encourageant à utiliser au maximum ces propriétés pour les images illustratives sur les sites, on se retrouve vite avec une page très vide quand on l'imprime "à poil". Difficile de rendre une mise en page sexy quand on ne peut pas jouer avec des images ou des fonds de couleur (regardez par exemple le rendu désastreux à l'impression du par ailleurs magnifique à l'écran PGA.com).

On se retrouve donc coincé entre le marteau et l'enclume, avec une très belle opportunité (la séparation contenu/présentation avec des feuilles de style spécifiques pour l'impression) contrecarrée par un comportement par défaut des navigateurs qui nous limite sévèrement côté créativité. L'idéal serait bien sûr que le navigateur désactive les éléments d'arrière-plan pour les pages ne possédant pas de feuille de style print mais qu'il les imprime dans le cas contraire. En effet, on peut supposer que si une feuille de style pour impression à été mise en place, celle-ci devrait utiliser judicieusement les éléments de background... Euh, on implémente ça dans Firefox 1.0 ?

#xhtmlCSS

A juste titre

# 11-08-2004

Parmi les commentaires laissés suite au redesign de fastclemmy.com (outre les coups de Baygon ;-), Sam (ai-je déjà signalé que j'étais fan de son nouveau design ?) a pointé les incohérences flagrantes du balisage des titres de mon site.

L'occasion rêvée pour moi de réfléchir sur la structure des documents et le balisage des titres avec les balises <hX>. Amusant d'ailleurs, car le sujet a agité la blogosphère anglophone il y a à peine plus d'un mois (lire , , , , et ).

Remarque préliminaire : la réflexion qui suit se base uniquement sur le balisage de ce weblog, d'autres pistes sont bien sûr envisageables pour d'autres types de sites.

La balise <h1>

Commençons donc par le début : <h1>. Il est de coutume de mettre le titre du site web dans cette balise, Zeldman, Denis, la plupart des utilisateurs de Dotclear le font. Logique ? Peut-être, mais il est sûr en tout cas que ceci fait doublon avec la balise <title>, ce qui m'inciterait plutôt à éviter cette habitude. Que mettre d'autre dans ce <h1> dans ce cas ? Du contenu utile évidemment, en l'occurrence pour ce weblog les titres des différents logs.

De plus, cette méthode permettrait de résoudre le cas de conscience qu'ont certaines personnes à utiliser plusieurs fois la balise <h1>. Au passage, rien ne dit dans les spécifications d'HTML qu'il est interdit d'utiliser plusieurs fois cette balise.

Interaction avec la structure

Un autre élément de réflexion qui m'est apparu en abordant ce sujet de la structuration des documents est l'interaction avec le reste du site. Le langage HTML a été conçu au départ pour baliser des documents scientifiques, pas réellement des sites web comme on les conçoit maintenant. Dans cette perspective, faut-il baliser les éléments de navigation avec des éléments de titrage de type <hX> ? Le risque de parasitage du contenu me conduit à penser qu'il vaudrait mieux l'éviter.

En conclusion, je pense partir sur une structure très simple au final : <h1> pour les titres de logs, <h2> pour les sous-titres à l'intérieur des logs. Le reste étant des éléments de navigation ils ne méritent pas de balisage spécifique. Et vous, qu'en pensez-vous ?

#xhtmlCSS

La fin d'un projet sur lequel je travaille depuis quelques semaines déjà commence à approcher. Voici quelques retours d'expérience "de la vraie vie" que j'aimerais vous faire partager.

Note : penser à éventuellement mettre à jour ce log.

Organisation des fichiers

Visiblement, il n'y a pas encore de règle de l'art en la matière. Pour ma part, pour éviter les feuilles de style à rallonge, j'ai expérimenté une nouvelle fois avec succès que j'appellerais le "toutpareilsaufque".

Mettons d'abord de côté la feuille de style de la page d'accueil qui a souvent des spécificités très différentes du reste du site. Le coeur du système, c'est une feuille de style "commun.css" qui, comme son nom l'indique, regroupe les caractéristiques communes à toutes les pages (typo utilisée, effets sur les liens, disposition générale des grands blocs, etc.). Ensuite pour les pages où des propriétés ponctuelles sont nécessaires, je crée une feuille de style qui @import(commun.css) avant de les déclarer. Quels avantages ? Une séparation claire des fichiers, des feuilles de style individuellement raccourcies, une maintenance facilitée.

Ainsi, pour mettre en place une image illustrative indiquant la rubrique du site dans laquelle on se trouve on procèdera comme suit. On affecte un id du nom de la rubrique à la balise >body<. Dans la feuille de style "commun.css" on déclare les propriétés générales du bloc d'image (position, marges, etc.). Dans une feuille de style "nomDeLaRubrique.css" on précise simplement le nom de l'image en question. Et le tour est joué !

Positionnement : the simpler, the better

Assurément, la tâche la plus compliquée dans la conception par blocs reste le positionnement. Je peux maintenant dire d'expérience que l'on a tout avantage à garder la structure la plus simple possible. D'ailleurs si cette attention est portée dès la conception du design graphique du site, vous vous éviterez quelques désagréments par la suite.

Si le positionnement absolu peut paraître sexy avec son approche au pixel près et son comportement relativement homogène dans les navigateurs, quelques inconvénients font qu'il ne peut s'appliquer à tous les éléments d'un site :

  • il est peu compatible avec une mise en page liquide
  • il ne permet pas d'obtenir des pieds de page "mobiles"
  • il risque de créer des problèmes de chevauchement

De manière générale essayez donc de conserver au maximum le flux normal des éléments (empilement des boîtes) pour ne pas avoir de surprises désagréables avec les différents brouteurs.

Pensez aux nouvelles bonnes méthodes

Le concept des image-maps vous plaisait ? Ca tombe bien, il est encore possible d'en faire, mais avec la (bonne) manière. Pour cela, inspirez-vous de l'article d'ALA sur le sujet, mettez-le à votre sauce. Et le tour est joué ! Dans mon cas, j'ai utilisé une simple liste linéaire avec une image d'arrière-plan et des les éléments étaient des liens dans des >span< que j'ai caché via la propriété display:none.

Pas de tableaux mais...

Hérésie, j'ai utilisé des tableaux pour mettre en forme des formulaires ! Mais finalement, est-ce si impardonnable ?

#xhtmlCSS

Bonne nouvelle pour la promotion de l'information sur les standards du web ! Celle-ci est à découvrir dans le magazine Création Numérique qui, comme son nom l'indique, est un mensuel à destination des graphistes. Dans son édition du mois d'avril, le gourou Jeffrey Zeldman explique sur 4 pages les tenants et les aboutissants de cette nouvelle technologie.

Bien que ne figurant pas sur la couverture du magazine, cet article est sans doute le contenu le plus intéressant de cette édition. L'interview commence par une rapide présentation/historique des standards (x)HTML et CSS, continue sur les avantages induits et termine enfin sur les changements que cette technologie implique.

Bien sûr pour un public averti (comme vous !) pas de réelles nouveautés dans le discours, mais ce n'était pas l'objectif. Faire découvrir une nouvelle façon de faire (puisque le terme "évangéliser" est tellement connoté négativement) à un public pas forcément sensibilisé (le syndrome du graphiste ?), on ne peut que s'en féliciter.

Mais pourquoi avoir choisi Zeldman ? Si son statut de pionnier en matière de pédagogie sur les normes est incontestable, on pourra penser qu'un graphiste plus affirmé tel qu'un Douglas Bowman, un Shaun Inman ou un Jon Hicks aurait pu trouver des arguments plus percutants pour cette cible particulière.

Ne boudons tout de même pas notre plaisir, la mécanique bien huilée de Zeldman fonctionne tout au long de l'article. On comprend bien les enjeux, les avantages, les possibilités offertes par la conception par blocs, mieux, on se demande pourquoi on ne travaille pas comme ça depuis le longtemps !

Pourtant, Zeldman passe sous silence certaines réalités. Sans pour autant les discréditer, il aurait pu en signaler les limites. Pire, comment ne pas lui reprocher de taire (comme le signalait à nouveau récemment Denis) la courbe d'apprentissage (ou plutôt de désapprentissage) que nécessite un processus de passage aux standards.

Passer aux standards ne se fait pas du jour au lendemain, la plupart d'entre nous mettent des mois à la maîtriser. Affirmer le contraire (ce que fait finalement Zeldman par omission) est non seulement faux mais surtout sans doute très dommageable au bout du compte pour les gens qui défendent la conception par blocs.

On aurait d'ailleurs apprécié que l'article outre les traditionnelles références au Zen Garden, à Wired ou à l'Open Championship fasse mention des ressources francophones sur le sujet (Openweb, Pompage, les blogs, etc.). J'attends avec impatience que les graphistes aguichés par cette interview commencent à nous en mettre plein les yeux en XHTML/CSS !

#xhtmlCSS

Article original du 22.03.04 - Les initiateurs du projet se félicitent sur leurs blogs respectifs de l'anniversaire d'OpenWeb. En réaction, les commentaires sont nombreux et enthousiastes, soulignant à juste titre tout l'intérêt de cette initiative. Dommage simplement que cet anniversaire ne soit pas l'occasion, si ce n'est d'une remise en question, du moins d'un bilan en termes d'accomplissement des objectifs de départ.

Clairement, le lancement d'Openweb a marqué une étape décisive dans le mouvement d'évangélisation des standards. A la manière (un peu trop ?) d'Alistapart, on avait enfin un site de référence auquel on pouvait renvoyer les webdesigners en quête d'informations sur le sujet. Rien que pour ça on ne remerciera jamais assez Openweb.

Mais au bout d'un an de vie, on peut raisonnablement commencer à réfléchir sur les évolutions que le projet pourrait prendre. A la lumière des commentaires sur un de mes billets précédents sur l'avenir des weblogs pro-standards et confirmée par l'ébauche d'un projet communautaire chez Tainted Words, cette remise en question est plus que jamais d'actualité.

Pour quelles raisons ?

  • Les sites se multiplient (Openweb, Pompage, les C2 contributions, le wiki Pompeurs, la FAQ incongrue, etc.) diluant l'information pour les personnes désireuses d'en savoir plus sur le sujet.
  • La fréquence des mises à jour est très aléatoire et le fait que la rubrique Actualité d'OpenWeb ne comporte que 10 items en 1 an prouve bien que le site ne bénéficie pas du travail de veille technologique que les blogueurs mènent quotidiennement.
  • La page d'accueil d'OpenWeb propose un patchwork confus d'items dont on ne perçoit pas immédiatement les différences (Actualités, articles, humeurs).
  • La lecture des articles d'Openweb ne répond toujours pas concrètement à la problématique que nous avons tous rencontré lors de nos premiers pas "Comment faire un site sans utiliser de tableaux pour la présentation". Bien sûr, en piochant ici et là on devrait pouvoir arriver à recoller les morceaux, mais il n'y a pas vraiment de tutoriel prenant les débutants par la main à la manière d'un PHPdébutant.

Bien entendu, il s'agit là d'un rapide tour d'horizon que je tente de dresser en me mettant à la place du débutant voulant s'initier aux standards. Je me doute que les initiateurs d'OpenWeb pourront me trouver dur, partial voire même teinté de mauvaise foi (encore que ?), mais au-delà de la volonté de rompre le splendide éparpillement qui donne l'impression de s'installer dans cette communauté, j'ai surtout voulu faire réagir ceux-ci à l'occasion de ce 1er anniversaire dans un seul but : servir au mieux la cause que nous défendons tous...

Mise à jour 26.03.04 - C'est avec un certain étonnement que j'ai découvert le déchaînement de réactions suite à ce log. Si l'aspect critique de celui-ci a pu irriter (au point d'avoir une influence testiculaire sur certains), je m'explique encore mal les invectives que j'ai lu ici et là. Considérer a priori une critique polie et raisonnée comme un troll ou une manoeuvre dont la finalité ultime serait d'augmenter un chiffre dans un tableau statistique s'apparente selon moi à de l'aveuglement ou à de la mauvaise foi. Pour en conclure, étant donné la démesure de la polémique, on peut au moins en conclure que le débat méritait d'être ouvert, dommage que celui-ci ait porté sur la forme plutôt que sur le fond...

#xhtmlCSS

L'utilisation quotidienne de la technologie XHTML/CSS nous confirme chaque jour que malgré tout le bien qu'on en pense, elle n'est pas encore la panacée. Un exemple parmi tant d'autres : comment matérialiser en XHTML le titre d'une liste ?

Le terme de "titre" nous fait instantanément penser aux balises du type <h1> <h2> <h3>. On serait ainsi tenté d'écrire :

<h1>Liste des ingrédients</h1> <ul> <li>Farine</li> <li>Oeuf</li> <li>Lait</li> </ul>

L'idée est bonne, mais hormis le fait que la liste succède le titre, rien n'indique que l'un dépende de l'autre. Il s'agit d'un titre, mais pas expressément le titre de cette liste.

Une autre idée nous est donnée dans le SimpleQuiz #3 : il s'agit de détourner l'utilisation de la liste de définitions (voir leur usage initial chez Pompage). Ainsi la liste serait considérée comme une définition du titre, un peu biscornu, non ?

Si on se retrouve dans une telle impasse sémantique, c'est que les spécifications ont ici une lacune. Personnellement, je vois deux possibilités :

  1. Rajouter un attribut "for" au <h1> (<h1 for="idDeMaListe">) qui permettrait un peu comme pour la balise <label> d'avoir une relation entre les deux éléments,
  2. Ou bien de rajouter une balise <caption> comme celle utilisée pour les tableaux.

Et vous, qu'en pensez-vous ?

#xhtmlCSS

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

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

Un titre en image

# 12-12-2003

Article original du 07.08.03 - Dans la logique de la conception de pages web en xhtml/css, on essaye autant que faire se peut de limiter les images au strict minimum. Cela est particulièrement vrai pour les titres : il est souvent possible de les styler en CSS pour économiser une image. Seulement cette approche a ses limites et il est vrai que graphiquement un titre en image est toujours plus agréable à l'oeil.

Pour concilier les deux approches, j'en suis venu naturellement à chercher une astuce qui s'est avérée par la suite être la même que celle proposée par Douglas Bowman de StopDesign. En gros le titre est placé dans un élément <h1>, le texte à l'intérieur (contenu dans un <span>) est caché en mettant sa propriété display à none et l'image est en fait un background de l'élément <h1>

Mais deux autres designers ont pensé à une autre méthode basée sur la propriété overflow : Seamus P. H. Leahy et Stuart Langridge. David Shea a d'ailleurs réalisé un article intéressant sur le sujet dans Digital Web.

Mise à jour du 12.12.03 - On ne compte plus les articles sur le sujet : une version mise à jour pour supporter IE5 Mac, une version qui marche en désactivant les images de son navigateur, dernièrement une autre et des articles récapitulatifs sur le sujet.

On l'aura compris la solution idéale n'existe pas. En effet, soit les méthodes échouent sur les navigateurs en désactivant les images, soit sur quelques navigateurs spécifiques et dans tous les cas le code à mettre en oeuvre est assez indigeste. J'en viens donc personnellement à la conclusion qu'il y a simplement une amélioration à faire au niveau des recommandations CSS. Admettons par exemple que l'on considère ces images faisant office de titre comme un type particulier d'images d'arrière-plan. Pour coder le titre, on utiliserait simplement sans autre marquage superflu.

<h1>Mon titre</h1>

Du côté des CSS, là encore on jouerait la carte de la simplicité en ajoutant une propriété qui mettrait l'image au premier plan : background-z-index

h1 { background-image:url(monTitreEnImage.gif); background-repeat:no-repeat; background-z-index:1; height:45px; }

Ainsi, pour les navigateurs texte ou pour Google la page afficherait "Mon titre", les navigateurs supportant les images afficheraient "monTitreEnImage.gif" qui cacherait le texte en-dessous permettant ainsi aux personnes ayant désactivé les images de comprendre le titre. Voilà enfin une solution simple, accessible à tous, sans code superflu. Ne reste plus qu'à la proposer au W3C et que les navigateurs l'incorporent vite ! ;-)

#xhtmlCSS

Vite fait bien fait

# 10-12-2003

Maintenant que vous êtes sûr que votre site est complètement valide, il est peut-être temps de remettre le nez dans le code pour l'optimiser un peu. Voici quelques conseils pour faire le ménage de printemps (puisque *hum* c'est la saison) dans votre HTML et votre CSS.

A réserver aux codeurs avertis bien sûr.

Raccourcis déclaratifs

Il existe plusieurs moyens de déclarer une couleur dans un fichier CSS. Prenons par exemple la couleur blanche : white, #ffffff et #fff sont équivalents. La dernière façon de procéder révèle qu'on peut économiser des doublons hexadécimaux en mettant une seule fois la valeur, de même la couleur rouge sang #ff0000 pourra s'écrire #f00.

Les propriétés d'arrière-plan peuvent également bénéficier d'une cure d'amaigrissement :

p {background-image:url(../images/fond.gif); background-color:#ccc; background-position:50% 50%; background-repeat : no-repeat; background-attachment: fixed; }

devient ainsi

p {background: url(images/fond.gif) #ccc 50% no-repeat fixed }

Idem pour les bordures, les marges et le padding :

margin: 8px 2px 1px 4px;

Cette ligne de CSS fixe l'épaisseur des marges dans le sens des aiguilles d'une montre (haut, droite, bas, gauche).

Le regroupement de propriétés

Au fur et à mesure de l'écriture de votre fichier CSS, vous allez rapidement avoir des propriétés en commun. A la fin du projet il est temps d'y rejeter un oeil et d'optimiser le tout. Comment faire ? C'est très simple :

div#menu { margin-left:5px; background-color:#ccc; } div.onglet { background-color:#ccc; } div#menuVertical { background-color:#ccc; padding-right:3em; border-top:1px solid black; }

devient ainsi

div.onglet, div#menu, div#menuVertical { background-color:#ccc; } div#menu { margin-left:5px; } div#menuVertical { padding-right:3em; border-top:1px solid black; }

On déclare les propriétés communes aux différents styles, puis on déclare ce qui les différencie.

Optimisation HTML : les bienfaits du ciblage CSS

Quand on débute en XHTML/CSS, on a tendance à user et abuser des <div> et autres <span> pour pouvoir les styler dans son fichier CSS. Par exemple, on peut écrire pour un en-tête de site :

<div id="enTete"><h1>Mon titre de site</h1></div>

En fait, ici le <div> n'a aucune valeur ajoutée, aucun sens. On peut donc le supprimer sans regret et cibler le texte "Mon titre de site" en stylant le <h1> dans le fichier CSS. L'exemple est trivial, mais cette philosophie d'ensemble s'applique à de nombreux cas.

Pour en savoir plus, consultez les liens suivants :
Introduction to CSS shorthand properties
CSS Shorthands, part I
Writing efficient CSS

#xhtmlCSS

Et si le validateur du W3C faisait du mal à la promotion des standards ? Prenez-le comme une boutade si vous voulez, mais il me semble que cet outil stigmatise toute la rigueur et l'aridité de ceux qui en défendent la cause.

Je m'explique. Le mouvement de promotion des standards s'est accompagné sur de nombreux sites par l'apparition de ce logo Ce logo indique 

que le site est conçu selon les normes du W3C.

La plupart du temps, un clic sur celui-ci amenait à la page du validateur testant la conformité de la page en question, au mieux indiquait-il que la page était valide XHTML 1.0 strict, au pire listait-il une série d'erreurs absconces. Vous admettrez volontiers que cette démarche n'est sans doute pas la meilleure pour expliquer aux non-initiés le principe de la conception par blocs. Ainsi donc le validateur est devenu malgré lui bien plus qu'un simple outil de contrôle-qualité d'une page le parangon opposant les pro et les anti-standards, les uns raillant le côté rustique de l'outil, les autres s'évertuant à afficher le logo sur toutes leurs pages.

C'est oublier que la validation n'est à la limite qu'anecdotique dans la conception par blocs : que l'on oublie d'encoder une esperluette ou un attribut alt de description d'une image n'est pas grave en soi, c'est la démarche conceptuelle qui est importante. Bien plus que de simples conventions d'écriture, cette nouvelle façon de faire met en oeuvre des valeurs essentielles oubliées.

Ainsi on revient sur les excès passés en admettant d'une part que l'intégrité graphique sur tous les navigateurs est une illusion (le fameux web "au pixel près"), d'autre part que c'est de toute façon le contenu qui prime et qui doit être accessible à tous. Ceci n'implique pas une vision castratrice du web où il faudrait chasser toute créativité graphique ou technique (brûler Flash, les systèmes de navigation innovants, les fioritures graphiques, etc.), bien au contraire. L'XHTML/CSS est au contraire un nouveau terrain à explorer pour les webdesigners, car il permet toutes les fantaisies graphiques en offrant à ceux qui ne peuvent pas en profiter une version tout de même accessible. Offrir le contenu à tous et en y mettant la manière pour les navigateurs capables de le recevoir voilà bien ma vision de la conception web moderne.

#xhtmlCSS

La folie des listes

# 05-11-2003

C'est un message sur la mailing-list des pompeurs qui m'a amené à la réflexion suivante : abuse-t-on des listes en XHTML ?

La tendance à la sémantique à tout crin nous a amené à utiliser des balises presque oubliées depuis l'adoption massive des éditeurs WYSIWYG. On a bien compris qu'un paragraphe était contenu dans un <p></p>, que les titres devaient être balisés par des <h1></h1>, etc. Et puis petit à petit, l'utilisation des listes, principalement non-ordonnées (<ul></ul>) est devenu très courant voire trop courant. Partout, dans les textes, les barres de menus, les différents éléments devaient être rangés dans des listes. Ben oui quoi, un menu c'est une liste d'items.

Certes, mais si on continue comme ça toutes nos pages web vont devenir des méga-listes !

Prenons l'exemple d'une liste de liens dans List-a-matic. On voit bien que le code HTML est redondant : chaque item est en fait compris dans une balise <a></a> qui elle-même est cernée par une balise <li></li>. Quel intérêt ? Une suite de liens n'indique-t-elle pas de facto qu'il s'agit d'un menu de navigation ? En plus côté CSS, on est obligé de définir successivement les propriétés de la liste, des éléments de la liste et enfin des liens en eux-mêmes. Ceci n'excluant nullement des bugs d'affichage avec IE. Peu d'intérêt sémantique, code redondant et code plus long, pour le coup voilà une belle liste d'inconvénients.

D'autant qu'avec un minimum d'effort on peut arriver au même résultat en stylant uniquement les <a></a>.

Ce n'est qu'un petit exemple anodin, mais il a pour but de montrer qu'utiliser des listes c'est bien, mais attention à ne pas devenir mono-maniaque !

#xhtmlCSS

Mon engagement pour la promotion des standards m'amène souvent à me poser des questions sur la finalité de celle-ci. Vous l'aurez sans doute compris, je me considère comme un intégriste de la conception par blocs, dans le sens où il me paraît pour le moins aberrant de faire un site en 2003 avec de mauvaises méthodes datant d'il y a 5 ans. Je ne manque donc pas une occasion d'expliquer aux gens comment faire différemment et surtout mieux. Oui, mais jusqu'où ?

Ma conviction pro-standards est particulièrement exacerbée pour les sites faits par des "professionnels de la profession", ce qui m'amène même à être très exigeant sur la qualité des sites en XHTML/CSS, autant que je le suis sur les sites professionnels que je produis moi-même.

Mais quid de l'évangélisation des webmasters amateurs ? Quel intérêt a-t-on réllement à leur répondre, alors qu'ils posent une question sur un décalage de leur mise en page d'un tableau sous IE, qu'il faut tout reprendre à zéro et se mettre à l'XHTML/CSS ?

D'une part, la plupart du temps, on se fera stigmatiser pour notre "intégrisme", d'autant que tôt ou tard le webmaster trouvera la réponse à son problème de code pourri dans Google... D'autre part, est-ce vraiment une mauvaise chose que l'XHTML/CSS reste une affaire d'initiés ? Je vais peut-être paraître hautain, mais cela aurait le mérite de contre-carrer un peu l'idée générale selon laquelle tout le monde est capable de produire un site web de qualité professionnelle avec un peu de Photoshop et une touche de Dreamweaver.

Ma réflexion sur ce point n'est pas encore arrêtée, et vous, qu'en pensez-vous ?

#xhtmlCSS

Bien souvent, en lisant les forums de discussion, on tombe sur des webmasters ravis de montrer que dorénavant leur site "valide". C'est bien, mais bien souvent le travail ne fait que commencer...

Tout d'abord il y a valide et valide. Chaque document HTML doit spécifier dans son en-tête la "langue" qu'il parle (ce sont les DTD) : (x)HTML transitional, (x)HTML strict, (x)HTML avec des frames (frameset), etc. Le validateur du W3C en tient compte et vérifie que le document soumis correspond aux spécifications déclarées dans l'en-tête.

Il faut savoir que le choix de la DTD a une influence sur le degré de "sévérité" du validateur, ainsi, entre les normes transitional et strict, l'utilisation de certaines balises est interdite (le terme consacré est "déprécié") afin que le (x)HTML soit le plus proche possible de l'esprit d'origine de la publication web. Ainsi donc, une personne qui s'enorgueillit de voir son site valider en mode transitional a en fait sans doute encore un peu de pain sur la planche pour arriver à valider en mode strict.

Ensuite, la validation n'est qu'une étape pour s'assurer que l'on a fait un bon site web. Le validateur, c'est un peu le vérificateur d'orthographe de votre site. Si c'est valide, ça veut dire que la syntaxe est bonne, pas grand chose de plus. Le validateur ne vérifie par exemple pas si la mise en page de votre site se fait à base de tableaux plutôt que de blocs, c'est donc à vous de vous en assurer. Mieux vaut donc passer du temps à construire un site sémantiquement correct mais qui échoue au validateur pour un caractère & que vous auriez oublié de transformer en &amp; plutôt que l'inverse.

Ceci étant, je vous engage à faire les deux : un site bien construit et valide !

#xhtmlCSS

Article original 26.09.03 - Evangéliser, c'est diffuser la bonne parole en se mettant à la portée de son auditoire. Souvent, utiliser une parabole pour expliquer les grandes lignes du concept est une technique des plus efficaces. Cela est aussi vrai pour le message des intégristes de la conception par blocs.

J'ai cherché longtemps une parabole satisfaisante. J'ai d'abord pensé à opposer le français argotique au "bon français", mais l'aspect dévalorisant était rhédibitoire.

Parlons musique. Imaginez le web d'il y a quelques années comme de la musique, qu'on jouait plus ou moins en improvisant, à l'oreille, essentiellement pour soi. Quand on rejouait le morceau, il y avait quelques variations, fausses notes dues justement à cette improvisation.

Un jour, quelques personnes se décidèrent à décrire de manière précise les notes, les variations, les rythmes qu'ils consignèrent dans un grand livre appelé "Solfège". Grâce à ces règles, le même morceau peut être lu et joué par tout le monde, en étant fidèle à l'original.

Pour le web c'est un peu pareil. Avant, on faisait un peu n'importe quoi avec du HTML permissif que l'on vérifiant avec le permissif IE. Maintenant tout cela a changé. On code proprement, ça passe avec tous les navigateurs dignes de ce nom et c'est accessible à tous.

Alors on se met tous au solfège ?

Mise à jour 28.10.03 - J'ai trouvé une nouvelle comparaison !

La problématique du vieil HTML avec tableaux par rapport à l'XHTML élégant avec CSS est la même que celle de l'euro. Mais oui, vous savez ces vieux grincheux tout autour de vous qui continuent à vous parler en francs alors que cette monnaie a disparu de la circulation ! En matière de HTML, c'est un peu pareil : on a vécu pendant un certain temps avec une manière de faire (le HTML à tableaux), maintenant il est recommandé de faire différemment (le XHTML/CSS par blocs). Bien sûr que cela demande un certain investissement, bien sûr que cela demande un peu de temps, mais vient un moment où il faut évoluer. Vous imaginez si on parlait encore en anciens francs ? Non ? Bon alors, allez faire un tour sur OpenWeb !

#xhtmlCSS

Ce log est un article en gestation qui a pour but de clarifier un peu les choses entre XHTML, CSS, sémantique, contruction par blocs, bref tout un tas de notions nouvelles pour les concepteurs web qui se cotoient et souvent se mélangent. Bien sûr incomplet pour le moment, il a vocation à être modifié/repris/amélioré et qui sait peut-être publié à terme dans une tribune plus grand public ?

Tous vos commentaires en bas de log sont les bienvenus.

Sommaire

  1. Ma page est-elle sémantique ?
  2. Ma page est-elle valide ?
  3. Ma page est-elle accessible ?
  4. Ma page est-elle "navigo-dégradable" ?

Introduction

La conception de pages web avec XHTML et CSS commence à faire parler d'elle : de plus en plus de (grands) sites adoptent cette nouvelle façon de faire : Macromedia.com, Espn.com, Wired.com, entre autres. Ce changement apporte son lot de nouveaux termes techniques qui peuvent perdre le néophyte : sémantique, validation, doctype, accessibilité, dégradabilité, etc. Il faut bien comprendre que la conception par blocs (par opposition avec la mise en page à base de tableaux) recouvre tous ces aspects de la conception web. Il s'agit de concept tous différents mais connexes : une page web bien faite doit répondre à tous ces critères.

Ce grand questionnaire est destiné à vous donner les clés pour appréhender ces concepts et à chaque page que vous produirez, vous pourrez vous posez chacune des questions suivantes.

Ma page est-elle sémantique ?

Le principe

Derrière le mot un peu abscons "sémantique" se cache une réalité toute simple : quand on fait une page XHTML, il faut utiliser les balises telles qu'elles ont été pensées. Ce n'est rien moins que de la logique pure. Si vous regarder la source de ce document par exemple, vous constaterez que les titres sont balisés avec des <h1>, <h2>, <h3>, que les paragraphes sont bien dans des balises <p> (et non pas séparés par des <br><br> intempestifs), que les listes d'éléments ordonnés utilisent des <ol><li></li></ol>, etc. Il faut donc utiliser des balises qui ont du sens.

Les implications

Cette façon de faire découle du fait qu'il faut séparer la structure du document de sa présentation : le fichier HTML constitue un squelette que l'on habille à sa guise avec un fichier CSS. C'est pourquoi l'utilisation de balises de présentation comme <b>, <i>, <u> ou autres sont totalement à proscrire : les indications de mise en forme, de positionnement des éléments sont à décrire dans le fichier CSS.

Le fait de créer une page sémantique impose d'abandonner la mise en page en tableaux, mais pas d'en proscrire absolument l'utilisation. On comprend bien qu'une page conçue avec des multiples tableaux imbriqués avec des colspan, rowspan n'est pas la bonne méthode pour structurer son document. En revanche, quelle meilleure façon de décrire un tableau de chiffres qu'avec une balise <table> ?

D'ailleurs l'abandon de la mise en page à base de tableaux pour passer à la conception par blocs réduit considérablement le poids des pages HTML (c'est le "Codons moins, codons mieux" de Denis). En éliminant les attributs de présentation du fichier HTML et en les regroupant dans une CSS, on peut gagner jusqu'à 50% sur le poids du fichier.

L'utilisation sémantique des balises favorise aussi le bon référencement auprès des moteurs de recherche. Pas très étonnant, car ceux-ci recherchent uniquement les informations textuelles du document et apprécient de voir l'information hiérarchisée avec des niveaux de titres <h1>, <h2>, <h3>.

Les outils pour tester

Il n'existe pas à proprement parler d'outil automatisé pour tester la sémantique d'un document, seul un peu d'expérience et de logique permettent de déceler les erreurs dans un document HTML.

Ma page est-elle valide ?

Le principe

Ma page est-elle accessible ?

Le principe

Ma page est-elle "navigo-dégradable" ?

Le principe

#xhtmlCSS

Article original du 15.08.03 - Comme annoncé précédemment, regonflé à bloc après une petite douche écossaise, je me suis remonté les manches et ai concocté rapidement ma proposition pour le CSS Zen Garden.

Vous pourrez la retrouver sur http://www.fastclemmy.com/tests/cssZenGarden/ et vous y retrouverez évidemment... un scrolling horizontal qui ravira mes détracteurs :o)

Bien entendu tous vos commentaires sont les bienvenus, sachant que la CSS n'est pas très optimisée et qu'une barre de défilement verticale est apparue mystérieusement à un moment mais que je vais m'employer à trouver pourquoi et à la faire disparaître.

En attendant, il est temps pour moi de prendre quelques jours de vacances. A la semaine prochaine !

Mise à jour du 10.10.03 - J'ai enfin repris et corrigé mon design pour le CSS Zen Garden. Maintenant que les commentaires sont activés, vous allez pouvoir me donner votre avis ! Je n'ai pas encore soumis ma proposition officiellement donc si il y a des critiques à faire, c'est le moment !

A voir en version anglaise ou française !

#xhtmlCSS

Si vous utilisez Internet Explorer, vous ne pourrez pas tester ce nouvel outil, profitez-en pour adopter Mozilla ou Firebird. Parés ?

Grâce à Mozile, vous pouvez éditer directement dans le navigateur votre page en XHTML/CSS ! Vous ne voyez pas l'utilité ? Imaginez que vous créez un site pour un client avec une jolie structure XHTML/CSS comme il se doit. Bien entendu, le client est un néophyte et il est hors de question qu'il modifie directement le code lui-même. C'est ici qu'intervient Mozile.

En l'implémentant dans le site que vous aurez conçu, le client pourra simplement cliquer dans la page et modifier le contenu grâce à une barre d'outils semblable à celle de Word. Une sacrée bonne alternative gratuite à des produits comme Contribute par exemple.

Oui mais... tout le monde va pouvoir éditer mon site me direz-vous ? Pour pallier à ce problème, il vous suffit de mettre en place un simple système d'identification qui affichera ou non Mozile sur les pages du site en question.

A noter que Mozile fonctionne aussi en partie sur IE, mais produira du code invalide, retirant un grand intérêt au produit.

Le système reste sans doute à parfaire mais c'est sans doute un pas en avant dans la bonne direction. Et tant mieux si de nouveaux utilisateurs adoptent Firebird dans la foulée !

#xhtmlCSS

Depuis quelques temps c'est la mode des générateurs automatiques de bidules en XHTML/CSS pour rendre la vie facile aux débutants. Après les listes, les listes imbriquées c'est carrément un modèle de site entier qu'on peut réaliser parfois en remplissant quelques champs. Pour ma part ce genre d'outils me laissent assez circonspect.

Tout d'abord, même si je ne perds pas de vue que ces initiatives sont à destination d'un public qui découvre la conception par blocs, force est de constater que des générateurs de gabarits mènent nécessairement à l'uniformisation des sites web. Chose qui personnellement me hérisse en tant que défenseur de l'innovation "XHTML-CSSesque". La perspective de revoir partout les mêmes sites avec les mêmes mises en page, les mêmes boutons, les mêmes titrages, ne m'enchante guère.

De plus on remarquera que lesdits générateurs perpétuent toujours et encore des modèles de page hérités de l'ère de la construction à base de tableaux avec ces désespérantes lignes droites et ces colonnes à n'en plus finir.

Mais soyons optimistes et disons-nous que grâce à ces outils de nouvelles personnes faisant des sites web se plongeront dans le code et découvrirons que passer aux standards c'est dur, mais ça vaut le coup.

Deuxième chose qui m'interroge, c'est la visibilité de ces outils. Pour l'instant il s'agit d'initiatives personnelles isolées (qui au passage repompent surtout le code grâcieusement offert par d'autres) cachées au fin fond de sites épars. La probabilité que le débutant moyen en HTML tombe dessus est quasi-nulle. Il faudrait plutôt concentrer les efforts de lobbying pour intégrer ces générateurs sur les portails des hébergeurs expliquant comment on fait des sites web ou, mieux, sur les sites de "référence" du HTML d'antan (qui a dit AllHTML ?). Ce n'est qu'à ce prix que du code valide pourra être à la portée des nouveaux venus dans le monde du web.

Enfin, dernier point qui me chagrine, c'est que les générateurs en question tournent pour l'instant en peu autour de leur nombril. C'est sympa de me faire ma page à ma place en me rassurant sur le fait que je sois "peu inspiré" plutôt que "feignasse", mais ça serait bien par la suite de m'expliquer un peu l'envers du décor, de comprendre comment ça marche, comment je pourrais l'améliorer moi-même, pour un jour ne plus être dépendant et faire les choses tout seul.

C'est un peu apprendre à pêcher du poisson au lieu de pêcher du poisson automatiquement.

#xhtmlCSS

Un post a mis le feu aux poudres dans la blogosphère anglophone : refaire à l'identique en XHTML/CSS des sites existants en tableaux serait contre-productif (exemples , , et ).

Pourtant l'exercice de style qu'est le redesign de sites en XHTML/CSS fait partie des moyens d'évangéliser les concepteurs web. Il permet en effet de montrer que l'on peut faire la même chose qu'avant mais avec tous les avantages de la conception par blocs notamment en termes de légèreté et de simplicité du code. Et quoiqu'en dise le bloggeur de ParanoidFish, je ne pense pas que la finalité de ce genre de démarche soit que le designer CSS puisse rouler des mécaniques par la suite. Il s'agit au contraire de promouvoir la conception web conforme aux standards, l'intérêt général plutôt que l'intérêt particulier.

En fait, le bloggeur n'effleure à mon avis le point intéressant qu'à la toute fin de son article. Quel intérêt a ce genre de démonstration pour un développeur web ? Pourquoi devrait-il investir du temps à apprendre l'XHTML/CSS si c'est pour arriver au même résultat qu'avec des tableaux ?

Si je trouve la nouvelle mouture de Cybercodeur jolie graphiquement, je trouve, au contraire de Greut, qu'il est dommage qu'il ressemble à un site fait avec des tableaux.

Innovons !

L'évangélisation passe à mon avis plutôt par les initiatives comme CSS/Edge, CssZenGarden ou d'autres expérimentations. Il faut montrer ce que les standards peuvent apporter de neuf dans la conception web, en mettre plein la vue pour convaincre. Si ce genre de démarche est parfois dure à mettre en oeuvre dans nos projets professionnels pour le moment, il ne faut pas hésiter à faire des expérimentations sur nos sites personnels pour montrer que la communauté bouge, créé, innove !

Le seul frein que nous pourrions rencontrer serait un navigateur-passoire dépassé et buggé, mais heureusement la solution existe.

#xhtmlCSS

Miracle !

# 27-09-2003

J'ai converti mon DSI à l'XHTML/CSS, incroyable non ?

#xhtmlCSS

Article original 24.09.03 - Une question reçue par mail, me permet de faire mon log du jour facilement. La question était de savoir comment réaliser un site comme celui-ci ou comme ma participation au CSSZenGarden avec un défilement horizontal, sans tableau et en XHTML strict.

En fait par défaut, le comportement des navigateurs est de caser les infos dans l'espace visible du navigateur, donc d'éviter de préférence les scrollbars, surtout horizontales !

C'est pourquoi, si on met des <div> avec la même propriété float:left; les premiers se mettront bien les uns à la suite des autres de gauche à droite. Par contre dès qu'un <div> flottant atteindra la limite visible de l'écran, il se placera en-dessous des autres pour éviter justement une scrollbar horizontale.

Il faut donc contraindre d'une manière ou d'une autre le navigateur à le faire, donc à passer par du positionnement absolu (stratégie identique pour les soumissions horizontales du cssZenGarden).

Sur fastclemmy.com, chaque <div> correspondant à un log a un attribut id spécifique ainsi qu'un attribut class qui régit les règles communes à tous les éléments de ce type. Evidemment, la position en x ne peut pas être définie dans la feuille de style étant donné que je créé les blocs dynamiquement à partir de la base de données. J'utilise donc la balise <style> dans le corps de ma page HTML pour fixer la propriété left de chaque bloc. En PHP, dans la boucle d'affichage de mes blocs, j'incrémente simplement un compteur de la largeur d'un bloc + de la distance voulue entre chaque bloc.

Et le tour est joué (et valide !).

Bien sûr, on pourra regretter ce petit écart "philosophique" qui consiste à insérer des informations de présentation (<style="left:1650px;">) dans le fichier HTML, mais c'est le seul moyen que j'ai trouvé pour réussir un design horizontal dynamique.

Mise à jour 25.09.03 - Suite à ce log, vos commentaires par mail ont fait avancé le problème. Tout d'abord, un collègue bloggeur m'a suggéré, étant donné que je ne publie qu'un log par jour, de préremplir ma feuille de style avec les valeurs

#logID1 {position:absolute; width:415px; left:300px;} #logID2 {position:absolute; width:415px; left:750px;} et ce jusqu'à #log31 (dans l'hypothèse où j'écrive 31 logs par mois)

Effectivement ça résoudrait mon problème de séparation contenu dans HTML/présentation dans CSS.

Mais étant donné que ce site est dynamique, une autre idée m'a été envoyée par mail encore meilleure. Tant qu'à générer des informations de présentation dynamiquement, pourquoi ne pas le faire directement dans la CSS plutôt que dans le HTML ?

Pour cela deux méthodes : soit renommer tout simplement ton fichier weblog.css en weblog.php et hop le tour est joué ou alors dire à Apache d'interpréter les .css comme des scripts.

Youpi, un item de plus sur ma ToDo List !

#xhtmlCSS

Suite au défi posté sur le forum hardware.fr, j'ai entrepris de réaliser une page ayant les contraintes suivantes. Un bandeau en haut et un autre en bas de taille fixe, visible tout le temps. Au milieu, une zone de contenu scrollable, un peu à la manière de ce qui peut se faire avec des frames.

Mon premier essai, propre et fonctionnant sous Firebird 0.6.1 et Opera.

Mon second essai, fonctionnant sous IE6 (en rusant avec un peu de JS dans la CSS + un hack pour n'afficher une autre feuille de style à tout le monde sauf à lui), Firebird 0.6.1 et Opera.

Testez en réduisant la taille de la fenêtre. N'hésitez pas à commenter et à me faire remonter vos avis.

#xhtmlCSS

Avec tout l'optimisme qui le caractérise, Tristan se fait un joie de voir passer le site News.com aux standards : en effet, un rapide coup d'oeil dans le source de la page et on voit des <div> et des <hx> qui structurent le document. Très bien, mais...

... mais moi je suis un intégriste, alors quand je découvre avec horreur que la page d'accueil comporte plus de 1000 erreurs ça me désespère. Surtout que c'est visiblement des petits détails et notamment beaucoup d'esperluettes non converties...

Quelle crédibilité donner à l'évangélisation pour les standards lorsque les sites qui pourraient servir de porte-drapeau de la cause échouent bêtement au test de la validation ? Qu'un site fait avec Dreamweaver par un graphiste dans sa web agency ne valide pas parce qu'il ne sait même pas de quoi il s'agit, c'est normal, chacun son job. Mais que ceux qui prennent le temps de faire un site conforme aillent jusqu'au bout, validation incluse ! Car il faut bien avouer que la majorité des sites professionnels en XHTML/CSS ont encore quelques petits soucis de ce côté...

Et ceci est d'autant plus critique que le test du validateur du W3C n'est que la toute première étape pour s'assurer que son site est bien fait : il ne s'agit de savoir que si le site est écrit en bon (x)HTML. La sémantique (c'est-à-dire la logique de construction du document) ne peut malheureusement par être vérifiée finement autrement que par un oeil humain averti...

#xhtmlCSS

Non, pas de conseil beauté sur fastclemmy.com, juste un petit post pour insister sur un des avantages de la conception par blocs qui sépare le contenu du contenant. Cible du jour : Les joyeux drilles.

La version actuellement en ligne date d'il y a plus de trois ans, ce qui explique sans doute la mise en page en tableaux, les pixels transparents et autres astuces du temps de la "vieille école". La nouvelle version a été pour moi l'occasion de tout remettre à plat et de corriger ces défauts de jeunesse en reprenant tout le squelette de la page en XHTML sémantique et valide (car on peut faire du valide non sémantique !).

Mais le résultat graphique final ne m'a pas emballé. Qu'à cela ne tienne, je reprend de zéro une maquette dans Photoshop pour un enième lifting du site, une fois mes images découpées, pas besoin de toucher à la structure du site (le fichier XHTML), j'aurais juste à refaire la CSS.

Conclusion : avec XHTML le lifting de site coûte 50% moins cher, c'est votre patron(ne) qui va être content !

#xhtmlCSS

Passage de témoin

# 11-09-2003

Je me remémorais dernièrement quel chemin avait bien pu me mener jusqu'à l'intégrisme de la conception en blocs. Et vous, comment êtes-vous tombé dedans ?

La première fois que j'ai entendu parlé d'XHTML, c'était par un prof qui nous expliquait sans plus de détail que c'était la norme d'avenir qu'il fallait fermer toutes les balises et les écrire en minuscules. Mais que de toute façon, des logiciels feraient sans doute eux-mêmes les corrections, sans plus de précisions, peut-être parlait-il de Tidy. Dommage que lors du cours dit de "HTML" on ne nous en est pas parlé et surtout que l'on ne nous ai pas appris à faire du (x)HTML valide... J'étais donc passé à côté.

La lumière est venue, à force de lire des forcenés du code propre rabâcher sur le forum programmation de hardware.fr que coder autrement que selon les standards, c'est mal. En lisant de près la FAQ du forum à ce sujet, j'en suis venu à lire religieusement toutes les sources dans le domaine -tant en français qu'en anglais-, à m'exercer, me planter, recommencer et enfin toucher au but.

Avec le recul, je m'aperçois qu'en fait, cette bonne façon de faire m'était très familière, car c'est ce que ne cessait de répéter mon père, expert SGML (le grand-père d'HTML) de son état, qui pestait et raturait les bouquins d'HTML 4 qui prônait l'utilisation des balises de présentation <b> et autres horreurs. Du (vieux) puriste au (tout) jeune intégriste, la boucle était ainsi bouclée.

#xhtmlCSS

Peu de temps, peu d'inspiration pour le log du jour. Alors je cède à la facilité en pointant vers un autre site plutôt que de produire du contenu moi-même. Il s'agit en l'occurrence des SimpleQuiz de SimpleBits : des questions pas bien méchantes sur la sémantique (x)HTML dont les commentaires sont souvent très instructifs. Bien sûr, si vous lisez les sites de mon blogroll tous les jours cette info ne vous aura pas échappé, mais sait-on jamais...

#xhtmlCSS

L'effet de loupe

# 09-09-2003

Article original 01.08.03 - Un phénomène qui m'amuse toujours autant c'est l'effet de loupe. Derrière cette jolie formule se cache une réalité bien connue : quand on commence à s'intéresser à un sujet, les occurrences de celui-ci dans la vie quotidienne nous apparaissent chaque jour plus nombreuses. Ainsi si vous envisagez d'acheter un modèle particulier de voiture, vous avez toutes les chances d'en remarquer beaucoup plus circulant dans les rues.

Le rapport avec l'XHTML+CSS ? Et bien à force de lire Openweb, Standblog, la liste des pompeurs, on pourrait croire à un formidable bouillonnement du web qui se convertirait massivement aux standards. Je n'en crois rien. Les 27.000.000 de téléchargements de Netscape 7 (utilisant le même moteur que Mozilla) régulièrement cités par Tristan restent dramatiquement marginaux par rapport à l'hégémonique IE, le concept de web sémantique n'est pas encore arrivé jusqu'aux oreilles des concepteurs web dans les web agencies et encore moins dans les commanditaires de sites. Bref le bouillonnement qu'on peut sentir en étant au coeur de la communauté des développeurs acquis aux standards pourrait ressembler vu d'avion aux bulles dégagées par le diffuseur d'air de mon aquarium.

Faut-il se désespérer pour autant ? Peut-être pas. Mais l'âge de la maturité doit encore venir dans tous les domaines : la formation des futurs développeurs d'abord, l'amélioration des browsers web (celui commençant par un I et finissant par un E serait la bienvenue) et l'information de l'utilisateur final.

Mise à jour 09.09.03 - Oui, le travail d'évangélisation des intégristes de la conception par blocs est toujours d'actualité. Pour preuve, les 10 premiers nouveaux sites annoncés sur le Journal du Net (on peut donc imaginer que c'est un reflet correct de la production web française actuelle) ne valident pas. Pire, la totalité utilise des techniques de mise en page en tableaux, des frames, des intros en Flash inutiles et inaccessibles qui prouvent qu'il n'y a même pas le début d'un commencement de prise de conscience chez les webdesigners. Espérons que le nouveau Dreamweaver de Macromedia y changera quelque chose, mais je n'en suis même pas sûr...

#xhtmlCSS

Les bons termes

# 03-09-2003

En écrivant ces quelques petits paragraphes, je me suis rendu compte au fur et à mesure que j'avais du mal à définir correctement cette nouvelle forme de conception web qu'est celle utilisant XHTML et CSS. Je n'arrivais pas à trouver les bons termes.

Mise en page XHTML+CSS ? Trop abscons. Mise en page avec calques ? Trop de mauvais souvenirs avec Dreamweaver 3 et ses calques invariablement positionnés en absolu. Conception web conforme aux standards ? Trop répressif. Il me fallait autre chose pour qualifier cette nouvelle façon de faire par opposition à la mise en page avec tableaux.

C'est décidé, je parlerai dorénavant de mise en page par blocs.

Ce n'est qu'une formule, mais je trouve qu'elle a l'avantage d'être assez parlante (on réfléchit en termes de blocs : en-tête, menu, contenu, etc. plutôt qu'en tableaux avec des colonnes et des cellules) et assez proche du concept qu'on veut exprimer. Vous ne trouvez pas ?

#xhtmlCSS

Grande nouvelle dans le petit univers de la conception XHTML+CSS : le site macromedia.com vient de passer à la mise en page sans tableaux, une vraie révolution. Et ceci concomitamment au lancement de sa nouvelle ligne de produits parmi lesquels Dreamweaver MX 2004 qui met l'accent sur les CSS.

Pourquoi est-ce une grande nouvelle ? Tout simplement parce qu'en tant que logiciel leader chez les designers web, ce mouvement vers un codage HTML conforme aux standards est un grand pas en avant pour son adoption par une majorité de développeurs web.

Sam en deviendrait presque lyrique. Pourtant, je serais encore plus circonspect que les quelques réserves qu'il émet. En effet, je ne suis pas sûr (mais je ne demande qu'à me tromper) que cette nouvelle mouture empêche les gens de faire des sites affreux avec des mises en page en tableaux avec des tonnes de code superflu, car comme le souligne Kottke, il est possible de faire un site à base de tableaux et qu'il soit valide.

La mise en page en XHTML+CSS nécessite un changement d'habitudes radical par rapport à l'utilisation des tableaux, il faut penser de bout en bout, de la maquette à l'intégration finale à la structure, la sémantique et à l'habillage de sa page. Ce travail de réapprentissage de la conception web demande un certain investissement, et AMHA la population utilisant Dreamweaver me semble peu encline à s'y conformer et ce n'est pas le logiciel qui pourra l'y forcer.

Reste, comme le pointait Sam dans son article, que Macromedia.com va sans doute devenir l'un des sites-références que l'on pourra citer en exemple en matière de conception web sans tableaux en vue de faire abandonner aux gens Dreamweaver pour un meilleur outil !

L'avis de Stayleez

Concernant les "table codeurs" je pense que le Dreamweaver nouveau pourrait en convertir certains si bien sûr tout ce qui est annoncé est respecté et surtout si les modéles fournis abandonnent les tableaux pour la mise en page.

En ce qui concerne le sémantiquement correct ça viendra après. Il faut montrer d'abord la simplicité des mises en pages avec CSS ensuite viendra l'amélioration de tout ça.

Petit à petit ça viendra.

Le plus gros problème, à part les irréductibles, restera tout ceux qui n'y connaissent rien et à qui certains logiciels promettent un site web "minute-maid".

Tout ça pour dire laisse une chance à Dreamweaver quand même ;-) (en référence à la dernière phrase de ton post). Time will tell !

#xhtmlCSS

Mise à jour 25.08.03 - Bientôt le week-end, l'occasion de lire l'excellente interview (du moins les excellentes réponses) de David Shea, le créateur du site de démonstration CSSZenGarden.

Je vous laisse le lire, j'éditerai ce log lundi pour vous faire part plus avant de mes impressions à ce sujet.

Je suis donc tout à fait d'accord avec le fond du discours de David Shea. Le fait que la conception de sites en XHTML+CSS soit pour le moment réservé à quelques happy few geeks tient simplement au fait que les outils WYSIWYG sont conçus pour faire des sites avec des tableaux. Mais plus que ça, je me demande toujours si on pourra un jour coder proprement (avec <style>) autrement que directement à la main dans un éditeur de texte. Il me paraît en effet assez compliqué pour le logiciel d'aider l'utilisateur à faire son site sans qu'il en comprenne la sémantique. Je m'explique.

Quand on crée une page HTML, il faut d'abord structurer son document en délimitant les différents blocs (par exemple : un logo/un en-tête, un menu, une zone de contenu, un pavé d'information additionnelle). Ce n'est que dans un second temps que l'on s'occupe de l'arranger visuellement en rajoutant des images et de styler les textes avec les CSS.

La partie de structuration de l'information est difficilement réalisable par un logiciel, la bonne approche serait sans doute d'utiliser une sorte d'assistant qui demanderait à l'internaute de remplir les différentes zones : logo, menu, contenu, etc. Malheureusement la variété des mises en page possibles imaginées par les webdesigners font qu'AMHA il n'est possible de coder proprement qu'à la main.

#xhtmlCSS

Tutoriels XHTML+CSS

# 13-08-2003

Sibelius, actif membre du forum Programmation de hardware.fr, propose sur son site de très bons tutoriels sur les fondamentaux de la mise en page utilisant les techniques de l'XHTML et des CSS.

Une très bonne initiative qui vient compléter ceux déjà réalisés sur la référence en la matière : OpenWeb.

#xhtmlCSS

Une discussion intéressante sur le forum Programmation de hardware.fr détaille les avantages et les inconvénients de passer aux standards. Au final on s'aperçoit que la liste des bénéfices est longue et que les seuls arguments anti-standards relèvent surtout, au choix, de la fainéantise, du manque de temps ou de l'ego du développeur web.

#xhtmlCSS

Optimisé pour PDA

# 31-07-2003

Au risque de passer une nouvelle fois pour un trolleur [Définition], je vais expliquer mon point de vue sur la lisibilité d'un site web sur autre chose qu'un ordinateur de bureau.

En effet, parmi les arguments louables censés nous convertir tous aux standards du web, je mets en doute sérieusement celui qui consiste à dire : "un site bien conçu selon les standards du web sera consultable sur n'importe quelle plateforme : PDA, téléphone mobile, etc.".

Certes, un document HTML correctement construit aura toutes les chances d'être lisible sur ces supports, car même si le support des CSS sur les navigateurs est encore limité voire inexistant, on peut espérer que l'utilisateur pourra lire le site en mode texte. Le problème n'est donc même pas le rendu graphique : vu le temps que les navigateurs pour ordinateurs de bureau ont mis pour intégrer (presque) correctement le support des CSS, ceux pour PDA ont encore beaucoup de chemin à parcourir ! A quoi bon se démener à faire un design liquid si de toute façon le navigateur affichera au final le fichier en format brut ou presque ? Autant faire un site beau, optimisé pour une lecture sur un ordinateur de bureau. Il sera toujours temps, lorsque les CSS seront correctement supportées sur un PDA de faire une feuille de style spécifique pour ces petits écrans.

Mais outre l'aspect graphique, ce qui me chiffonne le plus dans le concept du site web sur PDA est que le concept-même me paraît aberrant. Il est inconcevable pour moi qu'un utilisateur recherche le même type d'informations quand il surfe sur son PC que quand il surfe avec son PDA : mode de consultation différent = contenu adapté. Prenons un site de restaurant par exemple : sur son PC, l'internaute pourra être intéressé de lire l'historique de l'enseigne, les coulisses de la cuisine, des recettes à faire chez lui; sur son Palm, sans doute en déplacement, l'utilisateur voudra plutôt accéder directement à l'information essentielle : les jours d'ouverture, le contenu de la carte, les prix, les coordonnées.

C'est en ce sens que je vois l'intérêt des CSS spécifiques pour les PDA : ne montrer que le contenu indispensable et accessible d'un coup d'oeil. Reste maintenant à attendre que les navigateurs pour PDA adoptent les CSS...

#xhtmlCSS

C'est décidé, un de ces jours (reste à déterminer lequel), je vais me mettre au jardinage.

#xhtmlCSS