Salut tout le monde.
Je suis en train de lire SMACSS que j’ai découvert ici.
C’est très intéressant. Dans l’ensemble cela rejoint pas mal de mes propres expériences et me convainc de mettre en place des choses que je sentais mais n’avais pas encore formalisées.
Toutefois, j’ai un doute sur un principe que j’ai souvent souhaité mettre en place sans jamais le faire parce que cela me parait aller à l’encontre du principe de CSS : dissocier le flux de la mise-en-forme. Ce principe promut par SMACSS est l’application de classe de mise en forme. Par exemple : .l-inline qui affecte un display: inline-block à l’élément affublé de cette classe. D’un point de vue perf, cela me parait effectivement logique de procéder ainsi, et comme je l’ai dit, j’ai plusieurs fois été tenté de le faire. Toutefois, ainsi on place spécifiquement un marqueur de mise-en-forme figé dans le flux HTML. Si pour une raison ou pour une autre je ne veux plus de inline-block sur l’élément, je suis soit obligé de modifié le HTML (pas toujours possible) soit obligé de changer la déclaration CSS de cette classe qui prend du coup une application radicalement opposée à ce que son nom décrit ! Pire, dans l’air du Responsive, un élément peut très bien être en inline-block sur desktop et en block sur smartphone !
Du coup, je me pose des questions sur la pertinence de ce conseil, qui pourtant me traine dans la tête depuis des années… Je viens donc demander l’avis de la communauté : qu’en pensez-vous ?
Modifié par Derwoed (04 Dec 2013 - 15:18)
Je suis en train de lire SMACSS que j’ai découvert ici.
C’est très intéressant. Dans l’ensemble cela rejoint pas mal de mes propres expériences et me convainc de mettre en place des choses que je sentais mais n’avais pas encore formalisées.
Toutefois, j’ai un doute sur un principe que j’ai souvent souhaité mettre en place sans jamais le faire parce que cela me parait aller à l’encontre du principe de CSS : dissocier le flux de la mise-en-forme. Ce principe promut par SMACSS est l’application de classe de mise en forme. Par exemple : .l-inline qui affecte un display: inline-block à l’élément affublé de cette classe. D’un point de vue perf, cela me parait effectivement logique de procéder ainsi, et comme je l’ai dit, j’ai plusieurs fois été tenté de le faire. Toutefois, ainsi on place spécifiquement un marqueur de mise-en-forme figé dans le flux HTML. Si pour une raison ou pour une autre je ne veux plus de inline-block sur l’élément, je suis soit obligé de modifié le HTML (pas toujours possible) soit obligé de changer la déclaration CSS de cette classe qui prend du coup une application radicalement opposée à ce que son nom décrit ! Pire, dans l’air du Responsive, un élément peut très bien être en inline-block sur desktop et en block sur smartphone !
Du coup, je me pose des questions sur la pertinence de ce conseil, qui pourtant me traine dans la tête depuis des années… Je viens donc demander l’avis de la communauté : qu’en pensez-vous ?
Modifié par Derwoed (04 Dec 2013 - 15:18)
: pas plus de 2 classes par item (sauf les classes pour le JS), pas de classe de forme (.left…)… Toutefois, ces années passées à faire pousser cette plante tentaculaire nous ont montré les limites de notre système : surcharges inutiles si l’archi avait été mieux pensée au départ, difficultés de maintenance et surtout grosses difficultés d’appréhension du projet par les nouveaux intégrateurs… Toutefois, il était impossible de revenir en arrière. Maintenant que le client envisage le RWD et accepterait une refonte partielle, on peut essayer de réfléchir en amont aux meilleures solutions. D’où ma lecture de SMACSS (entre autre) qui dans l’ensemble corrobore ma propre expérience… sauf sur ces fameuses classes de mise-en-forme aux-quelles je reste réfractaire, d’autant plus dans un projet RWD…