Salut,
je viens de passer la 1.0.2 en archives, pour que l'on travaille sur la
1.0.3 ;
* j'y ai mis une nouvelle version de inc_texte.php3,
- censée être plus "clean" en ce qui concerne la conformance W3C,
- n'affiche plus les codes <HTML></HTML> du raccourci SPIP,
- et gère les <hr /> automatiques à partir de 4 tirets en début de ligne
(---- ou ____)
-- Fil
J'ai fait des modifs dans cette version. Sur les includes
entre autres, et puis j'ai terminé l'adaptation de propre().
Quand même un souci : ce ~#{#@^{^#@ de validator dit que
les tags img ne sont pas fermés, alors qu'il y a bien :
<img src='puce.gif' alt='' ... />
Il faut reprendre tous les fichiers, enfin il vaut mieux.
a+
Fil wrote:
Quelle version de HTML ou XHTML ?
1. Il faut un DOCTYPE
2. En fonction de ce DOCTYPE se décline une grammaire qu'il faut respecter.
Cela ne sert à rien de fermer une balise IMG si ce n'est pas prévu dans le DOCTYPE comme c'est le cas pour HTML 4.01
Les fermer c'est très bien pour XHTML 1.0, donc première chose à faire, choisir son DOCTYPE. Je conseille le XHTML, car comme c'est du XML, si les balises sont bien identifiées par la suite cela permet de travailler le contenu à coup de XSLT.
D'autre part, rien ne sert de faire un moteur de génération correct si les gabarits ne sont pas corrects dès le départ d'où mes questions précédentes, hier...
@ Karl Dubost (karl@la-grange.net) :
D'autre part, rien ne sert de faire un moteur de génération correct
si les gabarits ne sont pas corrects dès le départ
A ceci près que les "squelettes" proposés sont des trucs par défaut, mais
qu'on espère que chacun va écrire ses propres squelettes. Donc, pour moi, il
est plus important de bosser sur le moteur que sur le squelette.
-- Fil
Je suis d'accord mais pour tester la validité du contenu, il faut utiliser un gabarit conforme sinon vous ne pourrez rien tester. Par exemple, le fait de choisir entre <img /> et <img> dépendra du DOCTYPE du document donc du gabarit dans votre architecture...
Donc la question reste entière. Quelquesoit le moteur que tu composes pour générer le code, il faut savoir quelle grammaire tu vas appliquer.
Donc votre choix messieurs ???
A moins de faire un outil adaptif (ce qui serait intelligent) qui regarde le doctype et adapte le process en fonction de celui-ci et qui s'il y en a pas le dit, et dit de corriger les gabarits 
Coucou,
Quelle version de HTML ou XHTML ?
1. Il faut un DOCTYPE
2. En fonction de ce DOCTYPE se décline une grammaire qu'il faut respecter.Cela ne sert à rien de fermer une balise IMG si ce n'est pas prévu
dans le DOCTYPE comme c'est le cas pour HTML 4.01
Heu, tu veux dire qu'il y a des versions qui acceptent <br /> et <hr />
mais pas <img /> ??? Qu'est-ce que c'est que cette logique de ~#[[~|¤:!
;))
Les fermer c'est très bien pour XHTML 1.0, donc première chose à
faire, choisir son DOCTYPE. Je conseille le XHTML, car comme c'est du
XML, si les balises sont bien identifiées par la suite cela permet de
travailler le contenu à coup de XSLT.
XSL pour SPIP, on n'en a pas trop besoin a priori.
Mais ce n'est pas à nous de choisir dans quelle norme est écrit
le HTML. C'est à l'auteur des squelettes, même si les squelettes
fournis par défaut sont effectivement compatibles avec _une_
norme. Il n'y a pas moyen de faire quelque chose qui soit compatible
avec *toutes* les normes récentes (HTML 4.x, XHTML 1.x...) ? Ne
serait-ce qu'au niveau des <p>, <br>, <hr>, <img>, <a>, <font>,
vu que c'est ce qui est généré dans propre() ?
D'autre part, rien ne sert de faire un moteur de génération correct
si les gabarits ne sont pas corrects dès le départ d'où mes questions
précédentes, hier...
Les deux vont ensemble et rien n'empêche de faire les deux en même
temps, non ?
Amicalement,
Antoine.
Coucou,
Quelle version de HTML ou XHTML ?
1. Il faut un DOCTYPE
2. En fonction de ce DOCTYPE se décline une grammaire qu'il faut respecter.Cela ne sert à rien de fermer une balise IMG si ce n'est pas prévu
dans le DOCTYPE comme c'est le cas pour HTML 4.01Heu, tu veux dire qu'il y a des versions qui acceptent <br /> et <hr />
mais pas <img /> ??? Qu'est-ce que c'est que cette logique de ~#[[~|¤:!
;))
non, non, je voulais dire que à partir du moment où l'on choisit une syntaxe autant si plier.
<br /> <hr /> et <img /> tout cela est consistant même en HTML 4.01 bien que jamais personne ne le fasse. Par contre, sans DOCTYPE, cela ne signifie plus rien.
Parce-que le vocabulaire est dépendant du DOCTYPE choisi. Par exemple en XHTML entre Strict et Transitional, il ya des différences sur les attributs notamment.
XML, si les balises sont bien identifiées par la suite cela permet de
travailler le contenu à coup de XSLT.XSL pour SPIP, on n'en a pas trop besoin a priori.
A priori, 
Cela veut dire que si quelqu'un veut faire tourner un feuille XSLT pour faire du RSS or whatever... il peut le faire 
si la syntaxe est correcte (soit du XML).
Mais ce n'est pas à nous de choisir dans quelle norme est écrit
le HTML. C'est à l'auteur des squelettes, même si les squelettes
fournis par défaut sont effectivement compatibles avec _une_
norme. Il n'y a pas moyen de faire quelque chose qui soit compatible
avec *toutes* les normes récentes (HTML 4.x, XHTML 1.x...) ? Ne
serait-ce qu'au niveau des <p>, <br>, <hr>, <img>, <a>, <font>,
vu que c'est ce qui est généré dans propre() ?
Si on doit pouvoir faire quelquechose... par contre si vous modifiez les gabarits à chaque release, je ne vais pas pouvoir vous fournir des gabarits conformes et ensuite pouvoir évoluer à partir de ceux-ci. J'ai bien compris que le maquettiste aurait le choix après de les modifier et heureusement, mais autant qu'il parte avec quelquechose de propre.
ET autant faire du lobbying pour avoir quelquechose qui aille vers une qualité de son contenu. (pas rédactionnelle mais balise)
Karl Dubost wrote:
<br /> <hr /> et <img /> tout cela est consistant même en HTML 4.01
bien que jamais personne ne le fasse. Par contre, sans DOCTYPE, cela
ne signifie plus rien.
Mea culpa, en forçant le document en HTML 4.01 Transitional et XHTML,
ça passe (enfin, il y a d'autres choses qui ne passent pas :-)).
Parce-que le vocabulaire est dépendant du DOCTYPE choisi. Par exemple
en XHTML entre Strict et Transitional, il ya des différences sur les
attributs notamment.
Pour propre(), il faudra donc trouver un subset commun entre HTML 4
et XHTML (en admettant qu'on oublie HTML < 4).
A priori,
Cela veut dire que si quelqu'un veut faire tourner un feuille
XSLT pour faire du RSS or whatever... il peut le faire
syntaxe est correcte (soit du XML).
Justement, un intérêt de SPIP est tout de même de se passer
du XSL pour le passage contenu->présentation. Pour l'exemple
du RDF, SPIP contient précisément un squelette backend.html
qui génère le XML correspondant (même si l'extension n'est
pas très en rapport ;-)). Ci-joint. Et un squelette SPIP
peut très bien générer tout à fait autre chose, par exemple
du Latex (cf. une autre discussion).... Le moteur de SPIP
ne se soucie absolument pas de la sémantique des documents
produits.
C'est mieux à mon sens que de prendre une présentation et
d'essayer d'y récupérer le contenu, via XSL, pour créer
une autre présentation.
Si on doit pouvoir faire quelquechose... par contre si vous modifiez
les gabarits à chaque release,
Heu, a priori, non, sauf si j'ai raté une modif ?
J'ai bien compris que le maquettiste aurait le choix après
de les modifier et heureusement, mais autant qu'il parte avec
quelquechose de propre.
Oui, c'est clair.
a+
Antoine.
backend.html (853 Bytes)
Heu, a priori, non, sauf si j'ai raté une modif ?
OK je poursuis mon clean-up des gabarits donc... 
<B_meme_rubrique>
<P>
<B>DANS LA MEME RUBRIQUE :</B>
<BOUCLE_meme_rubrique(ARTICLES){id_rubrique}{doublons}{0,10}{par hasard}>
<BR />
<IMG SRC="puce.gif" /> <A HREF="#URL_ARTICLE">#TITRE</A>
</BOUCLE_meme_rubrique>
</p>
</B_meme_rubrique>
<B_Mots_Cles>
<P>
<B>THEMES ABORDES :</B>
<BOUCLE_Mots_Cles(MOTS){id_article}{par titre}>
<BR />
<B>#TITRE</B>
<BOUCLE_meme_mot(ARTICLES){id_mot}{doublons}{0,10}{par hasard}>
<BR />
<IMG SRC="puce.gif" /> <A HREF="#URL_ARTICLE">#TITRE</A>
</BOUCLE_meme_mot>
</BOUCLE_Mots_Cles>
Quelqu'un peut m'expliquer pourquoi B_Mots_Cles n'est pas refermé ?
@ Karl Dubost (karl@la-grange.net) :
Quelqu'un peut m'expliquer pourquoi B_Mots_Cles n'est pas refermé ?
C'est dans la doc là:
http://www.uzine.net/article898.html
<Bn>
Code HTML optionnel avant
<BOUCLEn(TYPE){critère1}{critère2}...{critèrex}>
Code HTML + balises SPIP
</BOUCLEn>
Code HTML optionnel après
</Bn>
Code HTML alternatif
<//Bn>
Le code optionnel avant (précédé de <Bn>) n'est affiché que si la boucle
contient au moins une réponse. Il est affiché avant les résultats de la
boucle.
Le code optionnel après (terminé par </Bn>) n'est affiché que si la boucle
contient au moins une réponse. Il est affiché après les résultats de la
boucle.
Le code alternatif (terminé par <//Bn>) est affiché à la place de la boucle
(et donc également à la place des codes optionnels avant et après) si la
boucle n'a trouvé aucune réponse.
-- Fil
Je pense qu'il faut que SPIP soit cappable de générer plusieurs
type de DOCTYPE.
Cela devrait être une option de configuration du site.
L'administrateur choisit le DOCTYPE de son site, et la fonction
propre de SPIP génère les tags corrects.
L'intérêt est de laisser à tout le monde le plus de liberté.
Pour implémenter cela, une solution consiste à mettre les balises
dans un tableau:
$balises["XHTML-1.0"]["Line_Break"] = "<br/>"
$balises["XHTML-1.0"]["Paragraph_start"] = "<p>"
$balises["XHTML-1.0"]["Paragraph_end"] = "</p>"
$balises["HTML-3.2"]["Line_Break"] = "<br>"
$balises["HTML-3.2"]["Paragraph_start"] = "<p>"
$balises["HTML-3.2"]["Paragraph_end"] = ""
Cette solution nous permet de :
- ne pas modifier l'aspect des sites existants,
qui sont, par défaut et sans le savoir, conforme
à DOCTYPE HTML 3.2 ou HTML 2.0.
- intégrer les futures version de XHTML
- produire d'autres DTD XML à l'aide de SPIP.
Michaël
Toujours à me battre avec le gabarit articles.html
En fait cela serait beaucoup plus simple si je le faisais de zéro. C'est impressionnant le nombre de tableaux qui ne servent à rien dans votre truc.
Cela rend au final le code illisible. J'ai détecté l'usage de certains en collant des border-width: 2px border-color: red
pour les mettre en évidence.
Cela dérange si je mets tout à plat ?
@ Michaël Parienti (parienti@parienti.org) :
$balises["XHTML-1.0"]["Line_Break"] = "<br/>"
$balises["XHTML-1.0"]["Paragraph_start"] = "<p>"
$balises["XHTML-1.0"]["Paragraph_end"] = "</p>"$balises["HTML-3.2"]["Line_Break"] = "<br>"
$balises["HTML-3.2"]["Paragraph_start"] = "<p>"
$balises["HTML-3.2"]["Paragraph_end"] = ""Cette solution nous permet de :
- ne pas modifier l'aspect des sites existants,
qui sont, par défaut et sans le savoir, conforme
à DOCTYPE HTML 3.2 ou HTML 2.0.
- intégrer les futures version de XHTML
- produire d'autres DTD XML à l'aide de SPIP.
OK. Stop le délire. Je propose qu'on essaie plutôt de mettre au point un
filtre général correspondant à votre DTD préférée.
Par exemple :
function w3c($texte){
eregi_replace("<br>","<br />",$texte);
... etc ...
return($texte);
}
Puis, dans le squelette, un truc du genre [(#TEXTE|w3c)] renverra le texte
au bon format. Sinon on va devenir fous
L'intérêt de cette approche, c'est qu'elle peut ensuite s'utiliser dans tous
les scripts php du monde. Peut-être que ça pourrait faire partie des
objectifs du W3C justement ?
-- Fil
Hmmm toujours pas compris la logique...
<Bn>
Code HTML optionnel avant
<BOUCLEn(TYPE){critère1}{critère2}...{critèrex}>Code HTML + balises SPIP
</BOUCLEn>Code HTML optionnel après
</Bn>Code HTML alternatif
<//Bn>
ou n = "_Mots_Cles" dans notre cas (en elevant le HTML pour rendre plus facile la lecture)
<B_Mots_Cles>
<BOUCLE_Mots_Cles(MOTS){id_article}{par titre}>
#TITRE
<BOUCLE_meme_mot(ARTICLES){id_mot}{doublons}{0,10}{par hasard}>
#URL_ARTICLE
#TITRE
</BOUCLE_meme_mot>
</BOUCLE_Mots_Cles>
Donc je ne vois pas la fermeture de
</B_Mots_Cles>
Le fait de réaliser un parser de texte correct n'est pas trop compliqué le tout dépend de ce que tu veux faire avec.
Je m'entends.
Par exemple:
Ce que je propose me semble plus évolutif et plus souple.
Cela permettrait à chacun de modififer plus simplement la
mise en page de son site, avec ses balises personnalisées,
en créant une nouvelle entrée dans le tableau $balises, ce
qui est plus simple que de modifier une fonction.
De plus, c'est l'administrateur du site qui choisit quel
ensemble de balises il souhaite utiliser (HTML3.2, XHTML,
ou balises personnalisées), et non plus le graphiste qui
devrait, dans ce que tu proposes, ajouter un filtre dans
chaque page.
Elle nécessite de modifier un peu la fonction propre, pour
y repérer les tags paragraphes fermant, je veux bien m'en
charger.
Cordialement
Michaël
Karl Dubost wrote:
Ensuite on peut complexifier mais je ne connais pas encore la syntaxe
de votre système. C'est à dire comment les auteurs doivent écrire.
Tu peux aller voir les raccourcis typographiques sur
http://www.uzine.net/SPIP_aide/aide_index.php3?aide=raccourcis
Grosso modo, c'est tout ce que fait propre().
C'est le premier point. Le second point est plus sur l'aspect
architecture du système que j'ai beaucoup de mal à comprendre surtout
le système de boucle sur vos gabarits actuels... cela a l'air super
compliqué pour quelquechose de relativement simple à l'origine et je
ne comprends pas pourquoi.
Non, le parsing et l'exécution des boucles sont dans inc-calcul.php3
à la racine. Ca représente un bout de code mais c'est pas si énorme,
compte tenu de ce que ça fait. Tout le reste, c'est la gestion des
contenus, l'interface, divers machins techniques, etc.
a+
Antoine.