Ticket #1914 (closed idea: wontfix)
[Thème] Ajouter des classes depuis _public.php ?
| Reported by: | MathieuM | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | module:themes | Version: | 2.6.1 |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Bonjour,
Puisque la refonte des templates est au menu de Dotclear 2.7, une idée (*) me traverse l'esprit :)
Pourrait-on proposer aux créateurs de thèmes la possibilité d'ajouter (via le _public.php du thème par exemple) des classes à des éléments disponibles dans les tpl ?
Par exemple, ajouter la classe "pouet" à l'élément <h2 class="post-title"> ou à chaque "post-title" du thème ?
Pourquoi ? Pour la simple (et bonne ?) raison qu'il y a eu pas mal de discussions autour des framework CSS et qu'il serait super intéressant pour les thémeurs de pouvoir enrichir les tpl de classes provenant d'un framework CSS sans modifier les gabarits de Dotclear.
C'est déjà réalisable par javascript, mais je ne pense pas que ce soit la meilleure solution (est-ce que c'est pris en compte dans chaque navigateur ? est-ce que tout le monde active javascript par défaut ? etc...).
Z'en pensez quoi ?
(*) Merci de ne pas oublier mon incapacité à savoir si c'est techniquement réalisable ou non...
Change History
comment:2 Changed 12 years ago by Mirovinben
Perso je l'ai fait (et si j'y suis arrivé, d'autres devraient pouvoir y arriver aussi) via un marqueur de template kivabien dans le public.css de mes thèmes. Marqueur personnalisé/paramétré via le plugin myMeta.
Genre, pour post.html :
<body class="dc-post {{tpl:EntryMyMetaValue id="typePage" key="1"}}">
Rien empêche ensuite de personnaliser le <h2> qui suit le <body>
D'accord, ça empêche de proposer un thème full-CSS mais ça fonctionne chez moi depuis un bail...
comment:3 Changed 12 years ago by MathieuM
Replying to franck:
Y'a pas moyen d'utiliser des frameworks qui n'imposent pas une telle lourdeur dans le markup ?
Y'a toujours "moyen de", mais ça limite le champ des possibilités.
Vaudrait mieux utiliser des librairies Sass (ou Less) qui ont la courtoisie de s'adapter sans modification à la structure existante, non ? zenGrids est dans ce cas par exemple.
Tout le monde ne veut / peux pas prendre le temps de se familiariser à Sass / Less et consorts.
À mon sens, c'est à la "déco" (CSS et consort) de s'adapter à la structure et pas l'inverse.
Idéalement, je suis d'accord avec toi. Dans la pratique, c'est beaucoup de contraintes et c'est prendre, parfois, le risque de se passer de super outils qui n'en ont rien à faire de bien s'adapter à Dotclear :)
Replying to Mirovinben:
Perso je l'ai fait (et si j'y suis arrivé, d'autre devraient pouvoir y arriver aussi) via un marqueur de template kivabien dans le public.css de mes thèmes. Marqueur personnalisé/paramétré via le plugin myMeta.
Le problème, plus lourd que de devoir modifier un gabarit .html, c'est qu'il est impossible d'avoir un thème distribuable "prêt à l'emploi"... L'utilisateur final devra installer myMeta, le paramétrer correctement... et venir se plaindre qu'il n'y arrive pas :)
comment:4 Changed 12 years ago by franck
"limite le champs…" : euh, jusqu'à présent (et ça fait quelques années), il n'y a pas eu besoin de tels artifices (parce que c'en est, pour pallier la rigidité d'un framework) pour produire des thèmes qui tenaient parfaitement bien la route.
J'irai même plus loin : pourquoi "imposer" à tous ce qui est rendu nécessaire par un cas particulier ?
En ce qui concerne Sass/Less? et consorts, je pense que si on est prêt à s'investir dans l'apprentissage d'un framework alors on devrait l'être tout autant dans ce système. Essaie, une fois que tu y a goûté, tu auras du mal à le lâcher ;-)
Je n'appelle pas "super-outils" (c'est encore une fois mon propre point de vue) des frameworks qu'on intègre en bloc dans son design et qui imposent d'adapter tout le reste.
Quand à l'usage de myMeta, ce qui peut effectivement se révéler un problème pour la distribution, pourquoi ne pas intégrer tes propres templates qui transporteront tout ce dont tu auras besoin sans alourdir les autres thèmes ?
comment:5 Changed 12 years ago by franck
« Idéalement, je suis d'accord avec toi. Dans la pratique, c'est beaucoup de contraintes et c'est prendre, parfois, le risque de se passer de super outils qui n'en ont rien à faire de bien s'adapter à Dotclear :) »
J'ajouterai que si ces outils n'en ont rien à faire de DC, alors ils n'ont rien à y faire.
comment:6 follow-up: ↓ 8 Changed 12 years ago by Jean-Michel
Cela reste à confirmer et à retrouver mais il me semble par le passé avoir mis en place un _public.php de ce genre.
comment:7 Changed 12 years ago by MathieuM
Je respecte (beaucoup) ton avis et tout ton travail au cœur de Dotclear Franck, mais pour moi, je pense que tu as tord quand tu dis "J'ajouterai que si ces outils n'en ont rien à faire de DC, alors ils n'ont rien à y faire."
J'ai pas mal expérimenté de choses avec le framework Bootstrap. Impossible (ou alors je n'ai pas les compétences adéquates) de l'intégrer dignement sans toucher aux gabarits par défaut pour ajouter certaines classes. Pourtant c'est un excellent framework, populaire et il serait vraiment dommage de ne pas le proposer dans un thème pour Dotclear.
Modifier tous les gabarits pour intégrer à plein régime Bootstrap ? Ce n'est franchement pas la panacée... d'autant plus qu'il s'agit d'ajouter 1 ou 2 classes par-ci par-là, histoire d'avoir le meilleur rendu "responsive" possible.
Dans dcBootstrap 2.0.x, j'ai opté pour une solution javascript. C'est fonctionnel à défaut d'être "passe partout".
comment:8 in reply to: ↑ 6 Changed 12 years ago by MathieuM
Replying to Jean-Michel:
Cela reste à confirmer et à retrouver mais il me semble par le passé avoir mis en place un _public.php de ce genre.
Si tu retrouves une trace de son existence, n'hésites pas à la partager ;)
comment:9 Changed 12 years ago by franck
Que tu tiennes absolument à utiliser bootstrap, c'est ton choix — cela dit, transporter 7000 lignes de CSS juste pour un thème DC, je trouve ça un peu beaucoup, mais passons —, mais de là à "imposer" les contraintes inhérentes à ce choix à tout le monde, il y a un petit fossé que j'ai du mal à justifier.
Le même petit fossé que tu peux aisément combler en fournissant les templates modifiés par tes soins. Après tout, ce n'est pas ça qui va peser bien lourd dans le package. Je ne vois vraiment pas ce qui gêne la dedans.
Imaginons le futur : quelqu'un d'autre vient un jour en disant qu'il a trouvé un autre framework qui tue sa mère (évidemment mieux que Bootstrap, il va sans dire (c'est juste pour la démo)), mais il faudrait ajouter deux-trois trucs par-ci par-là, histoire de… On va alourdir tout l'ensemble pour le choix d'un seul, choix qui d'ailleurs ne sera pas le tien.
Pour résumer tu demandes de la souplesse à DC là où tu n'es pas disposé à en apporter — je ne juge pas tes raisons, elles existent c'est tout —, à savoir fournir les templates adaptés qui serviront pour ton seul thème.
comment:10 Changed 12 years ago by MathieuM
On tourne en rond, c'pas le but... Discussion close alors. :-/
comment:11 Changed 12 years ago by bruno
Techniquement parlant, ça me paraît très lourd à mettre en oeuvre : actuellement le moteur de templates considère tout le code hors balise comme du texte, à aucun moment on ne parse le html des templates. Ta demande ne me paraît donc pas réalisable dans le moteur de templates.
Si tu veux pouvoir gérer ça, il faut jouer de la regexp sur le code pondu par le moteur de template, et ce n'est ni simple, ni performant...
comment:12 Changed 12 years ago by kozlika
- Status changed from new to onhold
On "on hold" donc, quitte à rouvrir si des éléments nouveaux se font jour.
J'ai par ailleurs dans l'idée que l'héritage qui se met en place sur les templates devrait permettre pas mal de choses dans ce domaine.
comment:13 Changed 11 years ago by franck
- Status changed from onhold to closed
- Resolution set to wontfix
- Milestone A definir deleted
C'est vrai que l'héritage/extension simplifie pas mal les choses.
Je ferme, et puis si ça se trouve, Twig permettra de faire tout ça, en mieux :-)
Y'a pas moyen d'utiliser des frameworks qui n'imposent pas une telle lourdeur dans le markup ?
Vaudrait mieux utiliser des librairies Sass (ou Less) qui ont la courtoisie de s'adapter sans modification à la structure existante, non ? zenGrids est dans ce cas par exemple.
J'y vois deux avantages :
À mon sens, c'est à la "déco" (CSS et consort) de s'adapter à la structure et pas l'inverse.