Ressource

Le raccourci « ressource »

Avec cette proposition de raccourci nous voulons proposer une nouvelle approche de l’insertion de ressources dans un document. Avec l’objectif d’offrir au rédacteur la simplicité du Web d’antan, qu’on a un peu fini par perdre de vue.

Qu’est-ce qui nous embête actuellement

On sait que HTML permet très simplement d’insérer une image dans une page ; on écrit un appel sous la forme <img src=http://serveur.tld/image.jpg> — et le navigateur se débrouille pour l’afficher.

Hélas cette simplicité de 1995 s’est transformée, sous l’ajout de couches successives de complications dues à de bonnes et moins bonnes raisons. La syntaxe nécessaire s’est trouvée alourdie, quand elle n’est pas devenue totalement impossibles à mémoriser (pour la vidéo par exemple). L’utilisation de bases de données relationnelles pour stocker des fichiers dans les logiciels de publication n’a rien arrangé, aboutissant à substituer aux URI des identifiants numériques.

Dès lors que je souhaite intégrer deux images et une vidéo dans un texte, je dois suivre, dans le bon ordre, une procédure stricte :
— charger les documents (ou indiquer leur URL dans le cadre de document « distant »)
— noter le numéro que SPIP a attribué à chaque document
— saisir dans la boîte des documents les attributs titre et descriptif
— insérer des raccourcis du type <doc12> <img21> <emb35> dans mon texte.

Evidemment, si je recopie ce texte sur un autre site (par exemple, de mon site de tests vers mon site de prod), il me faut répéter la procédure, et les numéros seront différents ; un copier-coller, opération qui devrait être élémentaire, ne marche pas.

D’autres questions se posent, par exemple si j’utilise deux fois le même document mais en en modifiant le titre : faut-il le téléverser deux fois pour obtenir deux numéros différents ?

Proposition : le raccourci <ressource>

C’est l’URL de la ressource à intégrer qui sert de base, de la façon la plus simple qui soit ; on l’encadre avec des chevrons pour délimiter le début et la fin du raccourci. Une ressource, à la base, c’est un lien, que SPIP devra enrichir.

L’URL peut être :
— absolue : <http://www.spip.net/squelettes/img/spip.png>
— relative : <squelettes/img/spip.png>
— ou se référer à une médiathèque : <image.jpg>

L’affichage souhaité est défini comme « le meilleur rendu possible de la ressource dans le cadre de la page ». On verra au cas par cas ce que ça implique.

Des options peuvent être passées au raccourci, par exemple pour préciser des informations :
<http://www.spip.net/squelettes/img/spip.png alt=logo>
pour spécifier des actions de type « réduction d’image » :
<http://www.spip.net/squelettes/img/spip.png width=100>
pour préciser un mode d’affichage :
<http://www.spip.net/squelettes/img/spip.png left class=avec_bordure modele=fullscreen>

Ces options sont séparées les unes des autres par de simples espaces, comme en HTML (et non pas avec des pipes comme en SPIP). Si l’on veut des espaces dans l’attribut alt, il faut utiliser des guillemets :
<http://www.spip.net/squelettes/img/spip.png alt="Logo de SPIP">

Implémentation

L’implémentation de ce raccourci n’est pas figée ; au contraire elle est ouverte. Si on trouve une façon d’obtenir un meilleur rendu, on l’adopte sans hésiter.

Ainsi par exemple, un raccourci <photo_montagne.jpg> donnerait, dans le cadre d’une page Web traditionnelle, une version de la photo réduite à 500px de large, avec éventuellement, si la photo est plus large que ces 500px, un lien permettant de la voir en plus grand (ou de la télécharger, ou de l’afficher dans une galerie, etc.)

Mais la même photo, dans le cadre d’une sortie pour impression, devrait certainement être mise à la largeur du texte, avec une définition plus élevée que la résolution écran de base. Et si on vise plutôt un mode léger, une image plus réduite ou de moindre qualité pourrait être générée, etc. Le raccourci ne précise pas cela, c’est seulement l’implémentation qui le fait, et qui peut donc changer selon le cadre de sortie (ainsi que les préférences du webmestre et les plugins installés sur le site, qui étendent les possibilités de ce raccourci).

Formats

On pratique au maximum l’inclusion (« embed ») des documents, dans la mesure du raisonnable.

Par exemple, s’il s’agit d’un son ou d’une vidéo, on mettra un player (ou en tout cas le minimum nécessaire pour pouvoir brancher un player dessus), et dans la mesure du possible des éléments graphiques (frame extraite) ou textuels (tags ID3) permettant au lecteur de savoir ce que contient ce média.

Autre exemple, si la ressource est un fichier PDF, on peut essayer l’heuristique suivante :
— Si on ne sait rien du contenu du PDF, afficher un lien vers le document.
— Si on peut en extraire la première page sous forme d’une image, en faire une vignette d’une largeur « raisonnable » permettant de voir de quoi il s’agit ; un lien sur l’icone conduisant évidemment à l’affichage (ou téléchargement) du document complet, ou à sa visualisation dans un player de type pdf.js
— Si on peut en extraire du contenu textuel, afficher un extrait de taille raisonnable, et un lien.
etc.

De même, si la ressource est un fichier de bureautique (RTF, texte LibreOffice, etc) on peut essayer d’en afficher un extrait (si on dispose d’un convertisseur) ; si c’est un tableur (CSV, Excel…), on essaiera d’afficher un nombre raisonnable de colonnes et de lignes (avec des liens pour afficher ou télécharger le doc complet).

Généraliser oEmbed

Ce raccourci fait appel au maximum aux fonctions (parfois sous forme de plugins) d’embed distant de type oEmbed, autoEmbed, etc. De manière à ce qu’on puisse insérer une photo en donnant l’URL de la page correspondante :
<http://www.flickr.com/photos/fil-rezo-net/5897146332/>

On essaiera au maximum d’activer ces techniques d’embed sur tous les sites et pas seulement sur les « grandes marques » du Web 2.0 : aucune raison qu’on ait quelque chose de moins bien pour nos propres productions que ce qu’on accorde à FlickR. Il faut donc éviter les listes blanches, et favoriser l’« autodécouverte ».

Portabilité

Si l’on recopie un texte contenant ces raccourcis, d’un site A ayant tous les plugins permettant l’embed etc, vers un site B moins bien configuré ou moins bien doté, on ne doit jamais perdre la fonctionnalité de base consistant à pouvoir visualiser la ressource : au pire, donc, on offrira toujours un lien vers le document cible.

A ce propos je me demande si, en l’absence de plugin ressource, SPIP ne devrait pas tout simplement afficher le raccourci en htmlspecialchars, avec un lien banal vers le document (plutôt que passer le raccourci tel quel, provoquant une faute de HTML). Question pas très importante mais qu’on devrait régler maintenant.

Ce raccourci permet aussi d’échanger des articles par mail (ou via des gestionnaires de contenu de type GIT ou SVN) ; qu’il s’agisse de travailler à plusieurs sur un document multimédia, ou de faire un suivi de versions et des sauvegardes d’un site, revenir à un adressage par URL des documents devrait largement faciliter les choses.

Compatibilité

Ce raccourci ne peut pas référencer de fichier local sans extension : il comporte donc soit toujours soit un point (.jpg), soit un "http://". A moins d’un oubli de ma part ou d’une future évolution des normes, il ne devrait donc pas y avoir de problème de compatibilité avec HTML.

Cas de la médiathèque

Lorsqu’on référence un document dans la médiathèque, il faut savoir de quoi on parle : <fichier.rtf> peut ainsi référencer :
— ce fichier dans le répertoire IMG/rtf/ ;
— ce fichier tel que décrit dans la table spip_documents ;
— ce fichier dans un autre répertoire « de base ».

Le raccourci est agnostique à ce propos, c’est au webmestre de décider de la manière dont il gère les « documents locaux » du site. L’implémentation de base dans SPIP se fera selon spip_documents, puis de IMG/rtf/ ; mais si on se dote d’une autre solution de gestion de médias (par exemple un upload sur un serveur de médias dédié), il faut qu’il soit simple d’implémenter la recherche du document sur ce serveur.

Utilisé en tant que librairie de fonctions

Le plugin "ressource" est utilisé par le plugin "rss_articles" pour récupérer les documents associés à un flux rss. Pour cela, on a pas besoin des modèles. Or le traitement des modèles par ressource peut générer des warning PHP s’il y a des chaînes par exemple du type <truc@troc.trac> dans les champs #TEXTE des articles.
La constante _RESSOURCE_LIBRAIRIE_SEULEMENT sert alors à indiquer qu’on veut juste bénéficier de la définition des fonctions mais pas de l’utilisation dans les modèles.

define ('_RESSOURCE_LIBRAIRIE_SEULEMENT', true);

TODO

ce qui me manque peut-être à cette étape, c’est des modèles de rendu un peu sympa, et savoir quel type de HTML/CSS on propose pour divers cas classiques (grande image, petite image, vidéo, PDF, RTF, page web…).