[spip-dev] divers backport du lab

Coucou,

SPIP connait maintenant les "urls propres" de SPIP-lab ; cf.
http://lab.spip.net/spikini/UrlsPropres

Seules différences : la variable à régler dans mes_options.php3 (ou
mes_fonctions.php3) s'appelle $type_urls='propres', et pas $urls='propres';
et le fichier .htaccess est livré en standard sous le nom
htaccess-propres.txt (à titre d'exemple).

Autres fonctions du lab réintégrées :
- les <div> pour les documents (à la place d'une grosse table)
- <strong class="spip"> à la place de <b class="spip">

-- Fil

Autres fonctions du lab réintégrées :
- les <div> pour les documents (à la place d'une grosse table)
- <strong class="spip"> à la place de <b class="spip">

voilà qui fera plaisir aux inconditionnels des standarts et de l'accessibilité

Salut,

Dans l'exemple de code suivant (généré par une balise <doc'x'|left>) :

<div class='spip_documents' style='float: left; text-align: center;'>
<img src='IMG/jpg/logo_spip.jpg' border='0' width='105' height='92' alt="SPIP" title="SPIP" /><div class='spip_doc_titre'><strong>SPIP</strong></div><div class='spip_doc_descriptif'>Système de Publication
<br />pour l&#8217;Internet</div></div>

le titre et le descriptif sont gérés respectivement par .spip_doc_titre {}(ou plutôt .spip_doc_titre strong {}) et spip_doc_descriptif.

Si on ne veut pas de style particulier pour le titre, la solution
.spip_doc_titre strong { font-weight: 0; } n'est pas vraiment des plus logiques (même si cela fonctionne très bien).

Ne vaut-il mieux pas se dispenser alors des balises <strong> et rajouter simplement dans spip_style.css : .spip_doc_titre { font-weight: bold; } ?

Qu'en pensez-vous ?

#Olivier.

Note : le contrôle du style du descriptif est très appréciable :wink: !

Fil wrote:

moi je voterai plutot pour quelquechose comme
<div class="spip_documents docfloatleft">
<img src='IMG/jpg/logo_spip.jpg' width='105' height='92' alt="SPIP" />
<p class='spip_doc_titre'>SPIP</p>
<p class='spip_doc_descriptif'>Système de Publication<br />pour l&#8217;Internet</p>
</div>

explications:
les style inline sont à éviter pour des questions d'accessibilité (l'utilisateur n'as pas la main mise dessus) et non modifiable donc rien n'empeche de mettre le text-align:center dans la class .spip_documents .

Pour le float:left ou float right il vaut mieux créer deux style supplémentaires un .docfloatleft et .docfloatright qui sont appliqué en fonction de la balise spip choisi et qui viennent s'ajouter à la class spip_documents (ne pas oublier que l'attribut class supporte plusieurs valeurs qui s'ajoute les unes au autres), cela permet encore une fois plus de liberté au webmaster et surtout permettra de redefinir ces class en cas de css pour le print ou les éléments en float genere des bugs.

Sur l'image le border ne sert à rien il peut etre défini dans les css, et le title ne sert à rien non plus, si l'image est un lien c'est le alt qui indique la destination du lien. Pour des questions d'accessibilité le alt doit etre limité à 60 characteres et si l'image est un lien 80

Enfin l'utilisation de paragraphe pour le titre et le descriptif me semble plus sémantiquement correcte mais là ca n'engage que moi.

Quand au strong il ne sert effectivement à rien mieux vaut utiliser le css pour definir la font à bold
(si l'utilisateur veut vraiement du strong il pourra le rajouter avec la propriété content:before et after en css3)

moi je voterai plutot pour quelquechose comme
<div class="spip_documents docfloatleft">
<img src='IMG/jpg/logo_spip.jpg' width='105' height='92' alt="SPIP" />
<p class='spip_doc_titre'>SPIP</p>
<p class='spip_doc_descriptif'>Système de Publication<br />pour
l&#8217;Internet</p>
</div>

Non, le problème à tout déporter dans une feuille de style externe est
qu'un webmestre qui partirait d'une feuille de style vierge n'aurait
plus aucune formatage dans l'affichage des documents. Il faut alors
redéfinir quinze styles différents pour arriver à un affichage
"correct". Bonjour la courbe d'apprentissage.

Or quand on écrit "<doc183|left>" dans un article, c'est bien qu'on veut
aligner l'affichage à gauche, par définition. Il ne s'agit pas d'un
choix d'habillage laissé au webmestre. D'où le "style='float: left;'"
dans la balise.

Quand au strong il ne sert effectivement à rien

Heu, c'est rigolo ça. On n'arrête pas de nous dire qu'il faut utiliser
des <strong> pour la "sémantique", et après on nous dit que ça ne sert à
rien... Faut savoir. On ne garde que les balises <div> et <p> du HTML et
on met tout dans les feuilles de style ?

Là il me semble bien que le titre d'un document doit être "mis en avant"
par rapport au descriptif, ce qui justifie bien le <strong>. Non ?

(note en passant : ç'aurait été mieux de discuter le truc à l'époque sur
spip-lab plutôt que d'attendre qu'il soit backporté...)

a+

Antoine.

> Quand au strong il ne sert effectivement à rien

Heu, c'est rigolo ça. On n'arrête pas de nous dire qu'il faut utiliser
des <strong> pour la "sémantique", et après on nous dit que ça ne sert à
rien... Faut savoir. On ne garde que les balises <div> et <p> du HTML et
on met tout dans les feuilles de style ?

Pour les titres d'images ou de documents pourquoi ne pas utiliser <h4> ou
<h5> ? N'est-ce pas plus sémantique ? Et en plus ça insère du bold au
formatage.

Pierre

Ce ne sont que des remarques pour faire avancer le schmilblik, le code généré est deja beaucoup mieux que ce qu'il y avait avant. Je veux bien me pencher sur le code si il y a besoin de retoucher, histoire que vous n'ayez pas tout le boulot comme d'hab

Non, le problème à tout déporter dans une feuille de style externe est
qu'un webmestre qui partirait d'une feuille de style vierge n'aurait
plus aucune formatage dans l'affichage des documents. Il faut alors
redéfinir quinze styles différents pour arriver à un affichage
"correct". Bonjour la courbe d'apprentissage.

Ok pour l'argument meme si pense que dans le fond arrivé à un moment ou a un autre la compatibilité avec les version précédente devra etre rompu et il me semble meme qu'elle l'est déjà plus ou moins ne serait ce qu'avec l'ajout des css pour la gestion des formulaires accessible comme sur le lab

Or quand on écrit "<doc183|left>" dans un article, c'est bien qu'on veut
aligner l'affichage à gauche, par définition. Il ne s'agit pas d'un
choix d'habillage laissé au webmestre. D'où le "style='float: left;'"
dans la balise.

Reste qu'en print des doc flottant bonjour la merdasse, il y a bien l'attribut !important dans les css pour contrer cela mais je crois qu'il n'est pas suporté de la meme maniere partout. Par contre pour le text-align je pense vraiment pas qu'il soit necessaire en dur de meme que le border sur l'image

Là il me semble bien que le titre d'un document doit être "mis en avant"
par rapport au descriptif, ce qui justifie bien le <strong>. Non ?

Que le raccourci spip qui generait du bold genere desormais du strong c'est un plus indéniable mais décidé pour tout le monde sans changement possible que le titre du document doit sémantiquement etre mis en avant cela ne me semble pas correcte (la solution de mettre de h2, h3,etc à la place encore moins). Et comme expliqué celui qui veux vraiment du strong à la place n'aura aucun mal à en avoir contrairement à l'inverse

(note en passant : ç'aurait été mieux de discuter le truc à l'époque sur
spip-lab plutôt que d'attendre qu'il soit backporté...)

Désolé j'avais pas vu sur le lab le code généré

<quote who='aurelien levy' when='18/09/2004 12:59'>

Sur l'image le border ne sert à rien il peut etre défini dans les css, et le title ne sert à rien non plus, si l'image est un lien c'est le alt qui indique la destination du lien. Pour des questions d'accessibilité le alt doit etre limité à 60 characteres et si l'image est un lien 80

Aurélien,

Une bonne fois pour toutes est-ce qu'il serait possible que l'on se départisse de ce dogmatisme des 60 et 80 caractères ? Ce n'est pas une règle que j'applique, même si je fais mon possible pour être le plus accessble possible.

Une personne qui a une mauvaise vue et qui a réglé les info-bulles avec des grosses polices sera-t-elle aussi ravie d'une limite qui lui fera des énormes info-bulles ?

Tous les navigateurs les gèrent-ils de la même manière ? Non ! Il n'est dit nulle part qu'on doive afficher une info-bulle en cas de ALT, et d'ailleurs Mozilla ne le fait pas, alors qu'ne revanche il gère les TITE sous forme d'infos-bulles.

Comme d'habitude, soyons pragmatiques et pas dogmatiques. Si on doit continuer la discussion, je te propose qu'on le fasse sur spip-lab.

Quand au strong il ne sert effectivement à rien mieux vaut utiliser le css pour definir la font à bold
(si l'utilisateur veut vraiement du strong il pourra le rajouter avec la propriété content:before et after en css3)

+1 sur les arguments d'Antoine : trop de boulot pour un débutant, même si l'intention est bonne.

Une bonne fois pour toutes est-ce qu'il serait possible que l'on se départisse de ce dogmatisme des 60 et 80 caractères ? Ce n'est pas une règle que j'applique, même si je fais mon possible pour être le plus accessble possible.

Libre à toi de ne pas l'appliquer mais c'est pourtant une regle importante d'accessibilité pour les raisons que j'ai deja citée (et preuve si l'en est, l'existence de longdesc si la description est trop longue)

Une personne qui a une mauvaise vue et qui a réglé les info-bulles avec des grosses polices sera-t-elle aussi ravie d'une limite qui lui fera des énormes info-bulles ?

La taille de polices des info bulles en particulier n'est pas réglable c'est une partie de l'ecran qui peut etre zoomé

Tous les navigateurs les gèrent-ils de la même manière ? Non ! Il n'est dit nulle part qu'on doive afficher une info-bulle en cas de ALT, et d'ailleurs Mozilla ne le fait pas, alors qu'ne revanche il gère les TITE sous forme d'infos-bulles.

Le alt ne sert pas à afficher une infobulle (il le fait mais effectivement rien n'y oblige comme tu le dit) il sert à donner de l'info pour les personnes qui utilise des synthese vocal et des plages brailles ou qui désactive les images. Maintenant c'est sûr le but recherché c'est d'avoir à tout prix une infobulle là le alt + title sont nécessaire

Comme d'habitude, soyons pragmatiques et pas dogmatiques. Si on doit continuer la discussion, je te propose qu'on le fasse sur spip-lab.

ok mais où précisement

(Re)

Antoine wrote:

Non, le problème à tout déporter dans une feuille de style externe est
qu'un webmestre qui partirait d'une feuille de style vierge n'aurait
plus aucune formatage dans l'affichage des documents. Il faut alors
redéfinir quinze styles différents pour arriver à un affichage
"correct". Bonjour la courbe d'apprentissage.

Oui, c'est juste.

(note en passant : ç'aurait été mieux de discuter le truc à l'époque sur
spip-lab plutôt que d'attendre qu'il soit backporté...)

Ca m'apprendra à ne pas visiter le spip-lab :wink: !

Au risque de faire sourire - bondir ! - certains d'entre vous, il me semble qu'un fichier spip_styles-dist.css qui intégrerait les styles vitaux de spip pourrait être une solution.

Sur le même principe que les squelettes, un apprenti webmestre a en principe compris le sens du "-dist" et sa logique. Il pourrait donc lui être suggéré de copier et renommer ce fichier en spip_style.css (comme pour les squelettes), de le compléter et/ou de le modifier. En cas d'erreur ou de mauvaise manipulation, il est aisé de revenir aux styles par défaut.

En espérant ne pas trop torturer la courbe d'apprentissage ;-).

#Olivier.

#Olivier wrote:

Au risque de faire sourire - bondir ! - certains d'entre vous, il me
semble qu'un fichier spip_styles-dist.css qui intégrerait les styles
vitaux de spip pourrait être une solution.

Sur le même principe que les squelettes, un apprenti webmestre a en
principe compris le sens du "-dist" et sa logique. Il pourrait donc
lui être suggéré de copier et renommer ce fichier en spip_style.css
(comme pour les squelettes), de le compléter et/ou de le modifier. En
cas d'erreur ou de mauvaise manipulation, il est aisé de revenir aux
styles par défaut.

Bonne idée !

aurelien levy a écrit :

Une bonne fois pour toutes est-ce qu'il serait possible que l'on se départisse de ce dogmatisme des 60 et 80 caractères ? Ce n'est pas une règle que j'applique, même si je fais mon possible pour être le plus accessble possible.

Libre à toi de ne pas l'appliquer mais c'est pourtant une regle importante d'accessibilité pour les raisons que j'ai deja citée (et preuve si l'en est, l'existence de longdesc si la description est trop longue)

Une personne qui a une mauvaise vue et qui a réglé les info-bulles avec des grosses polices sera-t-elle aussi ravie d'une limite qui lui fera des énormes info-bulles ?

La taille de polices des info bulles en particulier n'est pas réglable c'est une partie de l'ecran qui peut etre zoomé

Tous les navigateurs les gèrent-ils de la même manière ? Non ! Il n'est dit nulle part qu'on doive afficher une info-bulle en cas de ALT, et d'ailleurs Mozilla ne le fait pas, alors qu'ne revanche il gère les TITE sous forme d'infos-bulles.

Le alt ne sert pas à afficher une infobulle (il le fait mais effectivement rien n'y oblige comme tu le dit) il sert à donner de l'info pour les personnes qui utilise des synthese vocal et des plages brailles ou qui désactive les images. Maintenant c'est sûr le but recherché c'est d'avoir à tout prix une infobulle là le alt + title sont nécessaire

Comme d'habitude, soyons pragmatiques et pas dogmatiques. Si on doit continuer la discussion, je te propose qu'on le fasse sur spip-lab.

ok mais où précisement

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
irc://irc.freenode.net/spip

Toc-toc,
En premier lieu permettez-moi de vous féliciter tous pour la qualité de votre travail. Merci.

Puis-je m'immicer dans votre intéressante question sur les styles?
Ma connaissance de SPIP est très récente et je viens juste de monter un premier site (en draft).

SPIP doit-il gérer l'apparence de la page vu par le visiteur du site?
A mon sens non, c'est le travail du producteur du site.

Lorsque le producteur envisage l'affichage d'un titre, d'un sous-titre ou d'un chapeau, enfin tout élément parfaitement identifié, il a toute les possibilités par sa feuille de style, des filtres éventuels de maîtriser l'apparence. Il peut parfaitement ecrire
[<p class="monstyleTitre">(#TITRE|maSeriedeFiltres)</p>] tout comme [<h2>(#TITRE)</h2>]. voire plus brutalement <h2>#TITRE</h2>.

La restriction à mon propos concerne les styles à appliquer au corps de l'article (italique, gras, intertitre, lien etc...). Là en effet SPIP doit donner une info de mise en page, la plus proche possible des standards HTML4.xx voire XHTML_x.XX ou plutôt sous la forme <p class="spip-intertitre">INTERTITRE</p>, <p class="spip-note_bas_page">...</p> ou
<ol class="spip-note_bas_page"><li>...</li></ol> ce qui laisse la possibilité au producteur d'adapté le style à son contexte.

Vient ensuite l'apprentissage d'une part et la production d'un premier site.
Il conviendrait en effet de proposer une feuille de style générique comme un squellette générique avec le sufixe "-dist".

Salutations

Claude

spip.cogefip wrote:

aurelien levy a écrit :

Une bonne fois pour toutes est-ce qu'il serait possible que l'on se
départisse de ce dogmatisme des 60 et 80 caractères ? Ce n'est pas
une règle que j'applique, même si je fais mon possible pour être le
plus accessble possible.

Libre à toi de ne pas l'appliquer mais c'est pourtant une regle
importante d'accessibilité pour les raisons que j'ai deja citée (et
preuve si l'en est, l'existence de longdesc si la description est
trop longue)

Une personne qui a une mauvaise vue et qui a réglé les info-bulles
avec des grosses polices sera-t-elle aussi ravie d'une limite qui
lui fera des énormes info-bulles ?

La taille de polices des info bulles en particulier n'est pas
réglable c'est une partie de l'ecran qui peut etre zoomé

Tous les navigateurs les gèrent-ils de la même manière ? Non ! Il
n'est dit nulle part qu'on doive afficher une info-bulle en cas de
ALT, et d'ailleurs Mozilla ne le fait pas, alors qu'ne revanche il
gère les TITE sous forme d'infos-bulles.

Le alt ne sert pas à afficher une infobulle (il le fait mais
effectivement rien n'y oblige comme tu le dit) il sert à donner de
l'info pour les personnes qui utilise des synthese vocal et des
plages brailles ou qui désactive les images. Maintenant c'est sûr le
but recherché c'est d'avoir à tout prix une infobulle là le alt +
title sont nécessaire

Comme d'habitude, soyons pragmatiques et pas dogmatiques. Si on doit
continuer la discussion, je te propose qu'on le fasse sur spip-lab.

ok mais où précisement

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
irc://irc.freenode.net/spip

Toc-toc,
En premier lieu permettez-moi de vous féliciter tous pour la qualité
de votre travail. Merci.

Puis-je m'immicer dans votre intéressante question sur les styles?
Ma connaissance de SPIP est très récente et je viens juste de monter
un premier site (en draft).

SPIP doit-il gérer l'apparence de la page vu par le visiteur du site?
A mon sens non, c'est le travail du producteur du site.

Lorsque le producteur envisage l'affichage d'un titre, d'un sous-titre
ou d'un chapeau, enfin tout élément parfaitement identifié, il a
toute
les possibilités par sa feuille de style, des filtres éventuels de
maîtriser l'apparence. Il peut parfaitement ecrire
[<p class="monstyleTitre">(#TITRE|maSeriedeFiltres)</p>] tout comme
[<h2>(#TITRE)</h2>]. voire plus brutalement <h2>#TITRE</h2>.

La restriction à mon propos concerne les styles à appliquer au corps
de l'article (italique, gras, intertitre, lien etc...). Là en effet
SPIP
doit donner une info de mise en page, la plus proche possible des
standards HTML4.xx voire XHTML_x.XX ou plutôt sous la forme <p
class="spip-intertitre">INTERTITRE</p>, <p
class="spip-note_bas_page">...</p> ou
<ol class="spip-note_bas_page"><li>...</li></ol> ce qui laisse la
possibilité au producteur d'adapté le style à son contexte.

Vient ensuite l'apprentissage d'une part et la production d'un
premier site. Il conviendrait en effet de proposer une feuille de
style générique
comme un squellette générique avec le sufixe "-dist".

Salutations

Claude

Tout à fait d'accord avec toi, Claude.

Une remarque de fond tout de même.
L'apparence de la feuille de style et des squelettes par défaut de SPIP est
actuellement volontairement sobre, dépouillée et, j'ose le dire, peu
engageante.
C'est volontaire ! En effet, la volonté des auteurs de SPIP est que chaque
utilisateur de SPIP se base sur les bonnes idées de boucles présentes dans
ces squelettes, mais fasse une autre présentation afin que tous les sites
sous SPIP ne se ressemblent pas (comme peuvent le faire le phpNuke et autre
phpBB).
Donc, aujourd'hui, il est tentant de faire gérer une partie de la
présentation par le code généré pour que l'utilisateur débutant n'ait pas
trop de difficultés incompréhensibles pour lui.
Une idée pour résoudre cela serait de faire 2 feuille de styles css dans
SPIP
- 1 responsable de la présentation des squelette
- 1 responsable de la présentation des balises spip (que ce soit <p
class="spip"> ou le résultat de <img1|left>...) en expliquant bien que
celle-ci est nécessaire (mais peut quand même être modifiée) !
Ainsi, il me semble que tous serait content !

Cordialement,

Fil wrote:

Coucou,

SPIP connait maintenant les "urls propres" de SPIP-lab ; cf.
http://lab.spip.net/spikini/UrlsPropres

ça c'est cool.

J'édite un magazine "papier", qui est amené à faire le lien
avec des articles ou rubrique sur le web.

Aussi, je suis attaché à la lisibilité et à la communicabilité
des urls, y compris pour des personnes qui ne sont pas familières
avec internet.

En l'occurence, des adresses du type
  www.nomsite.ext/+ecologie-pratique+
  ou www.nomsite.ext/-statut-association-collegiale-
ou, pire encore :
  www.nomsite.ext/+-ferme-autogeree-+
m'apparaissent très déconcertantes
et de nature à induire des erreurs dans la compréhension,
dans le notage, le recopiage, la parole au téléphone,
la transmission par tout autre moyen qu'un copier coller.

Des adresses du type suivant seraient plus facilement fidèlement transmises
  www.nomsite.ext/a-ecologie-pratique
ou www.nomsite.ext/r-statut-association-collegiale
ou www.nomsite.ext/m-ferme-autogeree

Oui, je peux réécrire les règles de réécritures pour qu'elles se conforment à ces souhaits, mais comme ces remarques me semblent valables pour tout le monde,
je propose cet avis ici dans l'espoir que ça profite à la version de base...

JLuc

> http://lab.spip.net/spikini/UrlsPropres
        www.nomsite.ext/a-ecologie-pratique
ou www.nomsite.ext/r-statut-association-collegiale
ou www.nomsite.ext/m-ferme-autogeree

Entièrement d'accord avec toi.

Pour les articles on peut conserver la forme donnée par Antoine, et la
modifier pour les autres. Par ailleurs ça me chagrine un peu que
url_propre soit un champ de chaque table, et pas une table de
correspondance séparée, ce qui permettrait d'étendre à tous les URLs
de tous les objets (hint : documents).

Cela dit, il ne faut pas introduire d'incompatibilité foncière entre
spip-lab et spip-stable ; donc discutons comment faire ça au mieux.

-- Fil

Fil wrote:

http://lab.spip.net/spikini/UrlsPropres

       www.nomsite.ext/a-ecologie-pratique
ou www.nomsite.ext/r-statut-association-collegiale
ou www.nomsite.ext/m-ferme-autogeree

Pour les articles on peut conserver la forme donnée par Antoine,

www.nomsite.ext/+ecologie-pratique+ ?
Bof.
Plutôt simplifier encore : www.nomsite.ext/ecologie-pratique
ça doit être possible ...

> et la modifier pour les autres. Par ailleurs ça me chagrine un peu

que url_propre soit un champ de chaque table, et pas une table de
correspondance séparée, ce qui permettrait d'étendre à tous les URLs
de tous les objets (hint : documents).

ça me fait cogiter du côté "grosses bases de très nombreux objets"
(mais ya rien qui sort).

Cela dit, il ne faut pas introduire d'incompatibilité foncière entre
spip-lab et spip-stable ; donc discutons comment faire ça au mieux.

Indépendamment de la compatibilité, mais du côté du "au mieux",
yaurait un truc top : la possibilité d'indiquer "à la main" une valeur
qui aurait priorité sur la valeur calculée automatiquement.
( Il faudrait étendre la gestion des ambiguïtés avec cette nouvelle possibilité, www.nomsite.ext/ecologie-pratique et www.nomsite.ext/ecologie-pratique-254 )

JLuc

Salut,

Des adresses du type suivant seraient plus facilement fidèlement transmises
  www.nomsite.ext/a-ecologie-pratique
ou www.nomsite.ext/r-statut-association-collegiale
ou www.nomsite.ext/m-ferme-autogeree

Dans ce cas, il y a encore mieux pour transmettre facilement les URLs :
- www.toto.com/a123
- www.toto.com/r45
- www.toto.com/m27

Indépendamment de la compatibilité, mais du côté du "au mieux",
yaurait un truc top : la possibilité d'indiquer "à la main" une valeur
qui aurait priorité sur la valeur calculée automatiquement.

Il suffit d'ajouter un champ dans l'espace privé pour modifier le
url_propre. Ceci dit, c'est un boulot fastidieux et je doute qu'un tel
ajout soit vraiment profitable.

Par ailleurs ça me chagrine un peu que
url_propre soit un champ de chaque table, et pas une table de
correspondance séparée, ce qui permettrait d'étendre à tous les URLs
de tous les objets (hint : documents).

Heu, je ne vois pas la différence, on peut ajouter le champ "url_propre"
aux tables qui le nécessitent. Il faut de toute façon systématiquement
écrire les fonctions genere_url_toto() et les rewrite rules
correspondantes (tu ne peux pas te contenter d'une rewrite rule unique,
sinon tu fais une requête SQL à chaque hit pour savoir quel squelette
sélectionner).

a+

Antoine.

Antoine wrote:

Dans ce cas, il y a encore mieux pour transmettre facilement les URLs :
- www.toto.com/a123
- www.toto.com/r45
- www.toto.com/m27

C'est vrai, mais ya pas la sémantique qui facilite la mémoire,
et ça n'est pas google-parlant.
JL

<quote who='aurelien levy' when='18/09/2004 16:49'>

Une bonne fois pour toutes est-ce qu'il serait possible que l'on se départisse de ce dogmatisme des 60 et 80 caractères ? Ce n'est pas une règle que j'applique, même si je fais mon possible pour être le plus accessble possible.

Libre à toi de ne pas l'appliquer mais c'est pourtant une regle importante d'accessibilité pour les raisons que j'ai deja citée (et preuve si l'en est, l'existence de longdesc si la description est trop longue)

Pardon avec du retard si j'ai pu sembler dur dans ma tournure, Aurélien. Je fais des petites nuits entrecoupées de biberons en ce moment... (spip-dev, la liste où l'on fait des excuses publiques ;))

Ma remarque n'était pas dirigé contre toi mais contre cette règle "au caractère près" qu'il ne me semble pas très rationnel d'appliquer à la lettre. L'esprit, oui ; la lettre, non ! :wink:

Je sais que c'est une règle importante, faire des alt et des title courts, mais ce qui me gêne c'est qu'on ne dise pas "courts" mais "60 et 80". C'est arbitraire, et très spécifique à Braillenet, si je ne m'abuse.

Une personne qui a une mauvaise vue et qui a réglé les info-bulles avec des grosses polices sera-t-elle aussi ravie d'une limite qui lui fera des énormes info-bulles ?

La taille de polices des info bulles en particulier n'est pas réglable c'est une partie de l'ecran qui peut etre zoomé

La taille de police des infos-bulles est réglable sous Windows, pour info. Cf. <http://www.nota-bene.org/misc/spip/tailles_infobulles.png&gt;

Le alt ne sert pas à afficher une infobulle (il le fait mais effectivement rien n'y oblige comme tu le dit) il sert à donner de l'info pour les personnes qui utilise des synthese vocal et des plages brailles ou qui désactive les images. Maintenant c'est sûr le but recherché c'est d'avoir à tout prix une infobulle là le alt + title sont nécessaire

Pour autant, certaines images impliquent un texte altenatif qui pourrait faire, mettons, cent caractères, exceptionnellement. C'est pourquoi cette limite arbitraire me gêne. Il vaut mieux éduquer la personne qui met un texte alternatif à faire "un texte court (environ 80 caractères)"... C'est beaucoup moins coercitif...

Comme d'habitude, soyons pragmatiques et pas dogmatiques. Si on doit continuer la discussion, je te propose qu'on le fasse sur spip-lab.

ok mais où précisement

Là : <http://listes.rezo.net/mailman/listinfo/spip-lab&gt;

C'est notamment sur cette liste qu'on a déjà pas mal discuté de "points fondamentaux" comme strong ou b, etc.

Je propose donc qu'on s'y exporte pour continuer cette discussion, si vous le voulez bien, chers z'auditeuheurs.