Ah, première fois que j’entends parler de post-processors. Concept intéressant. C'est vrai que grunt, yeoman et autres logiciels"hype" ont pas mal révolutionné la fin du workflow récemment (en permettant un watch qui lance concaténation, minification, et en fait tout ce que tu veux).

Après, le soucis c'est que tu n'as plus l'avantage d'un langage de programmation comme peut l'être sass. Exit les boucles, exit les calculs de couleurs, exit tout ce qui en fait le sel. La concaténation, la minification, le calcul de toutes les syntaxes, ça peut se faire en post-prod, pas les calculs générant des class ou une palette de couleur.

C'est hallucinant comme j'ai l'impression qu'il y a eu une accélération impressionnante du nombre et de la qualité des outils de webdev en 5 ans. Faudrai presque révolutionner son workflow toutes les années si on suivait la mode "webdev" ! :)

Si j'ai bien compris le lien de Fabe, la palette de couleurs est gérable en post-proc.

C'est un peu le même débat que Coffescript vs JS.
J'aurais tendance à dire qu'il faut bien connaitre la techno de bas niveau avant de passer à celle de haut niveau.
Ceci dit, lors d'une formation JS, on nous a montré la génération automatique du site Coffescript, et c'était assez impressionnant en terme de qualité.

Je n'avais jamais entendu parlé avant cette formation de Brunch,, et ça m'a l'air excellent. Ca permet justement d'avoir cette génération automatique (préprocesseurs). Et aussi, la minification, concaténation des ressources (1 seul script qui fusionne tous les scripts, 1 seul CSS pour tous les styles), plus création de squelette de projet, à la manière des archetype Maven, plus test sur un serveur web de dev, qui pousse automatiquement les update de code.

Ah, et une bonne pratique qui n'est pas respectée sur le Lexpage ;) : Les scripts doivent tous être en bas de page, sauf Modernizr!

GuybrushSi j'ai bien compris le lien de Fabe, la palette de couleurs est gérable en post-proc.

Pas tout à fait :

:root {
    var-color: #069;
}

.element {
    color: var(color);
}

C'est "juste" une variable appelable d'une autre partie de ton CSS. Et c'est déjà beaucoup par rapport à l'existant. Je parle plus de calculs de couleurs : dans mon framework, j'ai un fichier nomdemonsite_var.scss qui a dedans notamment :

$couleurDeCeSite: #072d71;
$couleurDeCeSiteNoircie: darken($couleurDeCeSite, 13%);

Donc ma couleur noircie me donne #5b972f. Je peux éclaircir, noircir, trouver l'inverse, etc ...

Et dans d'autres fichiers spécifiques, par exemple mon banner.scss :

.bandeau {
@include background-image(linear-gradient($couleurDeCeSiteNoircie,$couleurDeCeSite));
}

Je change une fois la couleur du site dans ma charte, je génére la CSS d'un tout nouveau site en quelques secondes. La couleur va pas ? Pas de soucis, hop on part dans un autre univers chromatique en deux coups de cuillère à pot, avec plusieurs tonalités différentes pour une couleur.

Les boucles ? Je m'en sers pour générer mes cols pour ma grid :

@for $i from 1 through $totalColumns {
	.cols-de-#{$i} { 
width: percentage($i / $totalColumns);
[...]
}
}

Oops, je crois qu'on a hijacké le topic ! :D

Tchou> En effet, c'est pas tout à fait pareil

pomAh, et une bonne pratique qui n'est pas respectée sur le Lexpage ;) : Les scripts doivent tous être en bas de page, sauf Modernizr!

Ouaaais, je sais Au début, c'était en bas de la template principale, mais je sais plus pour quelle raison je l'ai bougé...
Je vais refaire un test, parce que je suis prémuni de l'ordre, vu que la majeure partie des appels via JQuery se font dans un $(document).ready()... Cela dit, vu que mes scripts sont tous "internes", les placer en tête de document n'est pas (trop) problématique au niveau du temps de chargement

GuybrushJe vais refaire un test, parce que je suis prémuni de l'ordre, vu que la majeure partie des appels via JQuery se font dans un $(document).ready()... Cela dit, vu que mes scripts sont tous "internes", les placer en tête de document n'est pas (trop) problématique au niveau du temps de chargement

Ok, le $(document).ready(), te prémunit contre les comportements bizaroïdes, mais si tu ne mets pas les scripts en bas du body, tu n'auras pas un temps de rendu du DOM optimal! C'est pas que c'est ultra important ici mais c'est juste un bénéfice rapide ;)

Régler le soucis du python qui de temps à autre prend 20 secondes pour générer la page sera préférable à cette optimisation .... même si je ne peux qu'être d'accord avec toi ! :)

Une paire de balises span non fermées dans le code de cette page :

<div class="pagination pagination-sm">
        <li><a href="/board/thread/2-lexpage-v4-erreurs-404-erreurs-500-et-erreurs-diverses/1/"><span class="fa fa-fast-backward"/></a></li>
        
            <li><a href="/board/thread/2-lexpage-v4-erreurs-404-erreurs-500-et-erreurs-diverses/3/"><span class="fa fa-backward"/></a></li>
    
       
            <li class="disabled"><a href="#"><span class="fa fa-forward"/></a></li>
        
        <li><a href="/board/thread/2-lexpage-v4-erreurs-404-erreurs-500-et-erreurs-diverses/4/"><span class="fa fa-fast-forward"/></a></li>
    </div>

La prévisualisation a foiré sur ce message (lié au b dans le code) ?

Pom> Je viens de tester, et le minichat semble merdouiller un peu quand je déplace les scripts en bas de page. Je vais voir pourquoi, ça ne peut pas faire de tort

Tchou> Corrigé, merci. J'ai découvert (via le /> en rouge dans le source proposé par FF) que <span> ne pouvait pas être auto-fermé. Venant d'un monde où j'enseigne XML, est-ce qu'il y a une raison à cette hérésie ?

[Edité : Tu peux détailler pour le bug de la prévisu ? Je vois bien le [b] dans le [code], mais ça s'affiche correctement ici... L'affichage via la prévisualisation est le même que celui sur le forum, je suppose que tu as du corriger entre temps ?]

XML !== HTML

Tu peux faire en sorte que les liens (par exemple des brèves de John Duff) soient automatiquement en target=_blank, ça évite un clic-milieu

Merci

GuybrushTchou> Corrigé, merci. J'ai découvert (via le /> en rouge dans le source proposé par FF) que <span> ne pouvait pas être auto-fermé. Venant d'un monde où j'enseigne XML, est-ce qu'il y a une raison à cette hérésie ?

La même raison que celle qui a poussé le W3C à travailler sur HTML5 et à tuer XHTML, la peur de décourager les mauvais conserver le standard accessible aux débutants
Et cadrer le truc pour empêcher les vendeurs de navigateurs de pondre un nouveau format toutes les 2 semaines.

XML et son extensibilité étaient formidables, c'est grâce à eux qu'on a pu avoir les premières implémentations de SVG dans les navigateurs.
Mais HTML5 est vachement extensible hein, si si. On peut faire des attributs qui commencent par "data-" et mettre ce qu'on veut derrière

(troll, bisous)

:yaisse2: