-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
je pense que ces raccourcis typographiques ne sont pas qu'intéressant
pour leur caractère de raccourci. Selon moi, ils *cadrent*
l'utilisateur dans une bonne séparation du contenu et de la forme :
avec ces raccourcis, celui-il s'éloigne du HTML et ne se préoccupe
donc plus (ou en tout cas moins) de ce à quoi l'article va
ressembler.
De plus, cela permet de restreindre (sans être certain bien sûr) dans
une certaine mesure les balises qui vont être utilisées sur le site,
ce qui rend celui-ci beaucoup plus simple à développer et à
maintenir. Ce que je veux dire, c'est que selon moi, ce n'est pas une
bonne idée que les auteurs utilisent des balises HTML (sauf cas
particuliers bien entendu) de manière récurrente.
Et pour finir, même à supposer qu'il connaisse le HTML, comment
saura-t-il que pour que la hierarchie de la page finale soit
respectée, il faut utiliser des h(n) uniquement à partir de 3?
Pourtant, je soupconne la plupart des webmestres d'avoir supposé que
les articles n'auraient pas de h1 et de h2 lorsqu'ils ont créé leurs
squelettes. Si on encourage les utilisateurs à abuser des balises
HTML, on ne peut plus faire ce genre de suppositions, ce qui rend la
création de pages finales logiques et accessibles beaucoup plus dur
(impossible?).
Laurent
Toujours est-il que nous cherchons des racourcis typographiques pour des
balises de niveau 3 4 5 6 physiques.
Pour faire simple, et correctement separer la forme et le contenu,
pourquoi ne pas faire :
<h1> </h1> (equivalent au courant {{{ }}})
<h2> </h2>
<h3> </h3>
<h4> </h4>
Ils seront ensuite traduits correctement par SPIP dans le header voulu par
les squelettes (a savoir par defaut H3 H4 H5 H6)
Avantages :
- connus de tous ceux qui connaissent deja le html
- faciles a apprendre
- courts... et scalables 
(leur taille n'augmente pas avec le nombre
- independants de la forme
Inconvenients :
- aucun 
Et me dites pas qu'utiliser des balises HTML comme raccourci, c'est mal..
tout le monde ici connait <code> </code> (où un raccourci génial aurait
été bien utile 
Bonsoir,
je pense que ces raccourcis typographiques ne sont pas
qu'intéressant pour leur caractère de raccourci. Selon moi, ils
*cadrent* l'utilisateur dans une bonne séparation du contenu et de
la forme : avec ces raccourcis, celui-il s'éloigne du HTML et ne se
préoccupe donc plus (ou en tout cas moins) de ce à quoi l'article va
ressembler.
Eh bien non, justement, SPIP ne va pas jusqu'au bout de ce qu'il
promet en terme de séparation entre contenu et forme, puisqu'il
indique notamment comment "mettre en gras" au lieu d'indiquer comment
"mettre en évidence" !
Du coup, les utilisateurs mettent en gras tout et n'importe quoi tout
en croyant vraiment séparer le contenu de la forme.
Si l'on veut vraiment séparer le contenu et la forme, il faut
abandonner toute logique orientée présentation dans les raccourcis
SPIP, tant dans leur description que dans leur tranformation HTML.
Par exemple, {{blah blah}} devrait signaler une "mise en évidence" et le
HTML généré ne devrait pas être <b class="spip">blah blah</b> mais
<span class="spip-important">blah blah</span> ...
Et puisque le sujet est plutôt ici des intertitres, s'il faut en gérer
plusieurs niveaux, ce que j'applaudirais copieusement, le mieux est de
le faire sans se donner de limites, avec une hiérarchisation libre. Si
on veut des intertitres de différents niveaux, c'est pour avoir
différents niveaux de sections, donc autant imaginer un marquage de
niveaux de sections.
Par exemple on ecrirait dans SPIP :
Par exemple, {{blah blah}} devrait signaler une "mise en évidence"
C'est impossible à assimiler. Les utilisateurs vont voir que cela
s'affiche en gras et retiendront que {{toto}} met toto en gras.
Je défie quiconque d'expliquer en quelques mots simples et précis
ce que recouvre une "mise en évidence au sens de <em>" et
une "mise en évidence au sens de <strong>". Au contraire des
intertitres, je ne vois aucune caractérisation pertinente de
ces deux concepts. D'ailleurs, je suis sûr que même au W3C, ils
ne sont pas capables de l'expliquer précisément.
Désolé, mais il me semble que tout ça est illégal en XHTML ou même en HTML.
<ul> ne peut pas contenir <p>
Voir validation d'une page test du code ci-bas.
http://validator.w3.org/check?uri=http://edu.ca.edu/test/test-erreur.html
André Vincent
Ce que dit réellement cette page est qu'un <p> doit être entouré d'un
<li> s'il est dans un <ul>.
A.
Désolé, mais il me semble que tout ça est illégal en XHTML ou
même en HTML.
<ul> ne peut pas contenir <p>
J'ai bien dit que c'est du "brut de décofrage", imaginé en même temps que
j'écrivais le message, je n'ai pas fait attention à cette règle, que je
connaissais pourtant ... 
Ce que dit réellement cette page est qu'un <p> doit être entouré d'un
<li> s'il est dans un <ul>.
Voilà donc qui est résolu.
-Nicolas
Par exemple, {{blah blah}} devrait signaler une "mise en évidence"
C'est impossible à assimiler. Les utilisateurs vont voir que cela
s'affiche en gras et retiendront que {{toto}} met toto en gras.
Sauf que les utilisateurs sur mon site verront que ce n'est pas du tout en gras
mais en rouge, et il assimileront cela à du rouge ...
Je défie quiconque d'expliquer en quelques mots simples et précis
ce que recouvre une "mise en évidence au sens de <em>" et
une "mise en évidence au sens de <strong>". Au contraire des
intertitres, je ne vois aucune caractérisation pertinente de
ces deux concepts. D'ailleurs, je suis sûr que même au W3C, ils
ne sont pas capables de l'expliquer précisément.
Je comprends très bien le besoin de mettre en évidence de différentes manières,
en s'appuyant sur le fond et non sur la forme, mais je ne comprends pas non plus
ces tags du W3C qui ne veulent rien dire.
Ils auraient dû créer un unique tag de mise en évidence, qu'on aurait
spécialisés avec des classes et des CSS qui vont bien avec ...
-Nicolas
Pour rebondir sur ce qui a été dit depuis hier:
- au sujet de 'mise en evidence' au lieu de 'mettre en gras/italique',
Laurent en avait déjà parlé dans un mail précédent.
Petite précision: dans les spec du W3C pour le HTML2
(http://ftp.ics.uci.edu/pub/ietf/html/rfc1866.txt), ils differencient bien
tout ce qui est 'idiomatic' (logique) et ce qui est 'typographic'
(physique). Cependant, ils conseillent de rendre le STRONG en gras, le EM
en italique, et que si le gras (pour B) ou l'italique (pour I) n'est pas
disponible, une autre représentation peut être utilisée (pour répondre à
Laurent qui expliquait la différence entre STRONG/EM et B/I dans un mail
précédent).
Bref, je suis d'accord avec Antoine pour dire que c'est bien parler pour
rien tout ça.
Par contre, je suis contre la proposition d'André Vincent qui consiste à
insérer des h1... etc directement dans l'article, et de les traiter par
feuille de style. En effet, cela marcherait dans des navigateurs récents;
mais on perd toute la structure de la page, et donc l'accessibilité.
Je reste sur ma proposition précédente qui consistait à certes insérer des
h1/etc dans l'article, mais à les traiter tout de même.
Et eventuellement proposer un utilitaire de conversion de la base pour
ceux qui utilisaient déjà de telles balises.
Bonjour,
On 13 Aug 2003 23:18:23 +0200 GMT, Antoine wrote to spip-dev@rezo.net :
Je défie quiconque d'expliquer en quelques mots simples et précis
ce que recouvre une "mise en évidence au sens de <em>" et
une "mise en évidence au sens de <strong>".
Au niveau de la mise en forme, nous avons plusieurs manieres de
mettre en evidence un passage : gras, italique, souligne, double
souligne, barre, double barre, encadre, exposant, etc. etc. Le fait
d'avoir plusieurs possibilites permet de les mixer : e.g. dans un
passage en gras je peux vouloir mettre en italique une citation. Il
ne sert a rien, sinon a embrouiller le lecteur, de melanger trop de
attributs differents.
En fait, ces attributs differents correspondent a deux domaines :
#1 la mise en evidence et #2 la police utilisee. Le #1 se
situe au niveau du contenu, le #2 au niveau de la forme. Si l'on
veut distinguer le contenu et la forme, il faut creer des attributs
dont le #2 soit librement definissable par l'utilisateur. On peut
commencer par en creer un (appellons le : "<STRONG>"), mais on se
rend vite compte qu'en avoir au moins un deuxieme, pour pouvoir les
mixer, serait pratique : creons-le et appellons le "<EM>".
Il n'y a donc aucune difference de niveau logique entre <EM> et
<STRONG>, ils sont juste deux options differentes, toutes les deux
configurables (chacun peut definir a quoi ils correspondent en
termes de police). La confusion avec <g> et <i> provient simplement
du fait que la configuration par defaut des navigateurs visuels de
<strong> et <em> renvoie respectivement a ces deux balises.
Pour repondre precisement et simplement a la question d'Antoine :
chacun correspond a une mise en evidence (niveau du contenu) ayant
une mise en forme differente definie par l'utilisateur.
A bientôt,
Philippe
Non seulement cela, mais aussi que c'etait conseillé ainsi par les specs
du W3C.
cf http://www.w3.org/TR/REC-html32#phrase
A partir du HTML4, ce n'est plus conseillé, c'est uniquement un constat:
http://www.w3.org/TR/1998/REC-html40-19980424/struct/text.html#h-9.2.1
http://www.w3.org/TR/html401/struct/text.html#h-9.2.1
de toute maniere, de nos jours, je pense que la distinction est obsolète.
On peut changer l'aspect des textes entre balises B ou I aussi facilement
que les textes entre balises STRONG et EM.
(a noter, en passant, que c'est quand meme particulierement lourd de taper
STRONG et EM quand la meme chose (graphiquement parlant) peut etre
realisee par B et I