css 4 design » XHTML

Quelques notes — Programme de formation HTML & CSS

Bruno Bichet — Wed, 04 Jan 2012 12:01:47 +0000

Les langages du web HTML et CSS sont généralement structurés autour de concepts qui ont peu à voir avec la manière dont ils seront utilisés. Ce qui est normal après tout : les concepteurs ne sont généralement pas les auteurs. Il appartient à ces derniers de tâtonner un peu, beaucoup ou passionnément et d’en parler avec leurs voisins pour connaitre les bonnes pratiques du jour. Pour dire les choses autrement, les langages du web ne sont pas livrés avec «le» mode d’emploi. La plupart des tutoriels que l’on trouve sur le web reprennent généralement le découpage que l’on trouve dans les spécifications du W3C.

Si les spécifications sont très utiles pour comprendre la nature des ingrédients (balises HTML et propriétés CSS), elles ne nous disent pas grand chose sur la manière de les mettre en oeuvre pour réaliser un site web. S’il n’existe pas de recette toute faite, c’est certainement à cause des plats (les contenus) qui sont uniques.

Enfin, en même temps, on ne peut pas ne pas constater que les sites Web sont à 90% composés de :

En-tête pour : logo, baseline, visuel, un ou plusieurs menus de navigation,
Zone de contenu principale : texte, image, vidéo,
Une, deux ou trois barre latérales (Sidebar) à droite, à gauche de la zone de contenu,
Pied de page (Footer).

Depuis quelques temps, je réfléchis à la mise en place d’un plan de cours pour l’apprentissage du couple HTML & CSS. Dans l’idéal, cette formation devrait être :

Assimilable rapidement par les débutants qui n’ont jamais vu une balise HTML ou une règle CSS,
Convainquante pour inciter les créatifs à se pencher sur les notions d’intégration web,
Intéressante pour ceux qui utilisent ces langages dans leur vie professionnelle ou en amateur (dans le noble sens du terme).

La plupart des plans de cours sur le sujet séparent souvent l’étude du HTML des CSS. J’aimerais mettre en place une méthode globale s’inspirant (très librement) de la Programmation Orientée Objet (POO), en initialisant un super objet — le site web — englobant d’autres objets comme le header, la sidebar, les menus et les différentes zones de contenu que l’on trouve généralement dans un site internet ou sur un blog (titres, sous-titres, paragraphes, liste, etc.). A cet égard, HTML 5 permet d’aller dans ce sens avec les balises header, nav, article, aside, footer.

CSS et HTML sont dans un bateau…

Sans le HTML, les CSS ne servent à rien. Dans la pratique, on rencontre rarement HTML sans CSS. Au lieu d’aborder les deux langages de manière séquentielle, j’envisage de démarrer par la mise en place d’un vocabulaire de base qui fournirait les briques élémentaires nécessaires à la construction d’un site web. Cela pourrait s’effectuer en abordant les deux langages simultanément tout en ajoutant les notions d’ergonomie et d’accessibilité : les bonnes manières s’apprennent dès le début.

Ces briques seraient composées de bouts de code, de module, de composés HTML & CSS «prêts à l’emploi» à expliquer aux apprenants par le biais d’exercices pratiques qui débuteraient le plus tôt possible dans la formation. L’apprenant serait ensuite invité à assembler ces briques pour construire une page web. Le formateur fournissant à cette occasion les indispensables conseils, trucs et astuces concernant l’apparence sur les différents navigateurs, l’utilisation des commentaires conditionnels, etc., selon le temps disponible.

Parmi les méthodes proposées dans les commentaires du billet d’Aymeric, nombreuses sont celles qui préconisent de partir du contenu pour commencer l’apprentissage de HTML. Je suis généralement le premier à prendre mon Stabilo ® pour baliser le contenu avant même de prendre une tablette graphique ou mon Notepad++. Toutefois, intégrer le balisage du contenu dans la formation peut s’avérer chronophage et ne pas trouver sa place dans le temps généralement impartie dans les centres de formation où un module de base dure rarement plus d’une semaine.

En outre, indépendamment du contenu, l’immense majorité des sites web partage les mêmes caractéristiques. On pourrait passer beaucoup de temps à lister tous les éléments constituant un site et faire des statistiques pour savoir si tel ou tel élément se retrouve le plus souvent dans le header, la sidebar ou le footer, etc. mais force est de constater qu’à ce niveau, un consensus se dégage : le logo, la baseline et le menu principal se retrouvent dans haut de la page tandis que les informations de contact et de copyright se situent plutôt en bas de la page !

On pourrait donc, dans le cadre d’une formation sur cinq jours, fixer les idées autour des zones que l’on rencontre généralement sur les sites web ou les blogs :

un header (pour le logo, la baseline, la navigation principale et les liens d’évitement),
une zone de contenu…
… associée à une ou plusieurs barres latérales,
avec un footer (contact, crédits, copyright) pour finir.

Ce découpage mélange joyeusement l’analyse fonctionnelle et la présentation, mais présente l’avantage de fixer les idées sur des choses auxquelles les apprenants ont été confrontés, ce qui a son importance.

Pour aborder l’apprentissage des balises et la sémantique qui leur est associée, je propose de partir du logo qui peut être le premier niveau de la page d’accueil (ce n’est pas gravé dans le marbre, cf. 8 composés HTML pour le logo et la « baseline » et leur potentiel SEO). On pourra lui réserver la balise h1 avec un background pour l’image. On pourra masquer le texte d’une manière ou d’une autre.

Partant du principe qu’une zone de menu sera souvent composée avec une liste de liens, il me semble utile de proposer dès le début les méthodes généralement utilisées pour faire flotter les li, transformer les a en bloc, utiliser les images de fonds, etc.

Une zone de contenu secondaire est souvent représentée par une barre latérale placée à droite ou à gauche de la zone de contenu. Pourquoi ne pas introduire directement les notions de positionnement avec float et les positions relative et absolute ? Pour un débutant, ces notions ne sont pas plus difficiles à comprendre que le reste. Je me dis qu’elle seront peut-être même plus rapidement assimilées en les abordant dès le début, même si les notions de contexte de formatage ou de clearing ne sont pas très évidentes au premier abord.

Je reviendrais sur le sujet un peu plus tard selon vos retours. L’objectif est de remplir un programme de formation détaillé sur 5 jours permettant à des personnes ayant des pré-requis réduit au minimum de pouvoir créer une page web «classique».

Pour ne pas conclure

Ce billet est une ébauche que je compléterais au fur et à mesure de mes idées et de vos suggestions. Ce billet traine dans mes brouillons depuis que Aymeric a eu dès 2007 l’excellente idée de synthétiser les commentaires qui avaient suivis son billet sur le plan de formation idéal pour l’apprentissage du XHTML et des CSS que je vous invite à lire sans plus attendre.

Linkographie

Articles sur le même sujet

Quelques notes, beaucoup de liens (et un peu de mauvaise foi) sur HTML5

Bruno Bichet — Tue, 07 Jul 2009 02:02:28 +0000

Comme ça va finir par se savoir un jour, autant que se soit moi qui vous l’apprenne : HTML 5.0, c’est pas pour aujourd’hui ni pour demain. A force de claironner à qui veut l’entendre que le groupe de travail sur HTML5 paufine sa copie et que Firefox 3.5 (comme Safari, etc.) prend en charge une partie des spécifications du successeur de HTML 4.0.1 et de XHTML 1.0, les oracles zélés de la modernité sémantique oublient que la feuille de route vers HTML 5 courre jusqu’en 2022… Oui, vous avez bien lu, HTML 5 ne sera pas prêt avant 2022 !

Putain, 13 ans…

Je vous vois venir : quoi, 2022 ! Oui, plus que 13 ans à attendre. En attendant, j’ai voulu fait un petit tour de web pour voir ce que HTML5 nous prépare. Ce billet est donc vaguement exploratoire et les quelques allégations sur la supériorité de XHTML sur HTML que le lecteur pourrait déceler ça et là ne sont que le fruit d’une déception légitime car je trouve que XHTML remplit parfaitement son office.

MàJ du 08/07/2009 : D’après le commentaire de Florent V. nous devrions pouvoir commencer à utiliser HTML5 comme on utilise aujourd’hui CSS 2.1 en 2012, et non pas en 2022.

XHTML2 ferme les portes au profit de HTML5

Cela dit, la nouvelle vient de tomber dans mon aggrégateur : les membres du XHTML2 vont grossir les rangs du groupe de travail sur HTML5. Peut-être que la dead line sera-t-elle raccourcie. Ou pas, car c’est bien connu, au bout d’un moment, plus on met de ressources humaines sur un projet et moins le projet avance…

Enfin, je suis content de savoir que d’après Ian Jacobs le marché disponible pour XHTML 2 était trop faible comparé à celui de HTML 5. Comme si l’intégrateur de sites de cul (qui représentent en volume la majeure partie du web avec les intranets visibles uniquement avec IE6) attendait avec impatience des balises plus sémantiques, m’enfin… A cet égard, je comprends mieux maintenant la possible introduction d’une balise dans HTML5 ^^

Pour les curieux, voici les réponses à toutes les questions auxquelles vous n’osiez pas penser dans cette FAQ sur le devenir de XHTML. En ce qui me concerne, j’attends avec impatience une version stable de HTML 5.0.1 implémentée dans les principaux navigateurs du marché, en croisant les doigts pour qu’un avatar du mode quirk ne soit pas prévu ou décidé au dernier moment…

Nouvelles balises sémantiques (article, section, nav, etc.)

Comme 99,99% des sites web sont constitués des mêmes ingrédients (titres, paragraphes, micro-contenus, images, vidéos), le groupe de travail WHATWG — qui planche sur HTML5 — propose des balises permettant de découper le contenu des sites web en tranches plus fines. Peut-être pour faciliter la digestion de l’ogre Google ?

Evidemment, cette granularisation de l’information va dans le bon sens et l’implication forte de Google pourrait accélérer le processus : qui prendrait le risque de ne pas mettre son site à jour si Google menaçait gentiment les retardataires de ne plus indexer leurs sites aussi efficacement qu’avant ?

L’autre bon côté, c’est que l’intégrateur web pourrait en profiter pour ajouter une flèche éditoriale à son arc : elle viendra garnir le carquois déjà bien rempli du travailleur du web : HTML, CSS, Javascript (jQuery), graphisme, rédaction web, et plus à venir. A moins que l’intégrateur du futur ne soit qu’un presse-bouton sur DreamWeaver CS10 où toutes les balises auront leur petite icône : et hop ! une section par ici, et hop ! une nav par là… Et j’entends déjà les dialogues :

– ‘tain, fait chier, Pirefox 12 a encore planté…

– pfff, te plains pas, moi j’arrive pas à aligner mes sections pareilles sur Sexplorer 50 et Safairien 5 (en 2020, Mapple s’est fait racheté par Grozilla et Safairien n’a pas dépassé la version 5, mais des hordes de mapplemaniacs continuent d’utiliser Safairien 5 pour embêter le monde).

– Rhôoo, l’autre, il utilise même pas le reset HTML de B. Bichet (oui, en 2020, j’ai inventé un truc bien).

– Ouais, mais c’est un truc de vieux ce truc… moi j’utilise le script html4isback.js.

– Ralala, vous êtes dans les choux (oui, en 2022 on utilise encore cette expression désuette) : moi j’enlève le doctype html5 pour activer le mode Capitaine Quirk et à moi les joies du HTML 4 !

– N’empêche que je comprendrais jamais comment les mecs de XHTML 2 se sont fait bouffer par les petits jeunôts de HTML 5 à l’époque…

En tout cas, si vous voulez prendre de l’avance, vous pouvez commencer par jeter un oeil sur cette Cheat Sheet pour HTML 5 (PDF) concoctée par Veign en exclusivité mondiale sur Smashing Magazine.

Les codecs intégrés (audio, vidéo)

A côté des balises servant à baliser les contenus texte et image, HTML 5 prendrait en charge la gestion de l’affichage des données audio et vidéo par le biais de codecs intégrés dans les navigateurs. C’est à dire qu’une balise rendrait caduque tous les plugins Flash, Java ou Silverlight… Ben voyons, tu veux un Mars ou bien ? A moins que Google ne vienne au secours de HTML 5 en imposant un codec audio et video pour mettre tout le monde d’accord.

A ce sujet, Adrien Leygues signale dans l’excellent groupes de discussion webdevfr dédié aux professionnels francophones du développement web que le W3C renonce à spécifier les balises audio et video dans HTML 5 :

Face à l’impossible entente entre les éditeurs de navigateurs, l’organisme en charge de la normalisation du Web renonce à détailler les spécifications entourant les instructions relatives à la lecture de vidéos et de fichiers audio. Plutôt que de déplaire à quelques-uns en imposant un format, le W3C a donc choisi de en rien choisir, et donc de déplaire à tout le monde.

C’est balot : cette histoire d’intégrer les codecs audio/vidéo dans le navigateur était plutôt une bonne idée. Tant pis… le confort des utilisateurs est sacrifié sur l’autel des intérêts privés. J’avais malheureusement bien tapé dans l’Emile avec mon histoire de Mars (c’est marrant d’écrire un billet en direct live avec les informations qui arrivent au fur et à mesure).

Quelques liens pour aller plus loin

Pour finir (enfin, vous en aurez quand même pendant 13 ans des billets sur HTML5) voilà une petite lampée de liens gravitant de près ou de loin autour de HTML 5. Merci à tous les twittos y twittas qui m’ont aidé à un moment crucial de ma recherche sur HTML 5. Mention spéciale à webatou, justepourdire, PostMasterVeed, thierryB, Pathien : <3 <3

http://www.w3.org/TR/html5 — Vocabulaire et API’s associées pour HTML et XHTML
http://whatwg.org/html5 — Brouillon du standard HTML5, en évolution constante
http://forums.whatwg.org — Forum de discussion pour la communauté bâtie autour de HTML5
http://html5doctor.com/ — Envie d’implémenter HTML5 dès aujourd’hui ? Faites appel au docteur ! Vous trouverez tout ce qu’il faut savoir pour utiliser `
`, `
`, `
`, `
`, etc. à bon escient.
http://www.w3.org/News/2009#item119 — Annonce de l’arrêt programmé de XHTML 2 au profit de HTML 5
http://www.sitepoint.com/article/html-5-snapshot-2009/ — depuis l’annonce de l’application Google Wave architecturée autour de HTML5, ce dernier est devenu un sujet chaud dans la blogosphère. Exemples de marquage HTML sur le passage de HTML4 vers HTML5
http://www.alistapart.com/articles/previewofhtml5 — Avec l’amélioration des contrôles de formulaire, des API’s, le support du multimédia, HTML 5 promet aux auteurs de sites web plus de flexibilité et une plus grande interopérabilité. Beaucoup d’exemples concrets et pratiques.
http://www.ibm.com/developerworks/library/x-html5 — Exemples de mise en page avant et après HTML5
http://www.miximum.fr/actus/238-html5-quelles-nouveautes — Présentation en français des nouveautés apportées par HTML 5 et leur implémentation dans Firefox 3.5
http://t37.net/une-balise-nsfw-dans-html5-mais-wtf.html — Critique de Frédéric de Villamil sur l’introduction d’une balise `` (No Safe For Work) utilisés généralement sur IRC, Twitter, forums, etc. pour prévenir les lecteur que le liens contient du « matériel » pour adultes.
http://a.deveria.com/caniuse — Table de compatibilité pour les fonctionnalités présentes dans HTML5, CSS3, SVG et autres technologies web à venir. Voir aussi le wiki ou cette page sur l’introduction des fonctions dans les principaux navigateurs web.
http://www.sfgate.com — Il est devenu clair pour le W3c que le marché disponible pour XHTML 2 était trop petit comparé à HTML 5.
http://forabeautifulweb.com — Réflexions autour des microformats et de HTML5 sous l’angle de la « sémantique ».
http://www.modernizr.com — Modernizr est une petite bibliothèque Javascript qui peut vous aider à utiliser les nouvelles technologies (CSS3, HTML 5) dès maintenant grâce à une détection des navigateurs supportant telle ou telle fonctionnalité.
http://stoneship.org/ — Quelques questions intéressantes à propos de l’abandon de XHTML2 d’après les commentaires du billet de JeffreyZeldman intitulé XHTML DOA WTF.
HTML 5 and CSS 3: The Techniques You’ll Soon Be Using — Tutoriel très instructif et très clair sur le balisage d’un blog à l’aide de HTML5 et de CSS3. Utilisation un peu étrange de la balise `
` que l’auteur met plusieurs fois dans le document pour regrouper le titre des articles et les meta-informations sur le billet.
HTML5 se dévoile — L’article francophone qui manquait pour avoir une vision claire de HTML5. Merci julixyde !

Articles sur le même sujet

DVD de formation XHTML et CSS

Bruno Bichet — Tue, 04 Nov 2008 06:38:36 +0000

Après Francis Chouquet et Amaury Balmer qui nous ont gâté avec leur DVD de formation WordPress, c’est au tour de Florent Verschelde de commettre un DVD de formation sur XHTML et CSS :

Adoptez les bons réflexes pour concevoir des sites Web actuels et créatifs ! Cette formation animée par Florent Verschelde est conçue pour répondre à vos besoins quel que soit votre niveau. Débutants, découvrez toutes les bases grâce à de nombreux exercices pratiques et liens utiles fournis. Vous êtes de niveau intermédiaire, trouvez toutes les clefs nécessaires pour implémenter vos designs et concevoir des pages conformes aux standards du Web (W3C) en mettant à profit les richesses des feuilles de styles CSS. Des gabarits présentés avec Alsacreations.com vous permettront de trouver de nouvelles bases solides pour enrichir vos projets.

Articles sur le même sujet

Créer un site web en XHTML et en CSS

Bruno Bichet — Thu, 21 Aug 2008 03:53:47 +0000

Voici un tutoriel vidéo consacré à la conception d’une page web en XHTML 1.0 strict et en CSS. Créer un site web : codage envoyé par JojoRatonLaveur

Articles sur le même sujet

Zapper la maquette Photoshop et passer directement à l’intégration HTML/CSS ?

Bruno Bichet — Wed, 25 Jun 2008 15:00:28 +0000

Depuis longtemps, je me dis qu’un jour je saurai faire la maquette complète d’un design web dans Photoshop. Pourtant, je lance Illustrator à chaque fois, et dès les principes graphiques en place, je lance mon éditeur web préféré (en ce moment, c’est Aptana Studio) pour commencer l’intégration tout de go ! Dans mon for intérieur, j’ai toujours trouvé que peaufiner une maquette dans les moindres détails dans Photoshop était souvent plus chronophage qu’efficace. On se focalise sur les détails graphiques (le bidule, un peu plus à droite, c’est possible ?) au lieu de privilégier la bonne distribution des informations dans l’espace.

Et puis, en lançant mon aggrégateur, je suis tombé sur ce billet de Gou où il est question d’un article de 37 signals qui envisage de se passer de la traditionnelle maquette sous Photoshop pour se coltiner directement avec le code. Si Gou n’est pas vraiment convaincu par cette approche, je suis pour ma part rassuré sur ma façon de voir les choses :-) En effet, si la maquette Photoshop (ou Illustrator) rassure le client sur vos compétences en graphisme, elle ne dit rien sur vos talents de webdesigner, c’est-à-dire d’organisateur d’espace sur le web en vue de favoriser le clic et la navigation !

Pour vous faire une opinion sur cette question, voici une « craduction » rapide des arguments avancés par 37 signals :

Pourquoi nous zappons Photoshop

Voici quelques raisons qui expliquent pourquoi nous devrions nous passer de Photoshop :

On ne peut pas cliquer sur une maquette. C’est probablement la première raison qui fait que nous avons abandonné les maquettes statiques. Elles ne sont pas réelles. Le papier ne l’est pas plus, mais il ne provoque pas les mêmes attentes. La présentation à l’écran d’une maquette réalisée sous Photoshop devrait fonctionner. Mais vous ne pouvez pas faire défiler les menus déroulants, ni saisir du texte dans un champs dessiné. Vous ne pouvez pas non plus cliquer sur un lien. A l’inverse, un prototype HTML/CSS est une vraie expérience.
Photoshop fournit trop d’outils qui nous scotchent sur les détails. Lorsqu’on utilise Photoshop, on ne peut pas s’empêcher d’accorder de l’attention aux alignements, aux couleurs, aux formes, etc. Tout ces petits détails qui auront certainement leur importance… mais plus tard. L’essentiel est invisible pour Photoshop !
Dans Photoshop, le texte n’est pas le même que sur le web. Quand on regarde une maquette réalisée sous Photoshop, on ne peut pas modifier le texte sans retourner dans le logiciel pour changer le texte, enregistrer le fichier, l’exporter au format gif/png/jpg, etc. On ne peut pas le mettre en ligne et demander à quelqu’un de recharger la page dans cinq secondes comme il est possible de le faire en éditant rapidement un fichier HTML. On doit dire : Donnez-moi quelques minutes… Par ailleurs, les polices de caractères n’ont jamais le même aspect ni la même taille qu’en HTML. Ce n’est pas la même expérience.
Photoshop met l’accent sur la production, pas sur la productivité. Photoshop sert à construire quelque chose qui doit « paraitre », pas quelque chose qu’on peut utiliser. Lorsqu’on s’inquiète seulement de l’apparence des choses, on passe trop de temps en « fignolage ». HTML/CSS permet d’être productif en permettant d’aller de l’avant après chaque modification.
On refait souvent les mêmes choses dans Photoshop. D’accord, vous avez passé trois jours sur une maquette. Et après ? Maintenant, il faut tout transformer en HTML/CSS. C’est du temps perdu. On peut prendre ce temps pour faire l’intégration HTML/CSS et passer plutôt du temps à l’améliorer, au lieu de tout construire/déconstruire. Si l’on est pas assez rapide en HTML/CSS, on peut passer plus de temps à apprendre à travailler plus vite.
Photoshop n’est pas un logiciel très collaboratif. J’ai déjà touché du doigt cet aspect plus haut, mais laissez-moi enfoncer le clou : HTML/CSS vous permet de faire des changements, d’enregistrer et de voir le résultat. C’est le flux de collaboration que nous avons mis en place : laissez-moi changer ça, ça y est, faites F5 ! Ces changements prennent quelques secondes. Attendez, je vais placer cet élément à gauche plutôt qu’à droite. F5 ! Toujours quelques secondes. Pas besoin de sélectionner un outil, de modifier quelques éléments manuellement, d’enregistrer, d’exporter, de télécharger, de donner au client le nouveau nom de fichier, etc. HTML/CSS est idéal pour faire des prototypes itératifs ; ce n’est pas le cas de Photoshop…
Phostoshop est lourdingue. Même après 10 ans de pratique intensive de ce logiciel, je trouve toujours que l’utilisation d’un crayon et du papier est plus naturelle que de faire des aller-retours dans la barre d’outils. Un crayon peut dessiner n’importe quoi, tandis que dans Photoshop, vous devez utiliser l’outil texte pour saisir du texte, l’outil forme pour dessiner une forme, la barre d’option pour ajuster tout ça, etc.

Rien de tout ce qui précède n’est là pour dénigrer Photoshop, mais nous avons trouvé que plonger les mains dans le code HTML et CSS apporte une meilleure expérience créative. La voie du code est vraie comme Photoshop ne le sera jamais.

Quelques mots pour finir

Bon, j’espère que cette « craduction » ne comporte pas trop d’erreurs d’interprétation… J’imagine que beaucoup trouveront cette prise de position un peu extrême et se demanderont ce que l’on peut bien intégrer en HTML/CSS si on a pas fait de maquette avant…

En gros, on peut très bien dessiner une maquette sur le papier en commençant par le zoning global et en donnant des indications graphiques plus ou moins précises en fonction de la nature de la commande. Par exemple, dans la plupart des cas, il n’est pas nécessaire que la maquette soit exacte au pixel près, tant que le résultat final tient compte des détails.

L’avantage ? Selon, les méthodes de travail il sera ainsi possible de lancer Illustrator (ou de prendre son crayon) pour « dessiner » quelque chose sans se préoccuper de la largeur de la page ou de l’espace entre les colonnes. Ces éléments pourront trouver une réponse plus tard.

Je suis convaincu que même pour pour des projets ayant une charge graphique forte, il est possible de proposer l’univers graphique d’un côté pour s’assurer que la cible est prise en compte, et le prototype fonctionnel de l’autre pour valider les grands principes ergonomiques et « navigationnels ». Sachant que le premier influe sur le second et vice-versa ! Tiens, j’ai bien envie de relire Transcender CSS sous cet angle.

Articles sur le même sujet

Markdown, un plugin WordPress pour produire du XHTML facilement, rapidement et proprement

Bruno Bichet — Sun, 25 May 2008 23:30:19 +0000

Markdown est un convertisseur qui transforme du texte « brut » en code XHTML. C’est une alternative aux éditeurs WYSIWYG qui ne s’adaptent pas forcément à tous les besoins. Markdown vous permettra de rédiger des textes en utilisant un format de balisage de texte simple à écrire et à lire, puis à le convertir en code XHTML (ou HTML en option) structurellement valide. A première vue, la syntaxe utilisée est très proche de celle que vous utilisez peut-être si vous rédigez sur des wikis. A première vue, car Markdown est bien plus puissant, surtout si l’on utilise PHP-Markdown Extra…

Markdown, comment ça marche ?

La création d’un paragraphe se fait simplement en sautant une ligne. Pour créer une liste ordonnée ol, il suffit de commencer une liste comme suit :

1. Premier élément de liste
2. Deuxième élément de liste
3. Troisième élément de liste, etc.

Pour les listes non-ordonnées ul, il suffit de remplacer les chiffres par les symboles -, * ou + au choix :

- Premier élément de liste
- Deuxième élément de liste
- Troisième élément de liste, etc.

Vous me direz, oui, mais avec l’éditeur WYSIWYG de WordPress, il suffit de cliquer sur l’icône prévue dans l’éditeur pour arriver au même résultat… Certes, mais l’intérêt de Markdown est d’autoriser certaines imbrications de balises difficiles à obtenir avec un éditeur WYSIWYG, comme avoir des paragraphes p ou des citations blockquotes à l’intérieur des éléments de listes li :

- Premier élément de liste

- Deuxième élément de liste

- Troisième élément de liste, etc.

Le fait de sauter une ligne à chaque entrée de liste créera donc une balise p à l’intérieur des balises li, ce qui peut-être utile. Si vous désirez tester Markdown sans pour autant faire une installation, vous pouvez vous entrainer en ligne.

Les plus :)

La documentation sur la syntaxe est complète et on s’aperçoit que la complexité apparente de certaines combinaisons n’est que l’expression de la souplesse de Markdown qui propose souvent plusieurs façons pour parvenir au même but.

Cerise sur le gâteau, le script Markdown s’installe aussi comme plugin pour WordPress et peut à première vue être utilisé en même temps que l’éditeur visuel (à tester en profondeur quand même).

Les moins :(

Les listes de définition que j’utilise régulièrement ne sont pas prises en charge. Toutefois, le fait de pouvoir mélanger la syntaxe Markdown et le XHTML rend cet inconvénient moins critique.

Par ailleurs — et ça sera certainement un détail pour beaucoup de monde — mon enthousiasme est freiné par le fait que tout texte commençant par le symbole # devient un niveau de titre h1 et entre en collision avec mes nombreux exemples de feuilles de style CSS qui font la part belle à ce même symbole pour qualifier les identifiants. Mais encore une fois, la souplesse de Markdown permet d’utiliser le symbole backslash \ pour « échapper » les caractères « gênants ».

Markdown reloaded avec PHP Markdown Extra

S’il est possible d’utiliser du HTML à côté de la syntaxe Markdown, il n’est pas possible d’intercaler du code HTML pour formater du texte placé dans une balise div, par exemple. Heureusement, Michel Fortin a eu la bonne idée de commettre PHP Markdown Extra qui ajoute une palanquée de fonctionnalités au script d’origine :

Listes de définition,
Attribut id dans les titres pour faciliter la création de d’ancres internes,
Syntaxe pour créer des tableaux HTML très facilement,
Création aisée de notes de bas de page,
Support pour la création d’abréviation (abbr),
Etc.

En prime, vous trouverez la traduction française de la documentation de la syntaxe Markdown, ce qui vous permettra de gagner du temps !

Pour conclure

Markdown est une solution très intéressante pour ceux qui veulent garder une certaine maitrise sur le code XHTML de leurs billets et/ou permettre aux commentateurs d’enrichir leurs contributions (une option permet de désactiver le parsing des commentaires), sans qui soit nécessaire d’être geek pour celà : avec un effort de formation minimum et un peu de bonne volonté, je pense que le grand public peut s’approprier cet outil. Pour ma part, le temps de tester PHP Markdown Extra plus avant et de modifier mes exemples CSS, et je n’utilise que ça ;)

Articles sur le même sujet

Mise à jour de la grosse grosse liste #2

Bruno Bichet — Wed, 21 May 2008 23:38:17 +0000

Suite au billet sur les outils et ressources web qu’il est bon d’avoir sous la souris, j’ai mis à jour la grosse grosse liste en créant la rubrique Références, outils et dictionnaires pour l’occasion.

Articles sur le même sujet

Editeurs WYSIWYG : allez, les développeurs encore un effort :)

Bruno Bichet — Sat, 17 May 2008 19:05:59 +0000

Je suis peut-être difficile — ou compliqué — mais je ne trouve pas l’éditeur idéal (vous me direz que « trouver un idéal » revient à se mettre le doigt dans l’oeil, mais bon…). Je parle des éditeurs plus ou moins WYSIWYG comme TinyMCE, FCKEditor, Xinha, htmlArea, Cross-Browser Rich Text Editor (RTE), Cross-Browser WYSIWYG Editor, etc. A noter que WordPress intègre par défaut une version modifiée de TinyMCE qui fonctionne désormais plutôt bien… lorsqu’on se limite à des structures de contenus assez simples.

Moi je rêve d’un éditeur WYSIWYG qui permettrait des imbrications de balises comme l’insertion de listes de définition à l’intérieur d’une liste ordonnée ou non-ordonnée, par exemple :


  
    
      Terme 1
      Définition 1
      Terme 2
      Définition 2

Voire même qui permettrait de choisir les balises se trouvant à l’intérieur des éléments dd comme :


  
    
      Terme 1
      Définition 1
      Terme 2
      Définition 2

La question n’est évidement pas de (re)lancer un débat sur l’intérêt de mettre en place une telle structure, mais plutôt de voir si un tel éditeur existe déjà (le web est si vaste, on ne sait jamais) ou s’il serait possible de créer un plugin pour les éditeurs existants, sur le modèle de l’éditeur de Scribefire qui permet de saisir la balise HTML de son choix en cliquant sur Custom HTML suite à une sélection de texte (ce qui n’est déjà pas si mal).

L’idéal serait évidemment de pouvoir proposer, suite à une sélection, une liste de balises en fonction de la sélection elle-même : type bloc ou en ligne, afin d’éviter les imbrications contre-nature ;)

Je rêve, ou bien ?

Articles sur le même sujet

13 outils pour l'intégrateur web

Bruno Bichet — Thu, 08 May 2008 20:00:13 +0000

Comme tous les travailleurs, l’intégrateur HTML & CSS a ses petites habitudes et une boite à outils bien remplie. Depuis longtemps, j’utilise les bookmarks en ligne. Mais si je bookmark régulièrement les liens qui m’intéressent, la recherche d’information dans ces services est souvent moins efficace que le lancement d’une recherche dans Google ! Et comme il peut être utile d’avoir certaines ressources à portée de souris, un billet est un pense-bête comme un autre. Magneto :

yoyodesign — Nombreuses traductions d’articles et de recommendations du W3C. Voir également la liste des traductions françaises des documents du W3C
htmldog — C’est en anglais, mais la clarté des explications en fait une référence incontournable pour tout ce qui touche au développement web, avec un dictionnaire HTML où l’on retrouve toutes les balises passées au crible avec des exemples d’utilisation, les attributs requis, les attributs optionels et des exemples !
gotAPI — regroupe les principales API du web dans une interface Ajax très réactive : HTML, CSS, Javascript, jQuery, PHP, Ruby, asp, mais aussi le fonctionnement de certains CMS comme Drupal ou de services web comme Flickr.
giminik — La liste des balises XHTML 1.1 (ou 1.0 Strict sans les éléments obsolètes), leur utilité, leurs attributs, leurs évènements et la relation entre parents et enfants (hiérarchie). Indispensable pour construire un document valide.
Opquast — l’ensemble des bonnes pratiques pour la qualité des services en ligne. Abonnez-vous au fil RSS des bonnes pratiques pour avoir votre dose quotidienne.
Openweb — Les bonnes pratiques en action pour les technologies du web (XHTML, RSS, CSS, DOM, PNG) et les différents thèmes qui y sont associés (pages dynamiques, navigateurs, accessibilité, études de cas, mise en page, multimédia, structure).
Développez (pour le web) — toutes les technologies du web à portée de clic. Des tutoriels, des cours, des documents à télécharger. Allez, faites le plein !
Forum Alsacreations — Presque toutes les questions sur les CSS et le HTML et quasiment toutes les réponses ! Cerise sur le gâteau, la FAQ est complète et bien organisée.
Format publicitaire AdSense — Et oui, qui n’a pas eu besoin de prévoir des emplacements publicitaires dans une charte graphique et de chercher les formats les plus courants ? Voici les formats en vigueur chez Google, qu’il s’agisse des formats textes, images ou vidéos.
Blogmarks — Avec del.icio.us et ma.gnolia, je me suis remis à utiliser blogmarks qui garde un petit quelque chose en plus par rapport aux autres solutions de bookmarking social.
Bluevertigo — Un maximum de ressources graphiques et typographiques dans une interface toute en scroll horizontal. Au menu : Photothèques, clip-art vectoriel, polices de caractère, logothèques, sons, brosses (brushes) Photoshop, modèles 3D Poser, icônes, palettes de couleurs, générateurs de textes, échantillons graphiques (patterns).
WordReference — Sans doute le meilleur site de traduction (mot à mot en incluant les locutions idiomatiques). Pour les cas difficiles, vous pouvez utiliser le forum. Nombreux plugins Firefox pour la recherche par langue.
Les dictionnaires — Un maximum de dictionnaires thématiques classés par catégories : langue française, synonymes, encyclopédie, citations et expressions, gastronomie, humour, acronymes, etc. Mention spéciale pour le Trésor de la Langue Française Informatisée (TLFI pour les intimes) : interface web 0.2 mais très efficace ;)

Voilà, c’est fini. Maintenant, si vous avez des sites qui vous servent régulièrement dans votre job, vous pouvez balancer les liens ;)

Articles sur le même sujet

Granularisation du balisage HTML : parce que nos documents le valent bien…

Bruno Bichet — Wed, 30 Apr 2008 07:51:41 +0000

Suite à mon dernier billet sur les différentes manières d’aborder le balisage HTML d’une hCard, Neovov et burningHat ont soulevé la question de la sur-sémantisation du code d’une manière générale et de la sur-utilisation des listes en particulier. Neovov, par exemple, ne voit pas pourquoi on devrait mettre des listes partout. burninHat quant à lui, se demande si l’on ne n’accorde pas trop d’importance à la description de notre code HTML… Magneto !

Trop de listes tue les listes ?

Il n’y a jamais trop de listes, car tout est une liste :

le mot est une liste ordonnée de lettres,
la phrase est une liste ordonnée de mots,
le paragraphe est une liste ordonnée de phrases,
le texte est une liste ordonnée de paragraphes.

Dans ces conditions, on peut même se demander pourquoi utiliser des balises p pour les paragraphes au lieu d’une bonne vieille balise li… Et oui, il est possible de faire des p dans le li (ok, elle était facile, celle-là…) :D

Plus sérieusement, un des reproches que l’on fait souvent au HTML, c’est son manque de balises pour décrire les contenus. Alors ne boudons pas notre plaisir et profitons pleinement de nos 3 sortes de listes :)

Des descriptions à la Zola ?

La question que je me pose toujours quand je suis face à un document à intégrer htmlement parlant, c’est : à quoi celà devrait-il (va-t-il) ressembler en l’absence de feuille de style ou plus précisément : comment faire pour que la forme du document soit le plus proche possible du fond, sans CSS.

Je me rends compte que l’utilisation des listes à chaque fois que celà est possible améliore énormément la lisibilité des documents en donnant un aperçu de leur structure dès le premier coup d’oeil.

Reçu HTML 5 sur 7 ;)

Je suis convaincu que la granularité du balisage HTML doit être la plus fine et la plus précise possible. A cet égard, les travaux sur le HTML5 vont dans ce sens avec l’arrivée prochaine des balises relatives au découpage des documents comme section, nav, article, aside, header, footer ou encore la présence de l’élément dialog pour regrouper certains type de contenus. Cet balise dialog qui s’ajoute d’ailleurs aux éléments permettant de faire … des listes.

Ainsi, même si l’on pouvait utiliser les listes de définition pour mettre en forme des dialogues, le HTML 5 pousse le découpage un cran au-dessus. Une des raisons qui milite selon moi pour cette granularisation, c’est l’accessibillité des documents pour les lecteurs vocaux qui pourront moduler l’intonation en fonction des différents type de balise HTML.

Note : les plus observateurs d’entre vous auront peut-être remarqué que j’aurais pu créer une liste non-ordonnée dans l’avant-dernier paragraphe avec l’énumération qui commence par section, nav, etc. Je n’ai pas opté pour une liste, car le flux naturel de lecture risque d’être perturbé par un découpage trop systématique ;)