IRIVEN_CSSOPTIMISER - UNE CLASSE PHP POUR OPTIMISER SES FEUILLES DE STYLES CSS
Iriven
Messages postés
72
Date d'inscription
samedi 23 juin 2007
Statut
Membre
Dernière intervention
3 février 2014
-
16 août 2011 à 11:28
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 - 3 oct. 2011 à 01:31
TychoBrahe Messages postés 1309 Date d'inscription samedi 31 janvier 2009 Statut Membre Dernière intervention 5 juin 2013 - 3 oct. 2011 à 01:31
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/53467-iriven-cssoptimiser-une-classe-php-pour-optimiser-ses-feuilles-de-styles-css
https://codes-sources.commentcamarche.net/source/53467-iriven-cssoptimiser-une-classe-php-pour-optimiser-ses-feuilles-de-styles-css
3 oct. 2011 à 01:31
3 oct. 2011 à 01:01
ça fait deux avec l copie de zebra form, et j'ai pas regardé tes utres sources
...
Pitoyable comme comportement je trouve, tu ne fais rien avancer... tu plagie, ce qui démotive les vrais créateurs.
22 août 2011 à 09:02
Et si tu pouvais zipper ta source, cela éviterait un ascenseur sans fin ;)
18 août 2011 à 00:19
1. Pour une raison quelconque, le fichier css pointé est celui d'un autre site. Nous ne maîtrisons donc pas sa mise à jour et donc il nous faudrait passer manuellement ton script à chaque fois que l'autre site met à jour son css. La non prédiction de ces mises à jour ainsi que le temps mis entre le moment où on la remarque et le moment où nous avons nous même mis à jour notre css n'est pas acceptable. Devoir soi même devoir mettre à jour notre contenu alors que c'est un contenu externe qui change n'est pas non plus acceptable.
2. Notre site utilise du css dynamique. Par dynamique, comprendre généré à la volée (par exemple par un script php). L'utilisation de ton script empêcherais tout dynamisme à ce niveau.
Bien entendu ces deux situations sont évitables simplement en utilisant de vrais fichiers séparés et non des @import css. Mais voila, dans l'esprit de celui qui réalise le style cette nuance est source de confusions et d'erreurs, de comportement anormaux. Ceci est d'autant plus vrai que dans certaines circonstances on ne maîtrise pas forcément le nombre de fichiers css inclus en html et donc que l'on a pas d'autres choix que d'utiliser des import. Tout ceci me pousse à dire qu'il ne faut surtout pas "interpréter" l'include par défaut mais simplement le proposer comme option complémentaire, ou bien créer une nouvelle directive spécifique (mais alors ce ne sera plus du css pur).
J'ai également oublié de préciser comment je trouve que le code aurait du être organisé. Pour moi ceci devrait simplement être un parseur qui charge le fichier css afin d'en avoir une représentation sémantique puis le recrache sous sa nouvelle forme. Se contenter de simplement replacer des éléments, comme tu sembles le faire, est à mon sens une méthode à bannir car elle ne permet aucune validation de la syntaxe et devient rapidement très complexe à maintenir/améliorer.
Au passage j'en profite pour t'assurer que mes commentaires ne sont pas là pour te décourager mais simplement pour t'inviter à reprendre ton code afin d'en faire quelque chose de bien mieux.
17 août 2011 à 23:31
Je n'ai fait que survoler le code, je n'ai pas regardé en profondeur, mais voici déjà quelques critiques :
Au niveau des fonctionnalités :
- Sujet intéressant, on a souvent besoin de ce genre de choses.
- Le coup de générer les propriétés proprio -webkit, -moz etc, c'est contestable et devrait pouvoir etre simplement désactivé.
- Les optimisations du genre "padding: 0 0 0 0;" -> "padding: 0;" sont un peu useless mais bon,on ne va pas cracher dessus.
- Les images en base64 je suis totalement contre pour 3 raisons. 1. Le base64 augmente la taille du fichier. 2. Le fichier est "recopié" une fois par utilisation, ce qui conduit à des doublons en cas d'utilisation multiple d'une image. 3. Ça bousille la gestion du cache ainsi que son principe même, au lieux de recharger uniquement le fichier modifié on fais recharger un assemblage de plein de fichiers.
- Le coup de ta gestion du cache j'ai pas vraiment suivi le principe mais ça me semble carrément useless. Le serveur web s'en charge très bien, on ne dois rien avoir à faire de ce côté. Si on est vraiment des radins de la perf on met un varnish et hop le tour est joué.
- Tient, il n'est pas possible de pouvoir définir ses propres variables ? Parce que s'il y a une choses dont j'aurai besoin c'est bien ça, par exemple pour définir des tailles et couleurs récurrentes dans le css.
Au niveau du code :
- Mais c'est quoi tous ces bon sang d'attributs en public ! Sauf cas exceptionnel tu ne devrais en avoir *aucun* en public.
- Autant de méthodes statiques ? Entre ça et les attributs publics ça donne l'impression que tu ne sais aps faire de prog objet, que tu as juste balancé du code impératif dans une class. Bref, c'est carrément crade.
- L'utilisation de trigger_error() me conforte dans cette opinion, lancer des exceptions eut été plus judicieux.
- J'ai l'impression qu'il n'y a pas de véritable parseur, comment se comporte ton script en cas de css incorrect ? Est-ce qu'une erreur est générée ou bien est-ce-qu'il continue comme un boulet et fournis un truc toujours pas correct au final ? Dans ce genre d'outil la validation de la syntaxe me semble une nécessité.
Bref, si je trouve le principe intéressant, derrière je trouve ça mal fait. Ça pourrait être beaucoup plus propre et compréhensible.
16 août 2011 à 11:28