Comme rien n'était prévu dans SPIP pour différencier les <blockquotes>
des <q>, je me suis décidé à faire plugin tout simple: avec le
pipeline pre_propre, il remplace les <quote> par <q> s'il n'y a pas de
retour à la ligne dans la citation.
C'est tout bête mais c'est plus élégant que de mettre en italiques
parce que <quote> fait des <blockquotes> et qu'on veut que sa citation
reste "inline".
Une doc sur SPIP-contrib: SPIP-Contrib et
bientôt un zip...
Comme rien n'était prévu dans SPIP pour différencier les <blockquotes>
des <q>, je me suis décidé à faire plugin tout simple: avec le
pipeline pre_propre, il remplace les <quote> par <q> s'il n'y a pas de
retour à la ligne dans la citation.
Chouette ! Bonne idée !
J'irais plus loin : puisque « quote » est une abréviation de « blockquote », abrégeons encore, et utilisons le raccourci... « q » (en conservant « quote » pour compatibilité avec l'existant).
Au final, ce plugin ferait :
le raccourci SPIP « <q> » (ou « <quote> ») signale les citations, en distinguant celles en ligne par la balise HTML <q> et celle en bloc par la balise HTML <blockquote>.
Nous avons déjà le raccourci <code> qui fonctionne ainsi.
-----Message d'origine-----
De : romy@rezo.net [mailto:romy@rezo.net]
Envoyé : jeudi 28 mai 2009 09:31
À : spip zone
Objet : Re: [SPIP Zone] nouveau plugin Citations bien balisées
Le 27 mai 2009 à 17:59, MARNE Bertrand a écrit :
Comme rien n'était prévu dans SPIP pour différencier les <blockquotes>
des <q>, je me suis décidé à faire plugin tout simple: avec le
pipeline pre_propre, il remplace les <quote> par <q> s'il n'y a pas de
retour à la ligne dans la citation.
Chouette ! Bonne idée !
J'irais plus loin : puisque « quote » est une abréviation de «
blockquote », abrégeons encore, et utilisons le raccourci... « q
» (en conservant « quote » pour compatibilité avec l'existant).
Au final, ce plugin ferait :
le raccourci SPIP « <q> » (ou « <quote> ») signale les citations, en
distinguant celles en ligne par la balise HTML <q> et celle en bloc
par la balise HTML <blockquote>.
Nous avons déjà le raccourci <code> qui fonctionne ainsi.
Je suis assez réservé sur la question. En effet, à partir du moment où
il faut des trucs du genre q:lang(fr):before(«), ça devient tout de
même un peu complexe à utiliser... notamment, on risque d'avoir des
citations qui ne s'affichent pas bien en "mode texte" (lynx) puisque
privées de leurs guillemets.
Je suis assez réservé sur la question. En effet, à partir du moment où
il faut des trucs du genre q:lang(fr):before(«), ça devient tout de
même un peu complexe à utiliser... notamment, on risque d'avoir des
citations qui ne s'affichent pas bien en "mode texte" (lynx) puisque
privées de leurs guillemets.
Le 28 mai 2009 09:30, romy@rezo.net <romy@rezo.net> a écrit :
Le 27 mai 2009 à 17:59, MARNE Bertrand a écrit :
Chouette ! Bonne idée !
Bonne idée : oui, d’autant qu’elle vient de toi !
J'irais plus loin : puisque « quote » est une abréviation de « blockquote »,
abrégeons encore, et utilisons le raccourci... « q » (en conservant « quote
» pour compatibilité avec l'existant).
Je comprends le souci de compatibilité... Le problème est qu’on risque
d’avoir des gens qui vont utiliser <q> à la place de <quote> et donc
d’avoir des citations de plusieurs lignes avec des <q>. Le traitement
automatique permet d’éviter aux rédacteurs (qui s’en fichent un peu je
le crains) d’avoir à se préoccuper de ça.
Coté compatibilité, ce qui risque d’arriver c’est de faire disparaitre
des paragraphes... Il faut que les webmestres évaluent ce risque avant
d’activer le plugin.
Je suis assez réservé sur la question. En effet, à partir du moment où
il faut des trucs du genre q:lang(fr):before(«), ça devient tout de
même un peu complexe à utiliser... notamment, on risque d'avoir des
citations qui ne s'affichent pas bien en "mode texte" (lynx) puisque
privées de leurs guillemets.
Non plus ! Je ne suis pas pour coller du CSS chiadé comme ça dans SPIP.
Mais l'introduction de la balise HTML <q> me semble une bonne chose (à la place des actuels <quote> qui génèrent du gros <blockquote> ou des <i> qui n'ont pas de sens).
Je suis réservée aussi, mais..
- Le HTML pour les citations (et son support sur les différents navigateurs) est actuellement plutôt médiocre, pour ne pas dire déplorable.
- Rien n'empêche SPIP d'être un chouïa en avance là-dessus.
- Ce plugin peut être l'occasion de tester/réfléchir en situation réelle, tranquillou.
Sous Firefox, Safari (sans CSS) : “youhou” (guill. anglais)
Sous lynx : "youhou" (guilll. droits "informatiques")
Si on ajoute des CSS :
Sous Firefox, Safari : « youhou » (guill. fr)
Sous lynx : "youhou" (guilll. droits "informatiques")
=> incohérence
heu
c'est le propre et l'essence même du web que de pouvoir être rendu de façon différentes selon le dispositif de consultation utilisé.
Il n'y a pas de bonne justification à mettre les « et » en durs dans le html pour être sûr que ça va bien afficher des guillemets à la française sur tous les dispositifs.
En l'occurence, que lynx affiche malgré tout des guillemets droits informatique ne dénature pas le sens ni la compréhension du texte, ce qui est bien le but et l'objectif.
L'utilisation d'une balise q seule permet par ailleurs aux synthèse vocales d'annoncer correctement la citation. Si on double le <q> de guillemets on se retrouve alors avec un double balisage sémantique et visuel, qui sera rendu deux fois dans certains cas.
Je comprends le souci de compatibilité... Le problème est qu’on risque
d’avoir des gens qui vont utiliser <q> à la place de <quote>
Oui, c'est le but (c'est nettement plus court et rapide à écrire !)
et donc
d’avoir des citations de plusieurs lignes avec des <q>.
Qu'importe si le raccourci SPIP <q> génère un blockquote dans ce cas !?
Tout comme le raccourci SPIP <code> génère du HTML inline <code> quand il est dans une ligne, et du HTML block (<div> au lieu de <pre> mais bien block) quand il croise un saut de ligne
Coté compatibilité, ce qui risque d’arriver c’est de faire disparaitre
des paragraphes... Il faut que les webmestres évaluent ce risque avant
d’activer le plugin.
Non, les paragraphes ne doivent pas disparaître, puisqu'en XHTML, la balise blockquote doit contenir au moins un élément de type block <troll>et que SPIP se vente d'être valide XHTML Strict</troll>.
Il n'y a pas de bonne justification à mettre les « et » en durs dans le
html pour être sûr que ça va bien afficher des guillemets à la française sur
tous les dispositifs.
Au contraire, si je veux que mon texte s'affiche partout avec "«", je
ne peux pas utiliser <q>.
En l'occurence, que lynx affiche malgré tout des guillemets droits
informatique ne dénature pas le sens ni la compréhension du texte, ce qui
est bien le but et l'objectif.
Non, ce n'est pas acceptable dans tous les contextes d'application.
<troll>On pourrait aussi décider à ce compte-là d'unifier majuscules
et minuscules ???</troll>
Les choses deviennent encore plus compliquées quand tu as des
guillemets de second niveau...
L'utilisation d'une balise q seule permet par ailleurs aux synthèse vocales
d'annoncer correctement la citation. Si on double le <q> de guillemets on se
retrouve alors avec un double balisage sémantique et visuel, qui sera rendu
deux fois dans certains cas.
En effet on ne peut pas doubler <q> par des guillemets, je n'ai
d'ailleurs jamais proposé cela. Au final, le fait que le rendu soit si
peu fiable rend cette balise <q> pratiquement inutilisable (en tous
cas dans le contexte que je connais).
Je suis assez réservé sur la question. En effet, à partir du moment où
il faut des trucs du genre q:lang(fr):before(«), ça devient tout de
même un peu complexe à utiliser... notamment, on risque d'avoir des
citations qui ne s'affichent pas bien en "mode texte" (lynx) puisque
privées de leurs guillemets.
Non plus ! Je ne suis pas pour coller du CSS chiadé comme ça dans SPIP.
Mais l'introduction de la balise HTML <q> me semble une bonne chose (à la place des actuels <quote> qui génèrent du gros <blockquote> ou des <i> qui n'ont pas de sens).
Je suis réservée aussi, mais..
- Le HTML pour les citations (et son support sur les différents navigateurs) est actuellement plutôt médiocre, pour ne pas dire déplorable.
- Rien n'empêche SPIP d'être un chouïa en avance là-dessus.
- Ce plugin peut être l'occasion de tester/réfléchir en situation réelle, tranquillou.
Je précise ma pensée :
- que SPIP génère une balise <q> à la place du raccourci SPIP <quote> utilisé en ligne me semble plus cohérent que de forcer un block tel qu'actuellement (aussi cohérent que le fonctionnement actuel du raccourci SPIP <code>)
- ça n'empêche pas les rédacteurs d'ignorer la balise HTML <q> et de saisir des guillemets « et » en dur (comme je le pratique et préconise parfois)
- pour le reste de la réflexion sur les citations (CSS de q, guillemettage international, mention des sources, auteur, date, etc.) le plugin peut être l'occasion d'explorer les possibilités pour compléter les manques du HTML et du support des navigateurs.
Je précise ma pensée :
- que SPIP génère une balise <q> à la place du raccourci SPIP <quote>
utilisé en ligne me semble plus cohérent que de forcer un block tel
qu'actuellement (aussi cohérent que le fonctionnement actuel du raccourci
SPIP <code>)
- ça n'empêche pas les rédacteurs d'ignorer la balise HTML <q> et de saisir
des guillemets « et » en dur (comme je le pratique et préconise parfois)
- pour le reste de la réflexion sur les citations (CSS de q, guillemettage
international, mention des sources, auteur, date, etc.) le plugin peut être
l'occasion d'explorer les possibilités pour compléter les manques du HTML et
du support des navigateurs.
Je souscris sans réserves à cette approche. (C'est bien dit, non ?)
Désolé d'avoir fichu un tel bazar avec mon plugin !!
Le 28 mai 2009 12:36, Fil <fil@rezo.net> a écrit :
Je précise ma pensée :
- que SPIP génère une balise <q> à la place du raccourci SPIP <quote>
utilisé en ligne me semble plus cohérent que de forcer un block tel
qu'actuellement (aussi cohérent que le fonctionnement actuel du raccourci
SPIP <code>)
- ça n'empêche pas les rédacteurs d'ignorer la balise HTML <q> et de saisir
des guillemets « et » en dur (comme je le pratique et préconise parfois)
- pour le reste de la réflexion sur les citations (CSS de q, guillemettage
international, mention des sources, auteur, date, etc.) le plugin peut être
l'occasion d'explorer les possibilités pour compléter les manques du HTML et
du support des navigateurs.
Je souscris sans réserves à cette approche. (C'est bien dit, non ?)
Je crois que je souscris aussi... bien que je ne sois pas sûr d'avoir
tout compris:
Romy, tu proposes que
1- <quote> garde son fonctionnement historique (compatibilité)
2- <q> soit un nouveau raccourci remplacé en HTML par <q> ou
<blockquote> selon les cas.
3- dire aux rédacteurs que <q> remplace <quote>.
-----Message d'origine-----
De : MARNE Bertrand [mailto:bmarne@gmail.com]
Envoyé : jeudi 28 mai 2009 13:54
À : Fil
Cc : spip zone
Objet : Re: [SPIP Zone] nouveau plugin Citations bien balisées
Salut !
Désolé d'avoir fichu un tel bazar avec mon plugin !!
Le 28 mai 2009 12:36, Fil <fil@rezo.net> a écrit :
Je précise ma pensée :
- que SPIP génère une balise <q> à la place du raccourci SPIP <quote>
utilisé en ligne me semble plus cohérent que de forcer un block tel
qu'actuellement (aussi cohérent que le fonctionnement actuel du raccourci
SPIP <code>)
- ça n'empêche pas les rédacteurs d'ignorer la balise HTML <q> et de
saisir
des guillemets « et » en dur (comme je le pratique et préconise parfois)
- pour le reste de la réflexion sur les citations (CSS de q,
guillemettage
international, mention des sources, auteur, date, etc.) le plugin peut
être
l'occasion d'explorer les possibilités pour compléter les manques du HTML
et
du support des navigateurs.
Je souscris sans réserves à cette approche. (C'est bien dit, non ?)
Je crois que je souscris aussi... bien que je ne sois pas sûr d'avoir
tout compris:
Romy, tu proposes que
1- <quote> garde son fonctionnement historique (compatibilité)
2- <q> soit un nouveau raccourci remplacé en HTML par <q> ou
<blockquote> selon les cas.
3- dire aux rédacteurs que <q> remplace <quote>.
En effet on ne peut pas doubler <q> par des guillemets, je n'ai
d'ailleurs jamais proposé cela. Au final, le fait que le rendu soit si
peu fiable rend cette balise <q> pratiquement inutilisable (en tous
cas dans le contexte que je connais).
Avec une assistance auditive type Jaws (lecteur écran), la balise <q> est correctement interprétées avec un début et une fin.
Alors que les « » ne sont pas forcément vocalisés ne permettant pas toujours de savoir quand commence, et surtout, finie la citation.
