Paris, photo, humeurs, un peu de HTML/CSS pour faire sérieux. Feinte innocence et vraie naïveté (ou vice-versa). Encore un blog qui agite ses petits bras en couinant "Viens me lire !"
À Djac Baweur, avec ma compassion sincère
Si vous êtes impatient, la substantifique moelle de l'article est ici.
Rappel : ce blog est (en juin 2007) en niveau confiance, et en version 2 migrée à partir de la v1. Le passage en version 2 pur sucre se fera … un jour (note de juin 2009 : c'est fait depuis un moment déjà). Je n'ai aucun lien particulier avec Over-Blog, je suis un blogueur basique de chez basique. Juste un peu soigneux.
L'éditeur FCKedit est, en apparence, un bel outil proposant une palette classique d'options de mise en page : choix de la police de caractères, passage en gras ou en italique, écriture en indice ou en exposant, insertion de listes à puces ou numérotées, un fort bien fait système d'insertion d'images ou de liens e tutti quanti. L'intention, louable, est d'épargner au néophyte le recours à l'ABOMINABLE (qu'il croit) langage HTML, à ses balises absconses, à ses codes incompréhensibles par un humain normal. Langage informatique + jargon angloïde : au secours, les extra-terrestres attaquent !
Laissez-moi le temps de peigner mes tentacules verdâtres et de ranger my eight eyes pédonculés… voilàààààà c'est fait… et bavardons un peu.
"Tout simple" pour dire : rédigé au fil de la plume, avec quelques illustrations, en se satisfaisant de ce que propose FCKedit en mode normal.
Hé bien, figurez-vous qu'on s'en sort très bien comme ça, inutile de chercher plus loin, et d'ailleurs ça m'arrive de temps en temps. Mais, pour reprendre le titre de ce billet, un article tout simple peut-il être soigné ?
Les gens soigneux veulent pouvoir mettre des accents ou des cédilles aux majuscules. À toutes les majuscules qui en ont besoin. Éééévidemment. Ça va sans dire. Cadeau pour briller en société : tous ces appendices s'appellent des signes diacritiques ; casez le terme avec à-propos dans la conversation, vous passerez pour un dieu de la langue française.
Les gens soigneux veulent pouvoir écrire des voyelles liées, ça leur tient à cœur, ils ont l'œil pour ça.
Les gens soigneux sont très attentifs à la ponctuation, ils savent que les signes de ponctuation simples comme la virgule ou le point s'écrivent immédiatement après le mot et ne demandent qu'un espace ensuite, alors que les signes composés demandent un espace avant et un autre après : voyez-vous ce que je veux dire ? Non ? Allons … cherchez un peu ! Vous trouverez bien un exemple ou deux ; ensuite, ça vous sautera aux yeux. Ils savent aussi que la présence d'un espace n'autorise pas pour autant le signe composé à se balader tout seul au début de la ligne suivante, l'espace qui précède ces signes doit être insécable. Faites varier la largeur de votre fenêtre de navigateur et observez les transformations de ce paragraphe, ça devrait aider.
Les gens soigneux ne se préoccupent pas trop de l'art de faire tomber des cœurs roses sur leur page d'accueil (c'est tout juste bon à bouffer du CPU et compliquer la lecture). En revanche, les gens soigneux aiment bien
qu'une citation tant soit peu longue ressorte nettement.Ce que l'on conçoit bien s'énonce clairement et les mots pour le dire viennent aisément.J'admets pouvoir encore progresser dans ce domaine.
Ils finissent par découvrir, par exemple sur le site du Zéro et son fort bon tutoriel, que
| pour produire ça | on doit écrire ça |
|---|---|
| Espace insécable | |
| À | À |
| É | É |
| œ | œ |
| < | < |
| une longue citation | l'écrire entre <blockquote> et </blockquote> |
| etc. | etc. (gag !) |
À ce moment, les gens soigneux sont très contents. Ils ont l'impression d'avoir appris des choses utiles. Certes c'est du gros vilain HTML mais, justement, FCKedit permet d'ajouter du gros vilain HTML grâce au mode source. C'est-y pas bien pensé, ça ?
Procédé spontané : rédiger l'article dans la fenêtre normale, passer en mode source pour rajouter les quelques finitions évoquées, revenir en mode normal pour juger de l'effet. Pas mal, pas mal. Allez, on publie. Oups, il faut corriger une petite faute ? Nouveau passage dans FCKedit, nouveaux allers-retours, sifflotements joyeux, on avance on avance. Et zou on re-publie.
Et on prend une attaque, parfois dès la première publication : tout a foutu le camp ! Les majuscules accentuées ont résisté à la tourmente, les <blockquote> aussi, mais tout le reste a dégénéré : les espaces insécables se laissent couper en rondelles, les belles balises <strong> pour illustrer le passionnant article technique promis à un succès planétaire (c'est quoi, ces rires étouffés ?), les belles balises qu'on avait pris la peine d'écrire <strong>> ,en toutes lettres, pour qu'elles s'affichent <strong>, ont été prises au pied de la lettre et polluent la suite du texte … bref, c'est n'importe quoi.
Et regardent de plus près le fonctionnement de FCKedit.
Quand on appuie sur "Publier", il se passe un tas de trucs dans les coulisses. FCKedit rajoute les balises fermantes qu'on aurait pu oublier : ça, c'est sympa.
Il supprime, en mode confiance, les balises proscrites telles que <script> ou <form>. Rien à redire, c'est la règle du jeu.
Il se livre aussi à un reformattage sauvage du code source en fusionnant les lignes consécutives. Pénible pour relire, par exemple, une liste, mais encore inoffensif.
Il remplace tous les &quelquechose; par leur valeur et ça, c'est pas glop du tout. Que é devienne é
, ma foi pourquoi pas, c'est plus lisible. Mais que devienne un espace ordinaire, que < soit remplacé par <
, ça c'est vraiment pas glop. En version 1 FCKedit faisait l'inverse : é
devenait é et ainsi de suite.
Il va même – j'ai découvert ça récemment – jusqu'à rajouter à la fin un span invisible et nommé, en toute candeur, anti bug fck
!
Et décident de préparer leurs articles tranquillement sur leur micro, avec un éditeur de texte. Oui mais, toutes les saletés, les &truc; et les <machin>, il faut se les taper à la mimine ?
Oui et non : les &truc; un peu rares tels que œ ou À oui, je les tape au fur et à mesure. Pour tout ce qui est espaces insécables et ponctuation, je procède inversement : je tape des espaces ordinaires avant les ? ! : ; sans souci particulier. Ensuite, ultra-moderne, j'utilise la fonction rechercher/remplacer de l'éditeur pour mettre ? à la place de ? … Grandiose, non ? Chronométrage : pour l'article que vous êtes en train de lire, ça vient de me demander 50 secondes.
Et le balisage ? Un peu pareil : les balises occasionnelles se tapent au fil de l'eau. Truc déjà donné ailleurs pour ne pas oublier de refermer : taper d'abord le couple balise ouvrante - balise fermante
puis remplir l'intervalle. Si vous utilisez Notepad++ vous pouvez même le régler pour qu'il écrive la balise fermante dès que vous terminez la balise ouvrante, laissant le curseur entre les deux – TRÈS commode. Pour les paragraphes (tous mes articles sont organisés en paragraphes) c'est assez simple : pendant la rédaction, je tape de braves retours à la ligne comme avec un traitement de texte. Ensuite : une balise <p> au tout début du premier paragraphe puis, à la fin de ce premier paragraphe, un couple </p><p>pour terminer le paragraphe et ouvrir le suivant. Ce couple est ensuite copié/collé partout où c'est nécessaire. Bien sûr, la toute dernière balise <p> qui ouvrirait un paragraphe vide est à supprimer. Chronométrage du processus sur le présent article : 65 secondes.
Variante : préparer une batterie de paragraphes vides, les remplir, faire le ménage à la fin. C'est vous qui voyez.
Comme vous le constatez, tout ceci est d'une difficulté insurmontable.
Reste la question des images et des liens, plus ardue il est vrai.
Pour les liens, ma foi … une url, ça se copie/colle en un rien de temps, non ?
Pour les images : à l'époque de la V1, lorsque FCKedit respectait encore à peu près ce qu'on tapait, j'avais pris l'habitude de marquer tout bonnement (image telle ou telle)
dans l'article en cours de rédaction. L'article terminé, balisé et tout, atterrissait ensuite dans la fenêtre "Source" puis, de retour en mode normal, je remplaçais dans FCKedit les pense-bêtes par les images désirées, en utilisant l'outil approprié. C'était le bon temps …
Aujourd'hui j'ai inversé le processus : comme avant, l'article est rédigé à l'éditeur de texte, avec les pense-bêtes. Par ailleurs, dans la fenêtre normale de FCKedit, je crée une ébauche de l'article, ébauche ne contenant que les images, proprement dimensionnées et disposées, et quelques mots de remplissage. Passage en mode source et recopie du (complexe) balisage dans l'éditeur de texte, aux bons endroits.
Ayé, l'article est prêt avec tout son harnachement. Le seul moyen, à l'heure actuelle (juin 2007, et vivement que ça change !), de ne pas dénaturer ce code source est de le recopier dans la fenêtre "Source" totalement vide. On peut vérifier le résultat en prévisualisant le bébé.
Et voilà le moment le plus dangereux : la prévisualisation révèle forcément un ou plusieurs petits défauts. Il faut résister à la tentation de corriger dans FCKedit et n'intervenir que sur la version locale. Quand elle est prête, rebelote et copie dans une fenêtre "Source" totalement vide (vi vi vi : j'insiste lourdement).
Soyons précis : tant que l'article n'est pas encore publié, que FCKedit n'a pas fait sa tambouille, on peut encore faire des retouches à même le source, voire dans le mode normal. Je vous conseille fortement de tout de même prévisualiser le résultat. Mais pour modifier l'article une fois publié, c'est fichu ! Il faut repartir d'une fenêtre "source" vide.
Pffffouuu c'est lourd, c'est laid, c'est fastidieux, ça devrait être plus simple. Entièrement d'accord, et il me tarde de revenir à un fonctionnement plus normal. En attendant, la Constitution garantit votre droit de préférer vous arracher les cheveux … ;-)
La morale de l'histoire est, en fait, assez simple :
Il ne faut surtout pas l'utiliser pour une retouche, même minime, d'un article déjà publié.
Si le cas se produit, voici la procédure que j'utilise :
On peut alors vérifier le rendu en prévisualisation mais, pour corriger ne serait-ce qu'une patte de mouche, il faut repartir de l'éditeur de texte et copier/coller de nouveau vers la fenêtre du mode source complètement vide.
C'est un peu besogneux mais ça marche. Je viens d'ailleurs de procéder ainsi pour ajouter le présent résumé.
Mais pourquoi donc l'éditeur OB ne se contente-t-il pas de ce qu'on lui écrit ? Pourquoi le recuisine-t-il ?
Vous n'êtes pas le seul utilisateur de cet éditeur : il doit satisfaire aussi bien des gens (comme vous ?) peu soucieux de technique, voulant juste écrire rapidement un billet, que des perfectionnistes dans mon genre (comme vous ?).
En mode normal l'éditeur se charge de créer un balisage correct à partir des actions de l'utilisateur, novice ou pas : retours à la ligne, clic sur les divers boutons, etc. et tout va à peu près bien dans les limites de l'outil.
En mode source l'utilisateur, novice ou pas, peut intervenir sur ce balisage et donc y ajouter des erreurs – et les ennuis commencent. Les novices sont les plus difficiles à satisfaire : ils ne commettent pas tellement plus d'erreurs que les perfectionnistes mais eux ne les voient pas. Il revient donc à l'éditeur de tenter de reconnaître et corriger ces erreurs : un éditeur qui se contenterait de dire "Je ne publie pas votre article parce qu'il manque une balise à tel endroit" serait assez mal vu…
Et qu'est-ce qu'une erreur ? Une balise ouvrante sans balise fermante, des balises entrelacées… sont des erreurs incontestables : l'éditeur tentera, avec plus ou moins de bonheur, de deviner l'intention de l'auteur et de rectifier le balisage en conséquence. Mais un paragraphe ou un div complètement vides ? Un span dans un span dans un span ? Erreur ou point de départ d'une fabuleuse cuisine de CSS ? Sachant que la plupart des utilisateurs d'OB ne sont pas des virtuoses de ce genre de chose, l'éditeur penchera pour une erreur et sabrera tout ça. Il incombe aux perfectionnistes de trouver des solutions moins pathologiques/élégantes – ou de changer de plateforme.
C'est un peu comme avec les appareils photo : les automatismes sont très commodes dans la plupart des situations, il serait sot de les dédaigner. Si on se lance dans des photos un peu limite il faut débrayer l'automatisme, repasser plus ou moins complètement en manuel, et savoir ce qu'on veut et ce qu'on fait. Cette méthode demande de l'apprentissage, elle reste pourtant plus fiable et plus simple que de tenter de ruser avec l'automatisme. Dans tous les cas l'important reste la qualité de l'objectif, avant la présence de trente-six boutons chromés – si, bien sûr, on est assez vieux jeu pour croire qu'un appareil sert à faire des photos avant de flatter la vanité de son propriétaire.
Dans le cas d'OB je trouve que l'objectif est plutôt bon : le code produit est efficace et le blog bien référencé, donc je m'accommode de l'outil et de ses contraintes plutôt que de me lancer dans la fabrication d'un bijou de HTML que personne ne trouvera dans les annuaires.
Bien que l'éditeur soit aujourd'hui (2009) moins énervant que lors de la rédaction de cet article j'ai conservé le principe d'écrire ou modifier les articles sur le micro, puis de les copier ou recopier en une seule fois dans l'éditeur vide. Pourquoi ?
D'abord mon micro n'est pas tributaire des temps de réponse d'Internet ni de la disponibilité de l'admin OB. Ensuite, du fait même que je rédige d'abord sur le micro, tous les articles y sont présents : leur sauvegarde se fait toute seule. Enfin, puisque tous les articles sont sur le micro, il devient simple et rapide d'en modifier plusieurs pour les harmoniser, de dupliquer ou déplacer des lignes d'un article à l'autre, de rechercher les articles contenant un certain texte, etc.
La plupart de mes articles ont une structure très simple : du texte, quelques photos, centrées le plus souvent, et basta. Il y parfois des effets spéciaux
comme un lire la suite
, une photo zoomable ou un panoramique. Pour chacun de ceux-là j'ai créé une bonne fois un petit fragment de HTML prêt à l'emploi et clairement nommé (exemple : FRAGMENT - lire la suite.html), il suffit de le recopier dans l'article puis d'y modifier quelques url et quelques identifiants : pas besoin de réinventer la roue.
Enfin, si l'éditeur recommence à zozotter, je suis paré en attendant des jours meilleurs…
![[CSS] Marges courbes : derniers mots](https://image.over-blog.com/gw19mp5r7T7XCQ6rM02-5bERbWE=/400x260/smart/filters:no_upscale()/idata%2F0386897%2Fpharma%2Fmargescourbes%2FPoireArtyRogneG.png)
![[CSS] Marges courbes : solution](https://image.over-blog.com/MLk_D_jQ873MGK1i62mvfECzz_Q=/400x260/smart/filters:no_upscale()/idata%2F0386897%2Fpharma%2Fmargescourbes%2FPoireMini.png)