Par respect de la netiquette, tous les contributeurs s'engagent à ne tenir ni propos insultants ni propos infamants envers un tiers.
Merci d'avance à tous et ... bonne pêche aux infos - (Les numéros IP sont conservés.)
  » Sujet: iXprim, le W3C et le webmaster son dans un bateau... |
pgilbert
Mod Developer    Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/4/20 à 10:42 |
Pour faire suite au débat lancé par Tavnos sur le respect des
standards du W3C dans iXprim, je me permet de lancer un nouveau
débat/suggestions en parallèle puisqu'un peu en relation avec
le sujet.
L'une des particularité d'iXprim, c'est qu'il permet la
création de thèmes personnalisés de manière
complètement visible (cf. texte de présentation en une du
site). Ce système est bien évidement pratique et une grande
réussite. Toutefois, certaines imperfections pourraient êtres
corrigés pour rendre les réalisations des webmasters encore
plus faciles, souples et complètes.
1 - Le DOCTYPE
Le DOCTYPE, qui, comme son nom l'indique, défini le type de document
établi est intégré par iXprim par le script
functions.php. En 1.0, le doctype n'est pas intégré, en 1.x,
il est en XHTML 1.0 transitional. Pour les versions futures, certains
souhaiteraient (on est au moins 2) du XHTML 1.1. Tout ceci est très
bien puisque Trollix semble vouloir évoluer dans ce sens
(peut-être pas du XHTML 1.1 mais en tous cas, évoluer vers la
standardisation).
Toutefois, un webmaster peut souhaiter, et c'est son droit, ne pas utiliser
le XHTML et donc vouloir choisir lui même le DOCTYPE de son
thème. Or, il ne le peut donc pas autrement qu'en rentrant dans le
code PHP d'iXprim, ce qui n'est pas très pratique on le sait,
lorsque l'on veut installer une nouvelle version.
2 - Les balises < html >
De la même manière que le DOCTYPE, les balises < html >
d'ouverture et de fermeture, ne doivent pas être
intégrées aux fichiers réalisés par le
webmaster. Un peu contradictoire avec le fait qu'iXprim permette une mise
en page complètement wysiwyg. Combien de débutant se sont
fait avoir et ont présenté des réalisations dans
lesquels on retrouvait deux fois les balises < html > ? Combien sont
ceux qui ont un message d'erreur affiché par leur éditeur
html à chaque ouverture de leur page de thème leur signifiant
que celle-ci ne contient pas d'information d'encodage ? Finalement je fini
par me demander. Pourquoi est-il nécessaire que ce soit iXprim qui
insère ces balises ?
3 - L'en-tête
Là encore, tout est construit par iXprim. Du moins, en remplacement
et en ajout d'après ce que le webmaster à
inséré dans sa page. Mais une fois de plus, comment
personnaliser ? À part activer ou désactiver les tags TITLE,
META et JavaScript, que puis-je faire ? Pas grand chose... Et iXprim
insère des balises meta que je ne peux pas personnaliser.
Je veux changer l'encodage : je peux pas. L'auteur ? Il reprend
automatiquement le nom du site mais c'est pas forcément lui
l'auteur... Le copyright pareil... etc.
Pourquoi ne pas limiter la construction de l'en-tête au remplacement
des balises personalisable au niveau de l'administration ? Ou alors
pourquoi ne pas carrément faire évoluer la gestion des metas
dans l'administration. Actuellement elle se limite à deux
informations (plus le footer) stockées en base et dans u fichier
cache. Cela laisserai pleinement la possibilité à
l'utilisateur de choisir ces informations tout en lui en proposant
certaines de base. Bien entendu, une information en meta serait
imposées (generator) au même titre que l'affichage du tag de
signature.
En plus, un en-tête comprend le titre, les metas, les liens css, les
liens rss et les scripts. Pourquoi les liens RSS sont ajoutés au tag
meta ? Si je ne souhaite pas proposer de RSS sur mon site et donc souhaite
désactiver les liens comment faire ? Pourquoi ne pas ajouter un tag
{ RSS } à insérer dans l'en-tête des
thèmes ?
4 - Les feuilles de styles
Ah, les feuilles de style d'iXprim... Pas très compliqué
puisqu'il suffit d'un fichier CSS (style.css) à placer en lien dans
son fichier thème. MAIS ! Ah bah oui, il y a un "mais" sinon je n'en
parlerai pas 
- D'abord il faut bien penser à mettre des guillemets aux images
appelés dans la feuille de style puisque iXprim en a besoin pour les
repérer pour corriger leur chemin d'accès (j'ai l'impression
de rédiger une doc là...  ). Au passage je ne
suis pas certain que tous les éditeurs CSS wysiwyg acceptent les
guillemets dans un champs de saisie.
- Et comment je fais si je veux plusieurs feuille de style ? Et oui, iXprim
ne déplace dans le répertoire cache, QUE la feuille de style
qui s'appelle "style.css" si je ne m'abuse. Et si ma feuille n'est
défini que pour un seul media et pas tous ? Et bien, il ne la
déplace pas.
Mais au fait, pourquoi il déplace la feuille de style en cache
iXprim ? À quoi ça sert d'avoir une feuille de style en cache
plutôt que dans le répertoire du thème ? Pour garder le
lien entre la page mise en cache et ladite feuille de style ? Mais si
iXprim est capable de modifier le chemin vers les images dans les fichiers
du thèmes, il devrait être capable de modifier le chemin vers
les feuilles de style également. Ca semble plus logique puisque les
images et les styles s'occupent de la mise en forme et l'habillage des
pages, ils devraient rester ensemble. Et puis ça réglerai les
remarques expliquées ci-dessus. Du coup, je peux insérer
plusieurs feuilles de style dans mon thème, et en plus, plus besoin
de faire attention au guillemets dans l'appel des images dans les fichiers
css.
Ce message est un peu long... (vous êtes toujours là ?) En
tous cas, il rejoint la volonté de faire évoluer iXprim, au
même titre que les suggestions récentes de Tavnos. Je suis
d'accord que c'est important de respecter les standards du W3C mais je
souhaiterai qu'en parallèle, iXprim respecte les souhaits et le
travail du wemaster. Puisque le (X)HTML permet beaucoup de chose, il ne
faut pas qu'iXprim mette des bâtons dans les roues aux webmasters et
leur laisser plus de libertés. Et je pense qu'il faut que les
chaînes se délient dès à présent
plutôt que lorsque de futurs nouveaux utilisateurs se rendront compte
de ces limites et finalement râleront en taxant iXprim de mauvais CMS
alors que ce n'est pas le cas.
Je terminerai donc par la maxime du jour et après je vais bosser
parce que ça fait déjà plus d'une heure que je suis
sur ce post 
iXprim doit s'adapter au webmaster, tout comme le webmaster doit s'adapter
à iXprim. | | Out of iXprim project... |
|
|
|
Goubs
Béta-testeur    Messages: 118 Inscrit(e) le: 2004/4/30 Statut: Déconnecté(e)
|
Posté le 2006/4/20 à 13:12 |
Bonjour,
je rajouterais juste une précision concernant les feuilles de style.
Actuellement ixprim gere plusieurs feuille de style pusiqu'il prend en
compte aussi chaque css associé aux modules.
La limitation que je vois concernant les css c'est le fait de ne pas
pouvoir gérer le css associé à l'éditeur
(TinyMCE ou FckEditor). J'ai proposé ici de petites modifications
pour régler ce problème.voir ce post
Le fait de mettre les css en cache ne me gene pas particulierement.
Christian |
|
trollix
Core Developer    Messages: 2732 Inscrit(e) le: 2003/1/14 Statut: Déconnecté(e)
|
Posté le 2006/4/24 à 22:27 |
pgilbert a
écrit:
1 - Le DOCTYPE
Le DOCTYPE, qui, comme son nom l'indique, défini le type de document
établi est intégré par iXprim par le script
functions.php. En 1.0, le doctype n'est pas intégré, en 1.x,
il est en XHTML 1.0 transitional. Pour les versions futures, certains
souhaiteraient (on est au moins 2) du XHTML 1.1. Tout ceci est très
bien puisque Trollix semble vouloir évoluer dans ce sens
(peut-être pas du XHTML 1.1 mais en tous cas, évoluer vers la
standardisation).
Toutefois, un webmaster peut souhaiter, et c'est son droit, ne pas utiliser
le XHTML et donc vouloir choisir lui même le DOCTYPE de son
thème. Or, il ne le peut donc pas autrement qu'en rentrant dans le
code PHP d'iXprim, ce qui n'est pas très pratique on le sait,
lorsque l'on veut installer une nouvelle version.
Exact. Celà devrait pouvoir être fait dans le thème. Je
pense que dans la mesure ou le webmaster sait ce qu'il veut et qu'il veut
rentrer lui-même son doctype, il devrait être capable de
customiser lui-même le fichier theme.php de son propre thème.
C'est dans cette voie qu'il faudrait aller. c'est à dire donner la
possibilité au theme.php de mettre lui-même le doctype. Ce
n'est pas le cas aujourd'hui, mais c'est une bonne idée que je
garde. merci à toi Pierre. C'est adopté.
2 - Les balises < html >
De la même manière que le DOCTYPE, les balises < html >
d'ouverture et de fermeture, ne doivent pas être
intégrées aux fichiers réalisés par le
webmaster. Un peu contradictoire avec le fait qu'iXprim permette une mise
en page complètement wysiwyg. Combien de débutant se sont
fait avoir et ont présenté des réalisations dans
lesquels on retrouvait deux fois les balises < html > ? Combien sont
ceux qui ont un message d'erreur affiché par leur éditeur
html à chaque ouverture de leur page de thème leur signifiant
que celle-ci ne contient pas d'information d'encodage ? Finalement je fini
par me demander. Pourquoi est-il nécessaire que ce soit iXprim qui
insère ces balises ?
Vrai également. Adopté.
3 - L'en-tête?
Il est possible de modifier la variable $moremetas dans la fonction
themelayout de theme.php. Celà ne peut-il suffire ? Faut-il une
interface d'admin spécifique ?
4 - Les feuilles de styles
- D'abord il faut bien penser à mettre des guillemets aux images
appelés dans la feuille de style puisque iXprim en a besoin pour les
repérer pour corriger leur chemin d'accès (j'ai l'impression
de rédiger une doc là... ). Au passage je ne
suis pas certain que tous les éditeurs CSS wysiwyg acceptent les
guillemets dans un champs de saisie. Ceci peut être modifié. C'est par
commodité de codage et pour être certain de bien remplacer les
chemins dans le css que je me suis basé sur les double quotes ". On
eput, si ça aide utiliser les '. Je peux rajouter ça
maintenant au code, sachant que jusqu'à aujourd'hui ce genre de
chose n'était pas prioritaire.
-Et comment je fais si je veux plusieurs feuille de
style ? Il ya un répertoire
dans le theme qui s'appelle styles. on y dépose ici des feuilles de
styles dédiées à chaque module, qui s'ajoutent
à la feuille de style par défaut style.css. Il suffit de
créer sa feuille de style et de la nommer du [nom_module].css en lla
mettant dans ce répertoire. Voir le thème ixprim9999ff pour
exemple.
Et oui, iXprim ne déplace dans le répertoire cache, QUE la
feuille de style qui s'appelle "style.css" si je ne m'abuse. Et si ma
feuille n'est défini que pour un seul media et pas tous ? Et bien,
il ne la déplace pas.
Mais au fait, pourquoi il déplace la feuille de
style en cache iXprim ? À quoi ça sert d'avoir une feuille de
style en cache plutôt que dans le répertoire du thème ?
Pour garder le lien entre la page mise en cache et ladite feuille de style
?
Non, pas entre la page et la feuile: La mise en cache est nécessaire
pour mettre les bon chemins des url contenues dans les css ou des images
par exemple sur les tags url("image.gif").
Mais si iXprim est capable de modifier le chemin vers
les images dans les fichiers du thèmes, il devrait être
capable de modifier le chemin vers les feuilles de style également.
Voir au dessus. le pb n'est pas le chemin de la feuille de style dans la
page, mais le chemin des tags images ou url contenus dans les feuilles de
style. Sans ce problème à régler, il n'y aurait pas
besoin de mettre ne cache. Par contre, si tu as une solution... Sachant
quant même que tout thème doit être visible localement
dans son répertoire dans un éditeur wysiwyg. Ce qui ne serait
pas le cas si on pré-écrivait un chemin pour les liens images
ou tags url() dans les ces css...
Ca semble plus logique puisque les images et les styles
s'occupent de la mise en forme et l'habillage des pages, ils devraient
rester ensemble.
logique, oui. La mise en oeuvre simplement n'est pas possible. voir
c-dessus la contrainte imposée parle wysiwyg.
Et puis ça réglerai les remarques
expliquées ci-dessus. Du coup, je peux insérer plusieurs
feuilles de style dans mon thème, et en plus, plus besoin de faire
attention au guillemets dans l'appel des images dans les fichiers
css.
On peut régler ces problèmes autrement, par le biais des tags
dans le theme.php par défaut. Quelles sont les css par exemples que
tu voudrais voir rajouter à style.css, et dans quel but ? hormis
peut-être les css de media, y'en a-t-il d'autres ?
iXprim doit s'adapter au webmaster, tout comme le
webmaster doit s'adapter à iXprim. Adopté..
Merci de tout coeur pour cette contribution qui fait avancer
énormément les choses. | HQCH - Hope Que ça Helpe
Celui qui vise à la perfection sera au-dessus de la
médiocrité, mais celui qui vise à la
médiocrité tombera plus bas encore. "Proverbe chinois" |
|
|
pgilbert
Mod Developer Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/4/25 à 08:58 |
trollix a
écrit:1 - Le
DOCTYPE
Exact. Celà devrait pouvoir être fait dans le thème. Je
pense que dans la mesure ou le webmaster sait ce qu'il veut et qu'il veut
rentrer lui-même son doctype, il devrait être capable de
customiser lui-même le fichier theme.php de son propre thème.
C'est dans cette voie qu'il faudrait aller. c'est à dire donner la
possibilité au theme.php de mettre lui-même le doctype. Ce
n'est pas le cas aujourd'hui, mais c'est une bonne idée que je
garde. merci à toi Pierre. C'est adopté.
YES !
trollix a
écrit:2 - Les balises <
html >
Vrai également. Adopté.
YES !
trollix a
écrit:3 -
L'en-tête?
Il est possible de modifier la variable $moremetas dans la fonction
themelayout de theme.php. Celà ne peut-il suffire ? Faut-il une
interface d'admin spécifique ?
$more_metas permet des ajouts mais pas des modifications de metas
intégrés par iXprim donc une interface d'admin plus
complète que l'existante serait grandiose. Mais bon, ça peut
passer au second plan, il y a d'autres priorités...
trollix a
écrit:iXprim doit s'adapter au
webmaster, tout comme le webmaster doit s'adapter à
iXprim. Adopté..
Merci de tout coeur pour cette contribution qui fait avancer
énormément les choses.
Bah de rien
j'sui là pour ça
P.S. : ma réponses sur les feuilles de style suivra dans un autre
post parce qu'on va finir par s'y perdre... | | Out of iXprim project... |
|
|
pgilbert
Mod Developer Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/4/25 à 09:38 |
trollix a
écrit:4 - Les feuilles de
styles
- D'abord il faut bien penser à mettre des guillemets aux images
appelés... Ceci peut
être modifié. C'est par commodité de codage et pour
être certain de bien remplacer les chemins dans le css que je me suis
basé sur les double quotes ". On eput, si ça aide utiliser
les '. Je peux rajouter ça maintenant au code, sachant que
jusqu'à aujourd'hui ce genre de chose n'était pas
prioritaire.
Personnellement cela ne me gène pas puisque je le sais, mais je
pense aux petits nouveaux qui se font souvent avoir avec ça
trollix a
écrit:-Et comment je fais si je
veux plusieurs feuille de style ? Il
ya un répertoire dans le theme qui s'appelle styles. on y
dépose ici des feuilles de styles dédiées à
chaque module, qui s'ajoutent à la feuille de style par
défaut style.css. Il suffit de créer sa feuille de style et
de la nommer du [nom_module].css en lla mettant dans ce répertoire.
Voir le thème ixprim9999ff pour exemple.
Ma demande n'était pas pour une feuille de style par module, chose
bien pratique, que j'utilise déjà, soit dit en passant. Il
faudrait pouvoir définir des feuilles de style par média et
encore mieux, des feuilles de style alternatives.
trollix a
écrit:Mais au fait, pourquoi il
déplace la feuille de style en cache iXprim ?
Non, pas entre la page et la feuile: La mise en cache est nécessaire
pour mettre les bon chemins des url contenues dans les css ou des images
par exemple sur les tags url("image.gif").
Justement ! Si la feuille de style restait à sa place, il n'y aurait
pas besoin de corriger les url des images puisque les fichiers
appelés dans une feuille de styles sont soit absolus soit relatifs
à elle même.
trollix a
écrit:Mais si iXprim est capable
de modifier le chemin vers les images dans les fichiers du thèmes,
il devrait être capable de modifier le chemin vers les feuilles de
style également.
Voir au dessus. le pb n'est pas le chemin de la feuille de style dans la
page, mais le chemin des tags images ou url contenus dans les feuilles de
style. Sans ce problème à régler, il n'y aurait pas
besoin de mettre ne cache. Par contre, si tu as une solution... Sachant
quant même que tout thème doit être visible localement
dans son répertoire dans un éditeur wysiwyg. Ce qui ne serait
pas le cas si on pré-écrivait un chemin pour les liens images
ou tags url() dans les ces css...
C'est là que je ne te suis plus trollix. J'ai certains sites sous
ixprim qui tournent sans mise en cache de la feuille de style. Je l'appelle
directement dans le répertoire de mon layout et ça fonctionne
très bien. :
- je peux toujours éditer en wysiwyg
- les images sont appelée en relatif et donc pas besoin de corriger
les url
- pas besoin de recharger le theme pour mettre à jour (de toutes
façons c plus nécessaire) puisque le fichier n'est pas mis en
cache
Donc plutôt que de modifier les url des fichiers liés dans la
feuille de style, pourquoi ne pas modifier l'url de ladite feuille de style
dans la copie en cache des fichiers layout qui y font
référence ? Ca me semble beaucoup plus simple... Non ? J'ai
omis un élément ?
trollix a
écrit:On peut régler ces problèmes
autrement, par le biais des tags dans le theme.php par défaut.
Quelles sont les css par exemples que tu voudrais voir rajouter à
style.css, et dans quel but ? hormis peut-être les css de media, y'en
a-t-il d'autres ?
Comme je le disais plus haut, les feuilles de style alternatives. Bon, je
pense pas que ca soit nécessaire car peu les utilisent. Mais par
média, ca me semble indispensable. D'autant plus que dans le cas de
ixpnews par exemple, cela éviterai de gérer les impressions
avec un fichier php...
| | Out of iXprim project... |
|
|
trollix
Core Developer Messages: 2732 Inscrit(e) le: 2003/1/14 Statut: Déconnecté(e)
|
Posté le 2006/4/25 à 20:37 |
pgilbert a
écrit:Donc plutôt que de modifier les url des
fichiers liés dans la feuille de style, pourquoi ne pas modifier
l'url de ladite feuille de style dans la copie en cache des fichiers layout
qui y font référence ? Ca me semble beaucoup plus simple...
Non ? J'ai omis un élément ?
Adopté. C'est beaucoup plus simple, tu as raison. | HQCH - Hope Que ça Helpe
Celui qui vise à la perfection sera au-dessus de la
médiocrité, mais celui qui vise à la
médiocrité tombera plus bas encore. "Proverbe
chinois" |
|
|
pgilbert
Mod Developer Messages: 653 Inscrit(e) le: 2004/3/25 Statut: Déconnecté(e)
|
Posté le 2006/4/26 à 07:21 |
trollix a
écrit:Adopté. C'est beaucoup plus simple, tu
as raison.
YEEEEESSSSSSS !!! 
Alors là on a fait un grand pas vers la simplicité
d'utilisation et la possibilité de personnalisation des themes...
Merci Trotro | | Out of iXprim project... |
|
|
| |  |
|
© powered by Ixprim 1.3 rc1 | E-mail: trollix at trollix.com | Contact | Rapports de bug | Feed XML des News | Feed XML du Forum
