Salut,
dites-moi, j'ai pas fait gaffe, mais je viens de refaire un tour sur le
site CLX, à jour de la semaine dernière de la CVS.
Le fonctionnement de <code></code> a changé ?
J'avais l'habitude de faire :
Salut,
dites-moi, j'ai pas fait gaffe, mais je viens de refaire un tour sur le
site CLX, à jour de la semaine dernière de la CVS.
Le fonctionnement de <code></code> a changé ?
J'avais l'habitude de faire :
Prenons, par exemple, cette ligne, la première de la règle S93 :
<code>
R$+ < @ $=G . > $: <$1@$2 > $1 < @ $2 . > @ mark
</code>
Que cela signifie-t-il ?
J'avoue que je n'en sais rien ; j'utilise postfix, pas sendmail
Et bien cela, maintenant, colle tout en vrac. C'est laid, et à
l'encontre des balises verbatim de latex, et <pre(formated)> de html.C'est moi, ou le focntionnement achangé ?
Je crois qu'il y a une feuille de style à remplir : spip_code
-- Fil
> Et bien cela, maintenant, colle tout en vrac. C'est laid, et à
> l'encontre des balises verbatim de latex, et
<pre(formated)> de html.
>
> C'est moi, ou le focntionnement achangé ?Je crois qu'il y a une feuille de style à remplir : spip_code
???
Jusque-là <code> se transformait en <tt> si je ne m'abuse.
Jusque-là <code> se transformait en <tt> si je ne m'abuse.
Oui, mais ce n'est plus le cas
-- Fil
Le souci, c'est -- hormis le comportement de whitespace réglable dans le
css -- c'est pour les sauts de lignes.
J'ai pas trouvé d'attribut css à renseigner pour lui dire de ne pas
gérer les sauts de ligne, et de les prendre "as-is"...
<quote who="Gaetan Ryckeboer" when="30/10/03 15:59">
Jusque-là <code> se transformait en <tt> si je ne m'abuse.
Oui, mais ce n'est plus le cas
Le souci, c'est -- hormis le comportement de whitespace réglable dans le
css -- c'est pour les sauts de lignes.
J'ai pas trouvé d'attribut css à renseigner pour lui dire de ne pas
gérer les sauts de ligne, et de les prendre "as-is"...
<disclaimer>
Vous allez me voir de plus en plus faire des posts comme celui qui suit. Ne m'en tenez pas rigueur, ce n'est pas de la critique pour le sport, c'est une tentative constructive de faire des constats et des propositions. Par ailleurs j'ai déjà souvent exprimé mon attachement pour spip, tant l'outil que le projet, donc voilà... rien de méchant de ma part.
En plus j'ai une fâcheuse tendance à penser à voix haute avant d'agir pour échanger les idées avant de me jeter dans le code.
</disclaimer>
L'implémentation que je constate est la suivante :
Code en ligne dans un phrase :
<tt><span dir="ltr" class="spip_code">inline code</span></tt>
Code en "bloc (plusieurs lignes) :
<p class="spip"><tt><div dir="ltr" class="spip_code" align="left">multiline code<br>
indented with 4 spaces<br>
not indented</div></tt></p>
Effectivement on devrait lire, dans le premier cas :
<code class="spip">inline code</code>
et dans le deuxième :
<pre class="spip">multiline code
indented with 4 spaces
not indented</pre>
'Code bloat' et 'tag soup', je note pour référence ultérieure en xhtmlisation...
1. je comprends le dir="ltr", mais que fait-il là et pas dans la CSS ?
2. bientôt je vais éplucher le générateur de code. J'ai l'impression que le code est traité en plusieurs passes (question de gestion des innombrables variantes possible) : à la première on génère les éléments de type bloc (les <p>, quoi), et à la deuxième on regarde ce qu'il y a dedans sans regarder autour (sans englober le conteneur). C'est là que le bât blesse, on dirait. C'est là-dessus qu'on va devoir vachement bosser, mais donnez-moi votre avis préliminaire : est-ce que j'oublie des choses ? Est-ce que je simplifie trop ? Est-ce que le traitement a déjà été tenté autrement et que ça ralentissait trop le générateur de contenu ?
3. <div> imbriquée dans un <p>, argl. (j'ai le même souci avec les documents, je vous en reparlerai à l'occasion).