SpipKits

Présentation

Autant il est simple d’utiliser Spip pour produire et gérer du contenu, autant la problématique de la forme du site présente des difficultés. Des solutions qui se proposent, aucune n’est pleinement satisfaisante et toutes demandent à être adaptées afin de convenir à un projet original. Bienvenue dans les marais de l’html et la jungle des css !

Ne pourrait-on pas concevoir un système plus abordable, dont l’utilisation permette d’apprendre facilement les concepts nécessaires, et qui permette de mettre rapidement en place un site en s’appuyant sur une structure modulaire et relativement standardisée ? Voilà ce qu’est le projet spipKits, qui permettrait de mettre spip à la portée d’un encore plus grand nombre.

Squelettes

Lorsque l’on veut développer un site sous Spip, on doit faire face à deux options :

-  Utiliser tels quels les squelettes de la distribution ou d’autres jeux disponibles dans la communauté, en tentant d’adapter les styles qu’ils utilisent. Avantage, la simplicité, inconvénient, le manque d’originalité du site et une exploitation pas forcément optimale de sa structure éditoriale.
-  Développer ses propres squelettes ex-nihilo. Malheureusement, la récompense de pouvoir faire ce qu’on veut se gagne chèrement en heures à faire et défaire boucles et styles, et demande rapidement un savoir-faire quasiment professionnel. Mais c’est la seule façon de créer une réelle osmose entre forme et contenu.

Dans la réalité, on optera souvent pour une solution hybride, et l’étude des squelettes existants nourrira sa propre création. Mais celle-ci ne se fait pas sans mal : si les standards du W3C existent et que le langage des boucles spipiennes s’enrichit en permanence, leur exploitation est laissée aux expériences de chacun. De nombreuses questions se posent au développeur curieux, auxquelles il a bien du mal à trouver des réponses rationnelles ou justifiées : class ou id, règles d’accessibilité, etc. Aussi, chacun propose-t-il ses propres approches, ce qui induit encore plus de confusion dans la recherche des solutions ou principes à adopter.

L’adaptation des squelettes, si elle est une source d’apprentissage renouvelée, est également celle de beaucoup de nouvelles questions, qui succèdent à celles (et bien entendu, à leurs réponses) de leur créateur. Fort heureusement, c’est un point de vue pris en compte par la plupart de ceux qui partagent leur travail, aussi tentent-ils de le rendre accessible en le commentant plus ou moins abondamment. Mais si l’intention est louable, il faut bien avouer que sa nécessité passe souvent après d’autres priorités.

Pourtant, et même dans ses besoins spécifiques, tout développeur se retrouve face à des problématiques communes, et le fait qu’à chacune il existe de nombreuses solutions n’exclut pas le fait qu’il y en ait parmi elles de meilleures. Celles-ci, adoptées à coup sûr, garantissent la qualité d’un développement en écartant au passage autant de questionnements parasites, laissant d’autant plus de place à la création. Un ensemble de conventions, illustrant quelques principes clairs, accompagné des ressources nécessaires, fournirait un outil précieux à l’apprenti spipmaster et permettrait de lui faire gagner beaucoup de temps et d’énergie, de même que la possibilité de partager aisément son travail avec les autres. Voilà l’idée qui se trouve à la base du projet spipKits.

Validité

Dans le remarquable travail accompli par les développeurs de Spip (qu’Ils soient loués éternellement !), on peut noter leurs efforts pour respecter les principes de la conformité aux recommandations du W3C, et leur souci de produire des documents attentifs à ceux de l’accessibilité aux personnes handicapées. On ne peut que les suivre dans cette voie qui non seulement offre partiellement des réponses aux besoins évoqués au paragraphe précédent, mais participe à l’émergence d’une nouvelle façon d’envisager l’information, qui bouleversera à l’avenir notre façon de concevoir tout document. Si cette révolution se fait discrète, elle est néanmoins présente, basée sur l’idée d’un flux de contenu, l’information elle-même, se coulant dans une structure « intelligente », c’est à dire en mesure de traiter, voire de s’adapter à ce contenu. On peut ainsi évoquer le XML et les feuilles de styles, mais également la nature conceptuelle du traitement de texte d’Apple, Pages ou encore la convergence numérique qui fit les beaux jours de Mr Messier.

Ce modèle, qui vise donc non à séparer, mais à penser différemment conteneur et contenant, mettra encore quelques années à faire son chemin dans les consciences et dans les outils, et ceux qui tentent de l’exploiter dès à présent sont en quelque sorte les pionniers d’une nouvelle écriture, annonçant le langage de notre communication avec la machine. Ses bases philosophiques sont encore floues, et ses champs d’application encore à défricher. Il n’en reste pas moins que concevoir l’architecture d’une page pour qu’elle reste lisible même sans styles ou bien utiliser de balises signifiantes telles que ou encore une classe .date revient à prendre des options sur l’avenir tout en s’assurant d’une approche correcte.

Les spipKits non seulement la respecteront, mais chercheront à la prolonger en distinguant une coquille, dessinant la structure physique et logique de la page, des noix, pages conçues à partir de cette coquille, et des noisettes (ainsi nommées en clin d’œil à l’écureuil de Spip, mais évoquant également les javabeans, fragments de code autonomes.), zones de contenu qui viendront s’y insérer de façon modulaire. Utiliser un spipKit reviendra donc à choisir ou écrire un squelette de fond en enrichissant une structure-type, puis y inclure des panneaux indépendants dont les boucles généreront le contenu dynamique, puis à habiller le tout en jouant sur les feuilles de style correspondantes. Quelques conventions de construction, de nommage des balises et de documentation de l’organisation devraient pouvoir simplifier au maximum l’opération, tout au moins en ce qui concerne la mise en place.

Principes

Le principe d’un spipKit est le suivant :

Une structure standardisée, comprenant :

• une coquille, squelette structurel du site.
• des inclure, qui viendront remplir celle-ci pour constituer les pages.
• des feuilles de style permettant d’appliquer une charte graphique interchangeable.

Le code s’appuie sur des éléments modulaires afin de réduire au maximum le temps de développement et les difficultés d’adaptation. Il est valide, commenté et respecte les principes de l’accessibilité.

Les fichiers et le spipKit lui-même sont clairement documentés, dans un souci pédagogique, et accompagnés d’un texte descriptif. Les zones facilement modifiables sont indiquées en tant que telles afin de guider le néophyte dans sa personnalisation.

La distribution est open source, évidemment, en accord avec tous les principes de spip & co. Les spipKits sont intentionnellement un moyen de promouvoir ces idées.

Les spipKits s’installent facilement en complétant l’installation de base d’un site Spip. Les nouveaux squelettes reprennent donc dans la mesure du possible les pages de la distribution (dossier dist) mais sont installées dans un dossier à part (par défaut bones).

Coquille

La coquille, accompagnée de sa feuille de style indépendante, organise l’architecture générale des pages du site, et c’est à partir d’elle que ces dernières sont générées, puis adaptées. Bien entendu, la coquille n’est pas utilisé seule : elle se fond dans les pages html à qui elle donne forme. Par convention, les <div></div>

de la coquille sont définis et stylés par des classes ou des id anglophones, et standard : body, #header, #top, #left, #center, #right, #bottom, #footer, #content, dans le fichier (nom_du_spipkit)coquille.css.

Noix

À partir des coquilles sont conçues des pages en leur incluant un contenu, les noix, qui font l’articulation entre la coquille et les noisettes. Ces pages reprennent le nommage de la distribution de spip (fichiers rien), ou sont conçues indépendamment pour répondre à un besoin particulier (fichiers un). En-dehors des styles de coquille, leur habillage se trouve dans un fichier (nom_du_spipkit)styles.css, facilement modifiable. Les noms des styles sont plus libres, pouvant par exemple être dans la langue des squelettes. Un minimum de normalisation logique serait cependant la bienvenue, pour garantir l’interchangeabilité des spipkits dans la mesure du possible. À étudier.

Noisettes

Ces fichiers sont destinés à être intégrés dans les zones des coquilles par des INCLURE(1xxx.php3)[id_argument]. Ils sont également stylés dans (nom_du_spipkit)styles.css afin de conserver la logique de la charte graphique. Ils sont conçus pour être facilement portables d’une page à l’autre et d’un spipKit à l’autre, c’est à dire en répondant également au système de conventions (dimensions, nom des styles…).

Styles

Les feuilles de style de par défaut de spip étant un peu touffues (pour les besoins de la démonstration, certainement), en tout cas très complètes, elles seront aisément remplacées par celles du spipKit. Néanmoins, la feuille spip_styles.css, concernant les enrichissement typographiques du texte des articles, devra être recopiée dans /bones/css et adaptée.

Le choix idéal aurait bien sûr de pouvoir adapter de la même façon les autres feuilles de style de la distribution, mais elles apparaissent trop spécifiques au site par défaut. Néanmoins, l’objectif doit être une convergence entre les feuilles dist et celles des spipKits. À terme, et si le projet se développe bien, la distribution pourrait être conformée aux critères spipKits, ce qui répondrait aux souhaits apparemment exprimé par les développeurs d’une gestion plus aisée des squelettes.

Conventions

Malgré une forme affirmative, il ne s’agit là que de pistes à explorer et à remettre en cause jusqu’à une solution satisfaisante. Elles illustrent cependant bien les principes exposés ci-dessus.

Organisation des fichiers

Afin de faciliter la portabilité des spipKits et modifier au minimum le dossier originel de spip, leurs fichiers seront placés dans un dossier indépendant, au même niveau que l’installation de spip, donc dans un dossier commun : le dossier spipKit. C’est le dossier bones qui sera indiqué comme $DOSSIER_SQUELETTES lors de l’installation.

De façon standard et pour des raisons de lisibilité, le dossier bones comportera des sous-dossiers css, scripts, etc. selon besoins.

Types de fichiers

Pour distinguer les différents types d’éléments et qu’ils se trient automatiquement dans le dossier spipKit, ils seront précédés ou non d’un chiffre, selon les définitions suivantes :

-  Les fichiers rien xx.html, xx.css... Ce sont les fichiers qui portent les noms de ceux du dossier dist de la distribution de spip : sommaire.html, article.html, etc. Leur particularité étant de ne pas avoir besoin de gérer leur lanceur .php3, ils échappent à la délicate installation des fichiers zero.

-  Les fichiers zero 0xx.html, 0xx.php3... Ces fichiers sont ceux des pages complètes non prévues dans la distribution, ou portant simplement un autre nom : les noix. Exemple : l’aggrégateur de news Sedna ou un squelette d’album photo. Comme leur « lanceur », le fichier .php3 doit se trouver dans le dossier spip, leur nom commence par un 0 pour qu’ils apparaissent en tête de liste. Sauf indication contraire, ces fichiers 0nom.php3 sont les seuls à copier à la racine du dossier spip. Les fichiers 0xx.html seront lancés du dossier bones, et peuvent donc y rester

-  Les fichiers un 1xx.html, 1xx.php3... Ce sont ceux des inclure, alias noisettes. Généralement, ce sont des boucles spécifiques qui peuvent être appelées contextuellement. Ces fichiers répondent à des conventions précises destinées à faciliter leur intégration dans les coquilles et correspondre à la logique des styles, et doivent être validés pour obtenir ce label. Exemple : une liste d’articles stylée, un panneau présentant un site syndiqué choisi au hasard de la rubrique. Leur lanceur .php3 peut se trouver indifféremment dans le dossier spip ou le dossier bones (par défaut).

-  Les fichiers trois (optionnels) 2xx.html, 2xx.php3, 2xx.css, dossier 2menu... Le label 2 sert à regrouper des éléments disparates. Le cas typique est l’intégration d’un menu déroulant, dont les éléments pourront être rangés dans un sous-dossier 2menu, apparaissant à côté de 2menu.html dans le dossier bones. Le fait de nommer ces fichiers par 2 peut être une façon de distinguer les inclure de source externe, en conservant dans la mesure du possible leur cohérence. Contrairement aux trois précédents, ils peuvent déroger aux règles et / ou styles du spipKit en n’étant que partiellement conformés.

-  Les fichiers quatre (encore plus optionnels) reprennent le principe des précédents, mais sont des extensions qui ne concernent en rien spip.

Le principe peut bien sûr être décliné (cinq, fichiers en test, par exemple) et affiné selon les besoins.

Résumé

D’abord, se bricoler un bon design de base, bien fluide.

Y prévoir l’inclusion de modules de format(s) standard répondant à des spécifications établies.

Créer une feuille de style comportant définition structurelle des modules et sélecteurs permettant d’y appuyer une charte graphique.

Torcher une page type. La décliner selon usages en jouant sur les modules inclus et les boucles d’appel.

La suite, c’est SpipKits2, et c’est déjà sorti en salles.

NOTE : la faisabilité, à estimer par les spécialistes, est fonction des limites de la standardisation.