Spip et les normes

Salut,

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...

Merci

@+

--
         \\\|///
       \\ - - //
        ( @ @ )
----oOOo--(_)-oOOo---------------

   Jean-Luc GRELLIER
   (->Netjl<-)

   ICQ: 117061113

   netjl@ouvaton.org
   http://weo.ouvaton.org

---------------Ooooo-------------
                ( )
       ooooO ) /
       ( ) (_/
        \ (
         \_)

Salut,

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,

As-tu essayé les squelettes par défaut ? Ils répondent déjà à ce besoin.

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...

Oui, il y a deux problèmes en fait :
- certains raccourcis (comme les {{{intertitres}}}) ne génèrent pas du
HTML "correct" ;
- une mauvaise utilisation des raccourcis (par exemple inverser la
fermeture du {{gras}} et de l'{italique}) entraîne aussi un mauvais HTML
car les
erreurs des rédacteurs ne sont pas détectées par SPIP

Le deuxième problème tient à mon avis de l'auto-discipline : si les
rédacteurs sont sensibilisés, il n'est pas difficile pour eux de se
tenir à quelques règles simples. Le premier problème est à résoudre
dans SPIP :wink:

a+

Antoine.

Bonjour,

Le lundi, 24 mars 2003, à 15:41 Europe/Paris, Antoine a écrit :

Oui, il y a deux problèmes en fait :
- certains raccourcis (comme les {{{intertitres}}}) ne génèrent pas du
HTML "correct" ;

Effectivement, j'ai contourné le pb avec un filtre mais il faut que les rédacteurs sautent une ligne avant et après l'intertitre :

function bug_inter($texte) {
   $texte = ereg_replace('<p class="spip"> &nbsp;<h3','<h3',$texte);
   $texte = ereg_replace('</h3><br> </p>','</h3>',$texte);
   return $texte;
}

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 ?

Cordialement

--
Jean-Luc

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...

Merci, cordialement

---
Patrice

---

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

Je suis partisan de laisser comme c'est :wink:

-- Fil

Hello,

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 ...

-Nicolas

--
Nicolas "Brush" HOIZEY
  Free PHP projects http://www.phpheaven.net
Veille tous azimuts http://www.gasteroprod.com
         Clever Age http://www.clever-age.com

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 :wink:

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 ?

Merci, cordialement

---
Patrice

---

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 :wink:

Oui effectivement ; pour laisser le choix aux webmasters qui
voudraient valider CSS, "l'option rajoutée" serait à mon avis
bienvenue.

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. :wink:

Amicalement

Antoine.

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. :wink:

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 :slight_smile:

Cordialement

---
Patrice

---

On Mon, 24 Mar 2003 16:27:44 +0100, Jean-Luc Béchennec
<jean-luc.bechennec@tiscali.fr> wrote:

Effectivement, j'ai contourné le pb avec un filtre mais il faut que les
rédacteurs sautent une ligne avant et après l'intertitre :

function bug_inter($texte) {
  $texte = ereg_replace('<p class="spip"> &nbsp;<h3','<h3',$texte);
  $texte = ereg_replace('</h3><br> </p>','</h3>',$texte);
  return $texte;

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 :slight_smile:

Cordialement

---
Patrice

---

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... :frowning:

A+

---
Patrice

---