Wikini

MattRixxTagHide

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-3-85-211-2.compute-1.amazonaws.com

Création du tag "texte caché"


J'ai fait une modification dans /formatters/wakka.php qui permet grace à ~~ de cacher du texte. Ce n'est pas un commentaire, le texte a juste une classe css .hide (.hide { visibility: hidden; }). Si on regarde le source html, on voit <span class="hide">le texte</span>, mais avec cette classe CSS, le texte n'est pas visible...

dans /formatters/wakka.php:





Pour compléter, une utilisation typique, qui est faite dans http://www.mattlab.com/artwork/ est la création de mots-clés invisibles qui permettent de "marquer" des pages pour qu'elles soient automatiquement référencées dans des catégories. Les pages-catégorie sont gérée automatiquement en listant juste les pages de cette catégorie, par ActionBacklinks.
En fait, ce mot-clé peut très bien être visible, mais le "tag" ~~ est très intéressant dans ce contexte.
Merci à MattRixx ! -- JexOm.

Merci pour cette précision -- MattRixx

Je trouve l'idée intéressante, mais pourquoi n'avoir pas choisi de mettre le texte dans un commentaire HTML <!-- xxxx --> (le résultat aurrait été identique) ; l'utilisation d'une classe de style fait que certains navigateurs vont afficher cette page (Lynx, lecteurs braille, etc.) ? -- CharlesNepote

Parce que je voulais que ce texte soit pris en compte par WiKini étant donné que je m'en sers pour faire un système de navigation par catégorie. Par exemple à la fin d'une page, je met en mot en mode caché, ce mot correspond à une page Wiki qui affichera les pages grace à une backlinks. Donc moi je pensais que WiKini, dans ce cas précis, n'aurait pas reconnu le lien... je me trompe?... à y réfléchir, étant donné que la fonction qui recherche et créé les liens dans la table links le fait sur le texte saisi et non sur le texte affiché... je me dis que je me trompe...
D'un autre coté, cette classe .hide permet au webmaster de faire ce qu'il veut de ce texte. Par exemple s'il veut tout de même l'afficher d'une certaine manière...
En ce qui concerne Lynx et les lecteurs braille, étant donné qu'il y a des images et des photos dans le contenu du site, je me ferme la porte a ces navigateurs "non standards" et je n'en tiens donc pas compte. -- MattRixx
J'ai vu sur le wiki plusieurs pages qui comportait un mot wiki du genre PageSurveilleParCharlesNepote ou quelque chose y ressemblant. Pour le lecteur, ca n'est pas interressant du tout et je trouve meme que ca gache la lecture si c'est une oeuvre artistique, ce qui est le cas sur mon site. Le newbie se demandera d'ailleurs ce que c'est que ce mot bizarre a la fin du texte.
Il ne faut pas penser un wiki comme un outil universellement connu. Je veux dire par là que mon site est principalement ouvert à des personnes ne connaissant même pas le mot wiki et à qui il faut que j'apprenne les rudiments du wiki. Heureusement la doc de wikini est très bien faites mais peu de monde lit les docs c'est bien connu. Donc les personnes veulent savoir le minimum, ce qui va leur servir: comment créer une page perso puis comment créer des pages liées à cette page perso et enfin, dans le cas de mon site, comment catalogué ses pages. Ensuite, il faut que ce soit le plus transparent possible. Et mettre un mot bizarre à la fin d'un texte, ca peut dérouter les simples visiteurs du site qui n'ont même pas appris ces bases. Surtout quand c'est un mot uniquement destiné a créer des catégories dans le site. -- MattRixx

Note a posteriori : quitte à employer un style je pense qu'il vaut mieux employer le style "display: none" (pas de boite créée) plutôt que "visibility: hidden" (ce dernier est invisible mais influence les autres contenus en occupant de la place (même si la place est vide)) :
-- CharlesNepote


[J'inclu ici-même la suggestion de Gniarf qui ressort du même débat.)

Inclure des commentaires au sein du "source" des pages d'un Wiki

ça ne doit pas être très sorcier de proposer des commentaires dans le code source d'une page d'un Wiki, comme des commentaires en C par exemple, et que cette section de texte ne soit pas rendu lors de l'affichage. comme un /* ceci est un exemple de commentaire */ qui n'apparaitrait que dans le source de la page.

Par rapport aux classiques mais temporaires notes qu'on ajoute quand on valide une page, ces commentaires résisteront aux changements de versions des pages, et pourraient servir pour avertir les gentils utilisateurs-éditeurs de ne pas toucher certaines portions de la page, de ne pas utiliser la syntaxe machin-bidule toute cassée, de donner une raison un peu plus longue que 3 mots de l'édition ou la correction d'une page, ou d'autres détails techniques ne concernant pas directement les simples visiteurs.

à part cette syntaxe toute simple, on peut envisager pour ici un {{Commentaires texte="Gérard a déménagé, j'ai corrigé son numéro de tel"}}, et pour un PhpWiki (pour comparaison) un plug in du genre <?plugin Commentaires texte="blablabla"?>

(ceci n'a pas de rapport avec la section "commentaires" de la page que vous pouvez voir en bas de la page)
-- Gniarf aka Olivier Souiry

Je vote pour, dans la mesure où ça éviterait de mettre ces notes dans le corps même du contenu utile. Ça permettrait de laisser des messages aux rédacteurs sans que les lecteurs ne les voient dans la mesure où ils sont inutiles pour eux. -- LiNuCe aka LuCieN

J'ai fait une modification de wakka.php (le formatters) qui permet grace à ~~ de cacher du texte. C'est pas un commentaire, le texte a juste une classe css .hide (.hide { visibility: hidden; }). Si on regarde le source de la page html, le texte apparait, mais pas à l'écran... -- MattRixx (.artWork) 10/01/04


Synthèse des propositions et solutions

Avant de parler de solutions, je pense tout d'abord qu'il y a deux besoins fonctionnellement différents.
1. Gniarf propose un commentaire caché quoi qu'il arrive, à des fins d'animation éditoriale, uniquement visible lors de l'édition.
2. MattRixx propose un marqueur servant à différencier des MotWiki servant à la classification via les rétroliens (en les rendant, par exemple, invisibles dans les navigateurs modernes, mais ce n'est pas obligé)
On voit bien que les besoins ne sont pas les mêmes.
Questions :
Même si nous ne sommes pas fixés sur les besoins voyons les solutions, dont le nombre est limité.

Solutions (appel)




Solutions (code HTML)




-- CharlesNepote
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]