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 !"
Ce fut un long pensum, cette fois on termine.
Le propos est d'utiliser Notepad++ sur nos fichiers HTML locaux pour
Si vous avez déjà réindenté du code, cet article ne vous apprendra rien. L'exemple utilisé est ancien, de la version 1.94 d'OverBlog. Avec d'autres designs ou la version 2, les détails changent mais le principe reste le même.
Dernière précision : cet article est LONG (trèèèès long) à cause des nombreuses figures et parce que je vais dans le détail des manipulations, mais je ne le crois pas très difficile. Et puis, je ne saurai pas faire court avant qu'il y ait des dentistes pour la volaille…
Si vous m'avez suivi jusqu'ici, il y a sur votre micro-ordinateur
LOCALou
TEST– question évoquée dans le deuxième article au § 2.2.
Toutes ces copies locales permettent de travailler sans dépendre de la disponibilité d'OverBlog, et de n'y remonter que des modifications convenablement testées.
Quelques conseils avant de nous y mettre vraiment :
Allons-y (Alonzo, si vous connaissez vos classiques).
Ouvrez le fichier HTML avec Notepad++. Dans le menu "Affichage", faites "Afficher tous les caractères", "Retour automatique à la ligne" (il y a aussi des boutons pour ça sur la barre d'outils – trouvez-les !) et enfin "Replier tous les blocs" (pas de bouton pour celui-là). Résultat (déjà vu dans le précédent article) :
Remarquez la mention des CR-LF ou LF (retour chariot-saut de ligne) à la fin des enregistrements (= des lignes de HTML). Quel intérêt ? Ce sont de bons repères visuels. Ils montrent, par exemple, que la ligne DOCTYPE, bien qu'affichée sur deux lignes d'écran, est contenue dans un seul enregistrement. C'est confirmé par la présence d'un espace entre les numéros 1 et 2 : ils sont bien des numéros d'enregistrement (du fichier) et pas de lignes (de l'écran).
Sans le retour automatique à la ligne, nous n'aurions vu que le début des enregistrements. Et sans l'affichage de tous les caractères, rien ne nous aurait indiqué qu'ils se poursuivaient au-delà du bord droit de l'écran – parce que, franchement, qui fait attention à la présence d'une barre de défilement horizontale en bas d'une fenêtre ? Morale : il est important de tout voir à l'écran pour ne rien négliger.
Progressons : dépliez l'élément html. Le niveau immédiatement inférieur dans la hiérarchie apparaît, il ne comporte que head et body. Nous avons assez trituré le head auparavant et le laisserons désormais tranquille. Dépliez le body. Résultat déjà vu :
Et ensuite :
Innovons : dépliez aussi le div main3 (ou autre) qui apparaît. Résultat :
L'organisation du fichier commence à sauter aux yeux :
Rappel : main3 et MainTab sont des noms propres à certains designs, pas de panique s'ils s'appellent autrement chez vous.
Questions : on voit deux balises ouvrantes <div> pour une seule fermante </div>. Et où est passé le </head> de fermeture alors qu'on voit le </body> et le </html> ? Bonnes questions, les réponses arrivent.
Déplions le bandeau OverBlog :
Voilà le </div> qui manquait ! Voilà aussi un (petit) tas de choses sur lesquelles nous allons nous faire la main. Insérez un retour chariot (= tapez sur la touche Enter) aux endroits suivants :
L'idée est de ne pas laisser sur une même ligne des balises de niveaux hiérarchiques différents. Résultat :
Maintenant, l'alignement des marges. Sélectionnez le contenu du div et aussi sa balise de fin (enregistrements 420 - 425 sur la figure). Faites tout glisser vers la gauche par plusieurs pressions sur Maj+Tab. Puis sélectionnez seulement le contenu du div (enregistrements 420 - 424) et faites-le glisser d'un cran vers la droite avec Tab.
Pour juger de l'effet produit, vous pouvez annuler l'affichage de tous les caractères et le retour automatique à la ligne, vous devriez voir ceci :
N'est-ce pas qu'on voit mieux qui contient qui ? Petit plaisir ultime, repliez le bandeau OB et regardez :
Cette fois les balises, au moins les plus élevées dans la hiérarchie, se répondent "harmonieusement". Jouez à plier et déplier pour vous en convaincre : quand un bloc est plié sa balise de fin est cachée dedans, quand il est déplié elle apparaît. Si vous voulez, rajoutez un commentaire tel que <--fin de main 3--> après le </div> de l'enregistrement 426, ça ne peut pas faire de mal.
Dernière remarque : on pourrait être puriste et vouloir mettre sur trois enregistrements successifs la balise <a (etc.) > qui ouvre un lien, puis le texte du lien, puis la balise de fermeture </a>. Mais si le texte du lien n'est pas très long, et même s'il contient d'autres balises, à quoi bon ? Notre but n'est que de gagner en lisibilité pour un œil humain.
Toute la suite obéit aux mêmes principes, et à ceux-là seulement :
C'est simple et je souhaite que ça vous paraisse sensé. C'est juste "un peu" long à mettre en œuvre…
Je pourrais vous lâcher là en vous indiquant que vous en savez assez pour continuer tout seul : ce serait vrai mais un peu cruel. Allez, je vous accompagne encore un peu…
Il faut maintenant passer à MainTab, le principal composant de main3.
Une table HTML (en très gros) se décompose d'abord en plusieurs lignes ("row", rangée) encadrées par <tr> et </tr> (tr = table row). Chaque ligne se décompose à son tour en une ou plusieurs cellules encadrées par <td> et </td> (td = table data), soit deux niveaux hiérarchiques d'un coup.
En dépliant les blocs au fur et à mesure de leur découverte, et en supprimant au passage les lignes vides, vous verrez apparaître un premier <tr> où il est question de top, puis sa balise fermante et le <tr> suivant. Arrêtez-vous là :
En procédant comme tout à l'heure, on arrive à :
Notez la symétrie des balises ouvrantes et femantes, notez aussi les deux commentaires qui encadrent le texte écrit par vous, pour l'isoler du texte "sacré" produit par OverBlog.
Manipulation analogue pour le pied de page : pour le confort, on replie le top désormais fini, on pose un signet (une pastille) à la ligne 434, et on passe de ceci…
… à cela :
Haut et bas, c'est fini ! On les replie.
Pourquoi prudents ? Sur la figure précédente, le corps de la page est tout entier replié dans le modeste tr de la ligne 42, et il se termine au pied de page, en ligne 434 : ça fait presque 400 lignes !
Posons une pastille sur cette ligne 42, ajoutons un commentaire à tout hasard, et déplions :
Déplions chacun des deux td qui apparaissent (dans notre exemple, aux lignes 44 et 344 ; chez vous, il peut y en avoir entre un et trois selon le nombre de colonnes de modules) et seulement ceux-là ! sans quoi ça deviendra illisible. Supprimons les lignes vides, déplions leftnav, encore un peu de ménage dans les lignes vides et ça nous donne :
… où nous reconnaissons des noms évocateurs.
Si vous utilisez un autre design, la table est remplacée par un emboîtement de plusieurs div. Dépliez-les jusqu'à faire apparaître leftnav et les modules, d'une part, et content d'autre part.
leftnav c'est la colonne de modules de gauche, rightnav (absente de l'exemple) la colonne de droite et content le contenu propre de la page, autrement dit les articles.
Attaquons-nous à RightPart, module de texte libre. Déplions-le jusqu'à faire apparaître box-content :
La série de huit div intermédiaire entre box et box-content n'existe que dans les designs 100, elle permet un contrôle fin de l'encadrement des modules. Nous n'approfondirons pas la question ici ; remarquez seulement la série de huit balises fermantes qui correspond. Elle est suivie par la fermeture de box. Quant à la fermeture de box-content, elle est pour le moment cachée dans les lignes repliées. Autrement dit : le code est déjà proprement organisé, toujours ça de gagné.
On déplie box-content et attention les yeux :
Heureusement pour la longueur de la figure, il y a encore 40 lignes masquées ! On aperçoit le titre du module, suivi du texte proprement dit.
Notez que ce texte est prolongé par un div class="clear" utilitaire ajouté par OverBlog. Isolons-le sur une ligne et, comme tout à l'heure, marquons le début et la fin du texte par des commentaires.
Sélectionnons le texte ainsi délimité :
Pourquoi ? Pour le copier/coller dans un nouveau fichier, que j'ai appeléFRAGMENT - Rightpart.html qui sera tout prêt à resservir ensuite :
Pourquoi ce nom ?
Yapuka.
Plus qu'à faire la même chose pour l'éventuel autre module de texte libre et le module de liens : ce sont les seuls modules contenant du texte écrit par vous. Laissez les autres modules tranquilles. Pensez à créer les fichiers fragments correspondants.
De même, créez FRAGMENT - top.html et FRAGMENT - footer.html à partir du texte clairement repéré par les commentaires dont vous l'avez encadré.
Tant qu'on y est, dans le fichier correspondant à votre page d'accueil, mettez des commentaires analogues autour du texte du message d'accueil et créez le fichier fragment qui correspond.
Dernière touche : toujours dans ce fichier, mettez des commentaires autour du texte du premier article, mais il est cette fois inutile de créer un fragment.
Enfin, ouvrez le fichier dans votre navigateur :si vous avez proprement bossé, RIEN n'a changé.
Ça y est : vous avez toutes les pièces détachées de la page d'accueil de votre blog.
On a presque terminé. Ouvrez maintenant dans Notepad++ TOUS les fichiers locaux. Là, on apprécie vraiment d'avoir des onglets… À titre indicatif, quand je fais ça chez moi, ça ressemble à ça :
Dans le fichier que vous venez de "peigner", repliez les colonnes de modules, le haut et le bas de page. Sélectionnez carrément tout le div id="#top" et recopiez-le dans tous les fichiers ouverts. Faites de même avec les colonnes de module et le pied de page. Évidemment, abstenez-vous de propager de la même manière le div id="#content" !
Pour la bonne règle, vérifiez au navigateur que rien n'a changé pour aucun fichier.
C'est fini, l'atelier local est prêt à servir.
Le plus simple est de vous donner quelques exemples, non ?
Travaillons sur la page d'accueil : ouvrez-la dans le navigateur ainsi que dans Notepad++. Tant qu'on y est, ouvrez aussi custom.css dans l'éditeur, ça va forcément servir.
Tapez le texte qui vous convient au bon endroit, clairement repéré par les commentaires. Sauvegardez, rafraîchissez le navigateur, jugez du résultat, et recommencez jusqu'à ce que vous soyiez content. Quand c'est fait, enregistrez le texte mis au point dans le fichier fragment qui correspond. Le texte seulement : ni les commentaires d'encadrement, ni surtout le balisage d'emballage. Copiez-collez le fragment au bon endroit d'OverBlog, en utilisant le mode source de FCKedit. C'est tout !
Ben… c'est pareil.
En temps normal, il n'y a pas besoin de passer en local, les outils OB suffisent largement. Mais je voulais ajouter une partie en italiques, et ce n'est pas prévu dans le contrat. En travaillant sur le module de liens d'un fichier local, j'ai fini par déterminer le balisage convenable, qu'il a "suffi" (euphémisme) de copier/coller ensuite, ligne à ligne, dans le champ "Nom du lien" de l'écran OB – parce que ce champ peut recevoir aussi du balisage HTML, faites l'essai en ajoutant un tout simple <br /> dans un de vos liens.
Là, ça devient vraiment commode : au lieu de jongler dans tous les sens avec l'interface d'OverBlog et de payer vos hésitations par des temps de réponse… variables, affichez le squelette de la ou des colonnes de modules comme nous l'avons fait au § 3.2. Maintenant, déplacez les modules vous-même autant que vous voulez, y compris d'une colonne à l'autre. Toujours sauvegarder/rafraîchir pour se rendre compte, et annuler (Ctrl+Z) si ça cafouille.
Quand vous êtes au point, il n'y a rien à remonter sur OverBlog, et il faut toujours déplacer les modules avec l'interface d'administration, mais au moins vous savez où vous allez.
Où se procurer le code source ? Ajoutez le module dans votre blog, affichez votre blog avec le nouveau module en place. Affichez le code source de la page, repérez le nouveau box, copiez tout son code et collez-le dans votre page locale, entre deux modules déjà présents. Et nous sommes ramenés au problème précédent.
Tiens, celui-là par exemple…
Une de mes pages locales, reprise de l'affichage d'un article court, ne me sert qu'à ça. Au repos, son div class="contenuArticle" ne contient que les commentaires d'encadrement et une ligne de texte.
D'abord poser une pastille sur le commentaire de début, pour y revenir commodément, puis remplacer la ligne-bidon par le nouveau texte. Je le complète tranquillement : ajout des images (juste une ligne "image numéro tant", en fait – voir cet article au §8 pour une explication), ajout du JavaScript des "lire la suite", bref tout le toutim, et je juge du résultat aussi précisément qu'avec la prévisualisation d'OB.
Quand j'aurai terminé, je vais d'abord remonter les illustrations ( 17 en tout, sans compter celles reprises d'un précédent article ! ), copier/coller en mode source le HTML ainsi mis au point, rajouter les images avec le bouton approprié de FCKedit, et me préparer une tasse de thé.
Encore un exemple vécu et récent.
D'abord ajouter le module "album photo" (cf § 4.5), puis afficher les nouvelles pages : le sommaire de l'album et une page quelconque. Sauvegarder ces deux pages en local, peigner le HTML comme je viens de le décrire, et me mettre au travail. Comprendre la structure du HTML, ajuster le CSS… en un petit après-midi c'était au point.
Alors là…
Le JavaScript, contrairement au HTML et au CSS, est un langage de programmation . Pas plus compliqué qu'un autre mais pas plus simple : on doit décrire pas à pas tout ce qu'on veut faire faire, pas seulement le résultat désiré – la programmation, ce n'est pas autre chose. Pour le mettre au point, il faut inévitablement tâtonner, faire afficher les points où l'on passe, les variables que l'on modifie. Le grand jeu, quoi – parfaitement impensable d'y jouer à même son "vrai" blog. Donc : travail local et café noir.
Pas fâché de boucler la série. J'aurais pu tout résumer en une seule phrase telle que : avec un bon éditeur de texte, tester les modifs sur des copies locales. Grrr ! Cinq pavés pour dire ça ? Du calme.
Pour un professionnel de la profession, cette phrase suffit largement en effet – et d'ailleurs il n'en a pas besoin car il travaille déjà comme ça.
Mais pour tous ceux qui ajustent leur CSS avec le bloc-notes Windows ou, pire encore, Word ? Qui patientent trente secondes (mini) après chaque changement parce que le serveur est chargé ce soir-là ? Qui perdent un article pour des raisons mystérieuses ?
J'ai voulu m'adresser à ceux-là, et je n'avais pas bien mesuré l'ampleur du domaine à couvrir : un peu d'éditeur, un peu de CSS, un peu de HTML en général, un peu de HTML OverBlog, un peu de méthode de travail, etc. Pas simple, je ne pouvais rien supposer connu.
Si cette série a rendu service à au moins un lecteur, je n'aurais pas tout à fait perdu ma peine. Espérons…
Toujours aussi recommandables :
![[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)