Ce petit lien, m’interpelle ^^
Une collection d’effets typographiques css, relativement déjà vue, avec beaucoup de trucs bien ringards et deux ou trois sympa
Css text effects
▻http://ecard.enter-media.org/css-text-effects
Mais, ils utilisent ceci dans un concepteur de bannière,… ça fait quelques années (…) maintenant , que je pense ou vois la publicité, les encarts, les visuels marketés conçus non plus sous photoshop ou flash comme des graphiques, mais comme des canvas autonomes html5/js du coup ça met le temps mais ça arrive gentiment.
Adapté a un site : les covers ou hero-units, sont tout a fait conceptualisables a partir de classes utilitaires simples et gérables par le rédacteur ensuite sur le container parent ou enfant (en spip sur des selections_éditoriales par exemple).
– .layout-[xxx] - des layouts prédéfinis
– .bg-xxx - utilitaire de background
– .[animate|zoom|scale]-xxx - classes utils d’animation
– .title.txt-[effect].color-[color]
Un peut complexe, pour un non intégrateur, on peut s’orienter sur des classes plus adaptées à l’utilisateur finale en adaptant au langage metier ou à la compréhension de l’utilisateur (plus complexe), via des selecteurs adaptés plus compréhensibles pour lui, via un pré-pross css et quelques mixins si les composant sont bien conçuts, en ajoutant un spécificité ou un ciblage fort (.mapage .mon_container > .enfant.util etc…) on limite les effets de bords.
.zoom-in.titre-grand.bg-foret.txt-vert
j’utilise depuis quelques temps, ça fonctionne si on utilise une living Styleguide, qui sert de référence/guide de mise en page, sinon deux ans ou même 15 jours après on oublie les classes ^^. Le petit mémo, dans une page du site, le post-it ^^, le doc rédigé et jamais a jour … Tout bon intégrateur documente ces css (en théorie), le problème c’est de savoir, et après on en fait quoi ?
Généralement rien, la doc css ne sert qu’a l’intégrateur d’après dans le meilleur des cas, à vos camarades intégrateur de vous lire en regardant le code de vos sites ça évite de leur expliquer sur un forum , mais pas toujours ^^.
Plus on opte pour la modularité dans la structure des styles et de son code css généré, plus on se retrouve obligé de produire une documentation a jour et en temps réel. C’est ce qui m’a poussé a créer un outil (pas encore dispo publiquement actuellement), différents des outils que j’avais trouvé a l’époque et encore maintenant de génération de styleguide/doc.
De mon avis , il y’a principalement deux niveaux de documentation envisageables/interressants pour les styles :
– les fonctions internes au sytème/prepross (mixin, function, globals, …),
– la documentation des css générées en fonction du thème (classes utilitaires, grid utils, layouts utils).
Documenter au format du prépross, est a mon avis une erreur si on l’utilise pour la partie front et donc css générées.
Je préfère utiliser et documenter au format kss et non scssdoc, car les commentaires persisterons dans le code css généré, avant d’être supprimés au passage en production par un minifier css ou compresseur.
D’ailleurs, dans mon cas meme le html/twig/autres ainsi que le js sont documentés via kss, car quand on utilise beaucoup d’inclusions et de partials il faut bien documenter le contexte qu’elle attendent du modèle en tant que vue, et ce que ça en fait ensuite (surtout dans le cas de templates engine introduisant/permettant une ’logique’).
L’avantage c’est de ne plus penser aussi en terme de site, quand on conçoit : l’outil de styleguide devient plus une gallerie de composants/patterns, que l’on peut travailler en temps réel et tester rapidement hors ou in contexte. Tout s’adapte en fonction des couleurs, de la typo, du thème de l’application/site ET des composant inclus, on gagne du temps, a recharger la page quand y’a pas de bdd derrière un proto, … ^^.
Pour revenir au sujet, l’étape d’après dans l’idéal serait, que les listes de classes utilisables soit donc suggérées en fonction du composant à l’utilisateur, lors de sa saisie, avec un auto-complete. Ceci est a priori complètement envisageable SI la doc est la, car on obtient en retour un objet complet (au sens programation) utilisable dans n’importe quel autre applicatif, quand on utilise une class comme kssphp.
On obtient en retour d’un numéro/ref de section :
– titre, description, …
– les modifers
– les params
– les requis
– le markup (non pollué car le lorem et les placeholders sont générés en js).
– le javascript (ajout personel dans mon cas)
Disons que ça pourrait, dans l’idée, être une utilisation de la documentation front, pour créer les composants « programatiquement » ensuite.
