lien hypertexte

Général
1

Il existe une balise pour pouvoir afficher un lien hypertexte [lien->http://www…com]
Mais existe-t-il une option supplémentaire pour ouvrir ce lien dans une nouvelle fenêtre ou faut-il le créer??

merci

2

At 14:29 +0200 29/08/01, SÈbastien Choblet wrote:

Il existe une balise pour pouvoir afficher un lien hypertexte [lien->http://www…com]
Mais existe-t-il une option supplémentaire pour ouvrir ce lien dans une nouvelle fenêtre ou faut-il le créer??

Non.

(1) Parce que, pour être honnête, nous détestons ça. :-))
L'ouverture d'une nouvelle fenêtre est une liberté de l'utilisateur, qui peut créer une fenêtre ou non d'un clic de souris (option+clic, ou bouton droit sur PC je crois). A l'inverse, l'ouverture de fenêtres supplémentaires imposée par le webmestre est pénible au dernier degré (avec, sur machines peu puissantes, saturation de la mémoire et risques de plantage).

(2) Parce que les raccourcis de mise en page de SPIP visent à la simplicité. Ce sont des raccourcis typographiques qui décrivent le _contenu_ (notion éditiorale) de l'article; le rédacteur lambda dans SPIP gère le gras, l'italique, les notes de bas de page... (notions éditioriales), alors que l'ouverture d'une autre fenêtre est une notion de navigation Web qu'il n'a pas à gérer lui-même.

(3) Parce que, sur un site aux très multiples rédacteurs (tel uZine), il faut maintenir une certaine unité entre les articles. Avec les raccourcis actuels, cette unité est garantie par leur simplicité (par exemple: pas de mise en couleur, pas de changements de tailles des caractères...) et cette unité est vérifiable d'un coup d'oeil à la validation (il suffit de _lire_ le texte). A l'inverse, si on introduit ce genre de tags de navigation (ouverture d'une fenêtre notamment), ça va être la foire pour vérifier à chaque fois qu'on utilise bien cette option de manière cohérente.

Pour résumer à l'extrême: l'ouverture d'une fenêtre pour les liens à l'intérieur d'un article ne nous semble pas suffisamment souhaitable pour qu'on en fasse un raccourcis spécifique (qui alourdirait donc encore la documentation de SPIP). En revanche, ça peut se justifier par exemple pour la syndication de sites (un pavé qui indique les nouveautés d'autres sites sur le Web); et dans ce cas, ça se gère directement dans les squelettes, où l'on utilise le code HTML habituel pour cela.

On retombe une nouvelle fois sur cette tension permanente dans le développement de SPIP: à la fois de nouvelles fonctionnalités qui offrent plus de liberté pour réaliser des sites très différents, mais aussi (surtout!) une grande simplicité, à la fois conceptuelle (certaines limitations de SPIP imposent, paradoxalement, la réalisation de sites robustes à la structure claire) et dans l'utilisation de l'interface (on ne se pose pas de questions pour savoir ce qui fait quoi - on peut très bien participer à un site sous SPIP sans jamais lire la documentation, ni même la doc en ligne).

Amicalement,
ARNO*

--
Le Scarabée : http://www.scarabee.com
uZine 2 : http://www.uzine.net

DH/DSS, 0x11930F0B, DEEB 602D B344 644B AF88 BF73 85F4 2297 1193 0F0B

3

(3) Parce que, sur un site aux très multiples rédacteurs (tel uZine),
il faut maintenir une certaine unité entre les articles. Avec les
raccourcis actuels, cette unité est garantie par leur simplicité (par
exemple: pas de mise en couleur, pas de changements de tailles des
caractères...) et cette unité est vérifiable d'un coup d'oeil à la
validation (il suffit de _lire_ le texte). A l'inverse, si on
introduit ce genre de tags de navigation (ouverture d'une fenêtre
notamment), ça va être la foire pour vérifier à chaque fois qu'on
utilise bien cette option de manière cohérente.

Je suis assez d'accord avec ca... Cependant, j'ai un autre soucis de cohérence.
L'ensemble de mes squelettes utilise une feuille de style pour définir les
alignements, casses, et autres fioritures. En revanche, quand j'appelle #TEXTE
sur un article, le code html produit refixe ses valeurs. Ainsi par exemple, les
titres introduits avec {{{ }}} sont definis par une balise <font> si je ne
m'abuse. Impossible donc d'y appliquer mon style.

Est-ce qu'il ne serait pas plus judicieux d'utiliser dans la generation du
document les balises predefinies h1, ... afin que tout le monde puisse ensuite y
appliquer le style voulu ?

Un autre moyen serait d'inserer au moment de l'ecriture de l'article qq chose
comme <HTML><p class="myClass">...</p></HTML>... Pas tres elegant non ?

Ai-je manque ici un aspect de SPIP, ou suis-je dans le vrai ? Merci de
commenter.

David.

4

@ dsoulayrol@free.fr (dsoulayrol@free.fr) :

Ainsi par exemple, les titres introduits avec {{{ }}} sont definis par une
balise <font> si je ne m'abuse. Impossible donc d'y appliquer mon style.

tu peux modifier cette balise en indiquant, dans tes fichiers d'appel
(article.php3, etc.)
    $debut_intertitre = "<ce que tu veux...";
    $fin_intertitre = "autre chose";

-- Fil

5

    $debut_intertitre = "<ce que tu veux...";
    $fin_intertitre = "autre chose";

Merci a vous pour ces lignes... Y a-t-il d'autres subtilites du meme genre que
j'ai manque ? Est-ce que cette astuce figure quelque part sur le site de Spip ?

Merci, A+

6

Pourquoi ne pas faire dans Spip, une balise [texte=>URL] pour pouvoir ouvrir le lien dans une nouvelle fenêtre (au lieu d'écrire [lien->URL" target="_blank"]. Cette question vient à la demande de visiteurs sur le site de l'Apress qui cliquent sur le site d'une source d'un article mais qui ensuite se trouvent obligés d'utiliser le bouton de retour en arrière.

Merci,

Sébastien

On Wed, 29 Aug 2001 15:48:08 +0200
ARNO* <arno@scarabee.com> wrote:

At 14:29 +0200 29/08/01, SÈbastien Choblet wrote:
>Il existe une balise pour pouvoir afficher un lien hypertexte
>[lien->http://www…com]
>Mais existe-t-il une option supplémentaire pour ouvrir ce lien dans
>une nouvelle fenêtre ou faut-il le créer??

Non.

(1) Parce que, pour être honnête, nous détestons ça. :-))
L'ouverture d'une nouvelle fenêtre est une liberté de l'utilisateur,
qui peut créer une fenêtre ou non d'un clic de souris (option+clic,
ou bouton droit sur PC je crois). A l'inverse, l'ouverture de
fenêtres supplémentaires imposée par le webmestre est pénible au
dernier degré (avec, sur machines peu puissantes, saturation de la
mémoire et risques de plantage).

(2) Parce que les raccourcis de mise en page de SPIP visent à la
simplicité. Ce sont des raccourcis typographiques qui décrivent le
_contenu_ (notion éditiorale) de l'article; le rédacteur lambda dans
SPIP gère le gras, l'italique, les notes de bas de page... (notions
éditioriales), alors que l'ouverture d'une autre fenêtre est une
notion de navigation Web qu'il n'a pas à gérer lui-même.

(3) Parce que, sur un site aux très multiples rédacteurs (tel uZine),
il faut maintenir une certaine unité entre les articles. Avec les
raccourcis actuels, cette unité est garantie par leur simplicité (par
exemple: pas de mise en couleur, pas de changements de tailles des
caractères...) et cette unité est vérifiable d'un coup d'oeil à la
validation (il suffit de _lire_ le texte). A l'inverse, si on
introduit ce genre de tags de navigation (ouverture d'une fenêtre
notamment), ça va être la foire pour vérifier à chaque fois qu'on
utilise bien cette option de manière cohérente.

Pour résumer à l'extrême: l'ouverture d'une fenêtre pour les liens à
l'intérieur d'un article ne nous semble pas suffisamment souhaitable
pour qu'on en fasse un raccourcis spécifique (qui alourdirait donc
encore la documentation de SPIP). En revanche, ça peut se justifier
par exemple pour la syndication de sites (un pavé qui indique les
nouveautés d'autres sites sur le Web); et dans ce cas, ça se gère
directement dans les squelettes, où l'on utilise le code HTML
habituel pour cela.

On retombe une nouvelle fois sur cette tension permanente dans le
développement de SPIP: à la fois de nouvelles fonctionnalités qui
offrent plus de liberté pour réaliser des sites très différents, mais
aussi (surtout!) une grande simplicité, à la fois conceptuelle
(certaines limitations de SPIP imposent, paradoxalement, la
réalisation de sites robustes à la structure claire) et dans
l'utilisation de l'interface (on ne se pose pas de questions pour
savoir ce qui fait quoi - on peut très bien participer à un site sous
SPIP sans jamais lire la documentation, ni même la doc en ligne).

Amicalement,
ARNO*

--
Le Scarabée : http://www.scarabee.com
uZine 2 : http://www.uzine.net

DH/DSS, 0x11930F0B, DEEB 602D B344 644B AF88 BF73 85F4 2297 1193 0F0B

7

Pour ne pas alourdir inutilement le jeu de raccourcis typographiques,
et la routine qui s'en occupe ;)) (cf. mail d'Arno).

a+

Antoine.

"Sébastien Choblet" wrote:

Pourquoi ne pas faire dans Spip, une balise [texte=>URL] pour pouvoir ouvrir le lien dans une nouvelle fenêtre (au lieu d'écrire [lien->URL" target="_blank"]. Cette question vient à la demande de visiteurs sur le site de l'Apress qui cliquent sur le site d'une source d'un article mais qui ensuite se trouvent obligés d'utiliser le bouton de retour en arrière.

Merci,

Sébastien