Avec la dernière SVN (sans plugin, avec le .htaccess de SPIP), les favicon sont pétées :
Quand je demande /spip.php?page=favicon.ico
J'obtiens :
L'image “/spip.php?page=favicon.ico” ne peut être affichée car elle contient des erreurs.
* RealET tapuscrivait, le 06/07/2009 16:35:
Avec la dernière SVN (sans plugin, avec le .htaccess de SPIP), les favicon sont pétées :
Quand je demande /spip.php?page=favicon.ico
J'obtiens :
L'image “/spip.php?page=favicon.ico” ne peut être affichée car elle contient des erreurs.
Et c'est http://trac.rezo.net/trac/spip/changeset/14163
le fautif.
En 14162, c'est bon.
* RealET tapuscrivait, le 06/07/2009 16:42:
* RealET tapuscrivait, le 06/07/2009 16:35:
Avec la dernière SVN (sans plugin, avec le .htaccess de SPIP), les favicon sont pétées :
Quand je demande /spip.php?page=favicon.ico
J'obtiens :
L'image “/spip.php?page=favicon.ico” ne peut être affichée car elle contient des erreurs.Et c'est http://trac.rezo.net/trac/spip/changeset/14163
le fautif.
En 14162, c'est bon.
Et pour que ça marche en 14163, il faut modifier le squelette favicon.ico.html de
#HTTP_HEADER{Content-Type: image/x-icon}
[(#INCLURE{favicon.ico}|sinon{#INCLURE{spip.ico}})]
en
[(#HTTP_HEADER{Content-Type: image/x-icon}
)][(#INCLURE{favicon.ico}|sinon{#INCLURE{spip.ico}})]
Puisqu'avant, le retour à la ligne n'était pas envoyé au navigateur...
Et c'est http://trac.rezo.net/trac/spip/changeset/14163 le fautif.
Et pour que ça marche en 14163, il faut modifier le squelette
favicon.ico.html
Ah mais non ! Il faut remettre le soi-disant "bug" dans le
compilateur, au moins dans la branche dite "stable".
Pour ma part j'ai toujours pensé que c'était une feature... L'exemple
donné dans le log du commit d'esj est précisément géré comme il faut
par #EDIT{} qui ajoute elle-même l'espace indispensable.
-- Fil
* Fil tapuscrivait, le 06/07/2009 16:57:
Et c'est http://trac.rezo.net/trac/spip/changeset/14163 le fautif.
Et pour que ça marche en 14163, il faut modifier le squelette
favicon.ico.htmlAh mais non ! Il faut remettre le soi-disant "bug" dans le
compilateur, au moins dans la branche dite "stable".Pour ma part j'ai toujours pensé que c'était une feature... L'exemple
donné dans le log du commit d'esj est précisément géré comme il faut
par #EDIT{} qui ajoute elle-même l'espace indispensable.
Oui, ça doit casser plus de choses que ça en répare.
Ah non je ne suis psa du tout d'accord: les seuls espaces non significatifs sont à l'intérieur des parenthèses des champs ou des chevrons du Inclure, sinon la doc est impossible à écrire. A la rigueur, on retire la correction dans la 2.0, mais je ne suis même pas sur.
Committo,Ergo:Sum
Ah non je ne suis psa du tout d'accord: les seuls espaces non significatifs
sont à l'intérieur des parenthèses des champs ou des chevrons du Inclure,
sinon la doc est impossible à écrire. A la rigueur, on retire la correction
dans la 2.0, mais je ne suis même pas sur.
Au moment où tu l'as introduit, on aurait pu considérer que c'était un
bug. Pourquoi on n'en a pas parlé, je l'ignore ; ce qui est clair
c'est que pour ma part j'ai remarqué que c'était bizarre, et je m'y
suis heurté à plusieurs reprises.
Alors maintenant de nombreux squelettes ont "contourné" ce bug, et
risquent de pêter si on le retire. C'est le cas avec l'exemple qui a
attiré l'oeil de Jacques (le favicon.ico.html), mais il y en a
certainement d'autres. Du coup le correctif risque de provoquer des
bugs assez difficiles à repérer sur des tas de sites. Ca ne me paraît
pas bon pour une version mineure (et même, pas génial pour une majeure
: à moins qu'on ne puisse offrir un détecteur de conflit ?).
-- Fil
On peut signaler un pb potentiel mais pas si c'est un pb effectif.
Par ailleurs, il faut distinguer les contournements qui ne seront pas gênés par la correction mêmes s'ils en deviennent superflus, et les vrais problèmes comme celui du favicon. Pas sûr qu'il y en ait tant que ça. Et ne pas corriger la 2.0 sur ce point mais corriger l'autre serait-il un si bon plan ? Quand la prochaine majeure sortira, les gros changements masqueront ces petits, il vaut mieux faire les petits changements dans les petites versions à mon avis.
Committo,Ergo:Sum
On peut signaler un pb potentiel mais pas si c'est un pb effectif.
Par ailleurs, il faut distinguer les contournements qui ne seront pas gênés
par la correction mêmes s'ils en deviennent superflus, et les vrais
problèmes comme celui du favicon. Pas sûr qu'il y en ait tant que ça.
En effet on ne sait pas. Donc on introduit un risque.
Comment faire pour savoir ? Je n'ai pas envie de casser mes sites pour cela.
Dans ton log de commit tu mentionnais les crayons (la balise #EDIT{})
; celle-ci précisément a été conçue à partir ce "bug" 
de manière à
ce que class="#EDIT{chapo} chapo" donne class="chapo" si les crayons
ne sont pas actifs, et class="crayon article-chapo-1 chapo" s'ils le
sont. Avec ton correctif on va avoir une espace (class=" chapo") --
qui pête sous IE 5 Mac. Je ne dis pas que c'est bloquant, car on est
dans un cas super marginal (IE 5 et squelette prévoyant les crayons,
mais sans le plugin crayons). Mais c'est un exemple.
Et ne pas corriger la 2.0 sur ce point mais corriger l'autre serait-il un si bon
plan ? Quand la prochaine majeure sortira, les gros changements masqueront
ces petits, il vaut mieux faire les petits changements dans les petites
versions à mon avis.
C'est un peu le principe des versions mineures justement : ça doit
être une mise à jour sans douleur.
-- Fil
Alors là je m'insurge: quand on veut qu'un champ vide élimine un ou plusieurs caractères qui le suit, on DOIT utiliser l'écriture [(#BALISE).....a eliminer...]. D'ailleurs c'était obligatoire d'écrire ça pendant longtemps, c'est moi qui ait introduit la possibilité d'écrire #B{x} plutot que [(#B{x})] qui est très lourd, mais quand on tire sur la corde, faut pas s'étonner qu'elle pète même si elle a tenu un moment.
Committo,Ergo:Sum
Fil a écrit :
Dans ton log de commit tu mentionnais les crayons (la balise #EDIT{})
; celle-ci précisément a été conçue à partir ce "bug"
ce que class="#EDIT{chapo} chapo" donne class="chapo" si les crayons
ne sont pas actifs, et class="crayon article-chapo-1 chapo" s'ils le
sont. Avec ton correctif on va avoir une espace (class=" chapo") --
qui pête sous IE 5 Mac. Je ne dis pas que c'est bloquant, car on est
dans un cas super marginal (IE 5 et squelette prévoyant les crayons,
mais sans le plugin crayons). Mais c'est un exemple.
???
Il n'y a pas de nécessité à écrire comme ça
puisque [(#...) ] fait bien le truc correctement, non ?
Donc pourquoi avoir utilisé (et maintenant défendre) cet usage ?
JL
Ah non, je m'insurge encore une fois !
Un webmestre doit pouvoir mettre à jour une version mineure sans avoir à retester ses squelettes et à les corriger.
De ce point de vue cette correction ne peut pas être faite dans la version mineure 2.0.9.
Sur le fond, et pour la suite, je suis partagé quand à ce bug/fonctionnalité. Il faudra prendre le temps de quantifier l'impact. Je vois déjà, a priori, toutes les balises #CACHE{} en debut de squelette qui vont introduire une ligne vierge.
Cédric
(la balise #EDIT{}) ; celle-ci précisément a été conçue à partir ce "bug"
de manière à ce que class="#EDIT{chapo} chapo" donne class="chapo"Alors là je m'insurge
ça date du 12 janvier 2006
on retrouvera peut-être une discussion à ce sujet dans les archives à
cette date (j'avoue que j'ai la flemme de chercher)
Il n'y a pas de nécessité à écrire comme ça
puisque [(#...) ] fait bien le truc correctement, non ?
entre
class="#EDIT{ps} ps"
et
class="[(#EDIT{ps}) ]ps"
j'ai choisi la notation la plus légère et esthétique.
Donc pourquoi avoir utilisé (et maintenant défendre) cet usage ?
parce que je croyais que c'était une feature volontaire d'esj (tu as
lu les mails précédents ?)
Mais tu te trompes de sujet : je donne les crayons comme *exemple* de
ce que le "correctif" d'esj a impacté.
-- Fil
Fil a écrit :
entre
class="#EDIT{ps} ps"
et
class="[(#EDIT{ps}) ]ps"
j'ai choisi la notation la plus légère et esthétique.
Indéniablement l'écriture est plus simple et plus claire,
mais la protubérance que ça suppose dans les règles d'écriture spip
ne m'apparait pas esthétique, elle*
Je ne sais pas à quoi la racrocher !
Donc pourquoi avoir utilisé (et maintenant défendre) cet usage ?
parce que je croyais que c'était une feature volontaire d'esj (tu as
lu les mails précédents ?)
Désolé, j'ai lu mais pas tout compris
PS : J'exprime en passant ici l'espoir que SPIP3
sortira avec une grammaire de référence,
décrite exhaustivement ?
JL
Sur le fond, et pour la suite, je suis partagé quand à ce
bug/fonctionnalité. Il faudra prendre le temps de quantifier l'impact. Je
vois déjà, a priori, toutes les balises #CACHE{} en debut de squelette qui
vont introduire une ligne vierge.
Je propose la chose suivante, qui consiste à tirer le meilleur de deux mondes :
On revert le "correctif", et on laisse l'imperfection dans les deux
branches (stable et dev), pour la syntaxe .html des boucles ; mais on
travaille afin que la nouvelle syntaxe .spip dont l'ébauche a été
proposée à Avignon soit *parfaite*.
Ainsi : on ne casse rien quand on fait une mise à jour, ce qui permet
d'éviter tout casse-tête du côté opérationnel ; mais à terme on a du
beau code propre.
-- Fil
Oui, c'est bien le sens de
http://trac.rezo.net/trac/spip/changeset/14172
mais le traducteur de l'ancienne à la nouvelle syntaxe que j'ai montré à Avignon va devoir sacrément se compliquer,
car la traduction d'un lexème ne va plus pouvoir se faire indépendamment du contexte, boulot supplémentaire et pénible que j'aurais préféré éviter.
Committo,Ergo:Sum
Oui, c'est bien le sens de
http://trac.rezo.net/trac/spip/changeset/14172
ah ok j'avais pas vu le commit ; c'est cool
mais le traducteur de l'ancienne à la nouvelle syntaxe que j'ai montré à
Avignon va devoir sacrément se compliquer,
car la traduction d'un lexème ne va plus pouvoir se faire indépendamment du
contexte, boulot supplémentaire et pénible que j'aurais préféré éviter.
Ca paraît logique en vérité : si la nouvelle syntaxe est là pour nous
débarrasser des problèmes de l'ancienne, il est normal que la
traduction prenne en compte ces problèmes de manière explicite. Sinon
ça signifierait que la nouvelle syntaxe ne corrige rien.
PS: j'ai regardé la vidéo mais je n'y comprends pas grand chose, à
part que l'écriture semble s'alourdir. Il faudra vraiment que dans ta
proposition tu expliques en détail les raisons des changements
proposés, ce qui te paraît optionnel et ce qui te paraît
indispensable.
-- Fil
PS: j'ai regardé la vidéo mais je n'y comprends pas grand chose, à
part que l'écriture semble s'alourdir.
Sans les abréviations oui, mais quand on les applique ce n'est pas le cas,
il y a même des fois où le squelette maigrit.
Le seul problème est que le traducteur risque de ne pas pouvoir appliquer les abréviations
aussi souvent qu'il le pourrait précisément à cause de la mauvaise conception de l'ancienne syntaxe.
Si un squelette est écrit:
<BOUCLE1(RUBRIQUES)
><BOUCLE2(ARTICLE)....
les abréviations pourront s'appliquer, mais en toute rigueur pas dans
<BOUCLE1(RUBRIQUES)>
<BOUCLE2(ARTICLE)....
alors que vraisemblablement l'intention est la même.
Je songe à un option "ne pas tenir compte des séparateurs après le > des constructions SPIP" dans ce traducteur.
Il faudra vraiment que dans ta
proposition tu expliques en détail les raisons des changements
proposés, ce qui te paraît optionnel et ce qui te paraît
indispensable.
Le problème de cette vidéo (mais ce n'est pas la faute d'Alexandra, que je remercie au passage déjà pour ça) est qu'on n'entend pratiquement pas les questions de la salle, ce qui n'aide pas à comprendre tout ce que je dis. De toutes façons je compte refaire cet exposé à d'autres occasions, en l'améliorant et l'amendant suite aux remarques qui ont été faites. Si effectivement on entérine un changement aussi important, il faudra que je me planifie un tour de France des apéros SPIP pour l'expliquer.
Committo,Ergo:Sum
Si
effectivement on entérine un changement aussi important, il faudra que je me
planifie un tour de France des apéros SPIP pour l'expliquer.
O l'excuse pour un boire un coup à l'oeil
;p
cam.lafit@azerttyu.net a écrit :
Si
effectivement on entérine un changement aussi important, il faudra que je me
planifie un tour de France des apéros SPIP pour l'expliquer.O l'excuse pour un boire un coup à l'oeil
;p
Pas besoin d'un si grand changement pour boire des coups un peu partout... croyez moi 
J'espère que Emmanuel a du temps, parce qu'on a décidé de faire un apéro SPIP dans toutes les villes de plus de 40 000 habitants... et il y en a pas mal !
(bon OK, c'est pas vrai...)