J'a vu passé un message ce matin concernant un site dit "exemplaire" : http://openweb.eu.org.
Il est vrai que ce site respecte parfaitement les standards XHTML et CSS ce qui est top, de plus la gestion des squelettes se fait intégralement par les balises DIV (plus de tables) et un css béton. Mais ce site n'est pas sous spip.
J'ai traduit une page pour le faire fonctionner sous spip, et effectivement cela améliore considérablement la compatibilité des sites sous spip avec les standards, mais il demeure un pb : le code généré par spip au niveau des fichiers php n'est pas complètement conforme aux standards...
Est-ce que cela fait parti des futurs modifications de Spip, ou est-ce que quelqu'un a déjà fait un squelette totalement conforme aux standards ?
pour tout vous dire, cela m'arrangerai bien si quelqu'un avait quelquechose de déjà fait , car le boulot en vue d'en réaliser un de A à Z est énorme et je n'ai pas trop le temps...
Sinon quelqu'un saurait-il où est localisé la ou les fonctions qui traitent les raccourcis typographiques ?
Par ailleurs, on peut empêcher SPIP de traiter ces raccourcis en utilisant BALISE* mais peut-on réappliquer le traitement de SPIP via un filtre après avoir appliqué ses propres filtres ?
On Mon, 24 Mar 2003 15:35:24 +0100, "netjl@ouvaton.org"
<netjl@ouvaton.org> wrote:
Est-ce que cela fait parti des futurs modifications de Spip, ou est-ce
que quelqu'un a déjà fait un squelette totalement conforme aux standards ?
Dans le même ordre d'idée, on n'arrive apparemment pas à valider CSS2
les feuilles de style qui comportent des noms de classes avec
l'underscore du stype .spip_surligne, etc. Ces classes étant appelées
par inc_texte.php3 ou autres... à part reprendre à la main ces
fichiers, y-a-t-il à votre connaissance une manière de créer des
sortes d'alias... de substitutions... sans toucher au code Spip. De
façon à ce que quand .spip_surligne est appelé l'on puisse "traduire"
en .spipsurligne qui lui serait défini dans la feuille de style du
site. J'espère avoir été clair...
Dans le même ordre d'idée, on n'arrive apparemment pas à valider CSS2
les feuilles de style qui comportent des noms de classes avec
l'underscore du stype .spip_surligne, etc. Ces classes étant appelées
On ne peut pas inverser ce choix sans risquer de casser des sites existants
au moment de la mise à jour. Trois hypothèses :
- on casse ces sites, avec une grosse explication bien visible
- on laisse comme c'est
- on ajoute une option
Dans le même ordre d'idée, on n'arrive apparemment pas à valider
CSS2 les feuilles de style qui comportent des noms de classes avec
l'underscore du stype .spip_surligne, etc.
On ne peut pas inverser ce choix sans risquer de casser des sites
existants au moment de la mise à jour.
La "casse" sera plutôt légère et visible immédiatement, donc je pense
qu'elle serait la bienvenue dans ce cas précis ...
D'ailleurs, un truc pas mal serait que comme la base de données
peut-être mise à jour automatiquement lors d'un upgrade, on puisse
mettre des messages d'alerte. Comme ça, l'admin est forcément au
courant des changements ...
On Tue, 25 Mar 2003 11:46:50 +0100, Fil <fil@rezo.net> wrote:
On ne peut pas inverser ce choix sans risquer de casser des sites existants
au moment de la mise à jour. Trois hypothèses :
- on casse ces sites, avec une grosse explication bien visible
- on laisse comme c'est
- on ajoute une option
Je suis partisan de laisser comme c'est
Oui effectivement ; pour laisser le choix aux webmasters qui
voudraient valider CSS, "l'option rajoutée" serait à mon avis
bienvenue. Autrement en attendant, existe-il une manière de contourner
le pbm comme je le demandais dans mon post, sans toucher aux fichiers
Spip... du style substitution dans mes_ fonctions.php3 ou d'une autre
manière ?
On ne peut pas inverser ce choix sans risquer de casser des sites
existants
au moment de la mise à jour. Trois hypothèses :
- on casse ces sites, avec une grosse explication bien visible
- on laisse comme c'est
- on ajoute une option
On Tue, 25 Mar 2003 13:22:36 +0100 (CET), "Antoine" <antoine@rezo.net>
wrote:
Non, pas d'option pour corriger un bug, pitié. On cassera la compatibilité
un jour, si besoin est. En attendant, je ne pense que "valider les CSS"
soit vraiment une préoccupation majeure.
Non c'est sûr que ce n'est pas prioritaire comme évolution de Spip...
et c'est bien pour cela que j'aurais aimé un p'tit "contournement" en
attendant
Pour ce problème, j'ai cherché/remplacé tous les <p> en <div> et leurs
balises de fermeture dans le inc_texte.php3 ; cela à l'air ok sur les
mises en page et cela valide en 4.01 transitional... je vais peut-être
finalement faire mes modifs à la main y compris pour les classes css.
pas plus d'une quinzaine de minutes avec l'outil adapté... après tout
on ne change pas de version toutes les semaines
On Tue, 25 Mar 2003 23:21:38 +0100, Patrice <webmaster@ecoparis.org>
wrote:
Pour ce problème, j'ai cherché/remplacé tous les <p> en <div> et leurs
balises de fermeture dans le inc_texte.php3 ; cela à l'air ok sur les
mises en page
et ben non, j'ai parlé trop vite, cela fonctionne pour les {{{ mais
par ailleurs les div interfèrent sur les sauts de ligne...
