Petite précision, je parle ici seulement de l'imbrication. Cela ne remet pas en question mon utilisation du préprocesseur SASS que je trouve toujours utile
Tu conforte ma position 😄, j'avais du abandonné l'imbrication également, ça deviens très vite le bordel à écraser les règles. Merci pour cette vidéo Grafikart
"Y a des gens qui pensent que je ne sais pas qu'on peut imbriquer les choses", lol qui peut penser ça il s'agit de Grafikart là on est sur le top des créateurs dans le domaine donc un moment donné il faut pas abuser 🤣😂
@@shiftytab Sincèrement y a pas a discuté c'est évident qu'il sait c'est l'une des premières caractéristiques si ce n'est pas la première qu'on découvre lorsque l'on apprend Sass donc stplt ce n'est pas de la philosophie
Juste génial, je me suis reconnu dans chacun des soucis liés à l'imbrication que tu as cité. Du coup j'ai un peu de travail à faire sur ma facon de faire. Merci !
Salut Grafikart, je comprends ton point de vue et j'ai deux remarques / utilisations différentes qui font que je n'utilise que l'imbrication: - Pour les header__logo qui sont imbriqués en &__logo, je trouve tout simplement que c'est une très mauvaise pratique, que du coup je n'utilise pas - Pour les imbrications trop profondes, je fini par commenter l'identifiant, pour le retrouver facilement en une recherche Merci encore pour ton contenu :)
Salut, Et vous n’aurez pas de problèmes si vous organisez correctement la construction de la page. BEM (Block, Element, Modifier) est une approche de composant du développement web. Il est basé sur le principe de la division de l’interface en blocs indépendants. Il vous permet de développer facilement et rapidement des interfaces de toute complexité et de réutiliser le code existant, en évitant le « Copier-Coller »
superbe vidéo, bien expliquer. en tant que dev surtout orient back, quand je fait du scss j'applique ce qui est déjà en place.... mais en effet j'aime pas trop, quand y a énormément d'imbrication
moi je ne ressent pas les points que tu soulève comme une gène. a part peut-être pour les reviews. Mais je travail sur des projets souvent en atomic design, où BEM prend tout son sens (profondeur limitée : block, element, modifier) et ou le scss de chaque composant n'est pas trop énorme. Associé a ça des mixins et des variables pour gérer le dark mode et tout roule. et au contraire, je trouve le scss bien plus lisible qu'un fichier css classique, bien plus verbeux avec beaucoup de répétitions.
Attention j'utilise quand même le SCSS tout de même (impossible de faire un gros fichier CSS comme avant). Comme tu le dis dans un scope limité, avec une profondeur restreinte ça passe d'utiliser de l'imbrication.
Il faut utiliser l'atomicité avec !important avec la méthodologie BEM. La méthodologie BEM permet de fournir un style de base aux composants et l'atomicité d'écrasé certaine partie du compostant. Quand on met un !important avec qu'une seule propriété, c'est logique que l'on veut dans tout les cas de figure appliqué. Dans ce cas là le !important n'est absolument pas un problème. Il existe aussi une histoire de couplage dans le CSS. Exemple, si tu met une règle de disposition sur un de tes composants.... Il est beaucoup plus intéressant de séparer la disposition des composants avec des styles de base par exemple au risque de rendre la classe peu réutilisable. Et dans un site web le poids du CSS rentre en ligne de compte pour le SEO. Le nouveau Bootstrap à totalement découpler cette logique. Il a un CSS pour le reboot, un autre pour les composants, et encore un autre pour les classes utilitaires et un autre pour la grid. Il a même un système permet d'auto générer les classes utilitaires avec @media-query permettant d'intervenir sur certaines résolution d'écran. Je ne suis personnellement pas trop trop contre les frameworks. Ils fournissent du code open source et donc du travaille gratuit. C'est instructif de lire le code source ^^
Avant que les préprocesseurs CSS existent, il était de bonne pratique d'éviter de descendre en dessous de deux sélecteurs imbriqués. Les préprocesseurs sont arrivés et j'ai gardé cette règle. Le problème avec les préprocesseurs, c'est que les gens ne font plus attention au code final (souvent dégueulasse) qu'ils génèrent. Ils ont appris à coder avec un outil avant même de savoir coder en vanilla.
C'est d'ailleurs ce que préconise des développeurs comme Kevin Powel, max 3 en ce compris les changements d'état. Ce qui ne pose aucun problème en suivant BEM ou CUBE ;)
Du css couplé avec :root ça peut faire la différence. Le système de variable simplifie la lecture quand elles sont bien écrites et les modifications. Mais si peu de gens utilisent :root...
Est-ce que comme moi, avant de passer en SCSS, certains d'entre vous tabulaient leur CSS pour essayer de rester cohérent avec l'HTML? Je trouvais ça tellement pratique et plus propre mais je n'ai jamais vu personne d'autre faire ça 😥
J'ai jamais vu quelqu'un faire ça, mais intuitivement ça me parait absolument horrible. A chaque fois que tu modifie du HTML, il faut que tu ailles dans ton CSS juste pour changer des tabulations. Pas possible 😅
je voie plus ca comme une facon d'utiliser l'attribut class="" en aval dans le DOM. soit on part sur une logique full utility-class et la oui l'imbrication n'a pas de raison d'etre , mais ca veux aussi dire utiliser une multitude de class ne serait que pour un bouton Soit on tire partie de l'imbrication pour creer des component entier a partir de la classe d'un container. Je suis encore partagé sur ce point entre mon utilisation plutot prompt a avoir un DOM le plus simple possible et la facilité d'utilisation qu'apporte les utility-class en equipe (surtout avec des dev allergiques a la css)
Personnellement j'utilise SCSS pratiquement que pour l'imbrication. Je trouve ça plus facile pour me retrouver et organiser mon code plutôt que d'écrire des sélecteurs à rallonge. Et au contraire, le fait de que ça crée des règles très spécifiques ça permet d'éviter certains conflits. Mais c'est intéressant comme point de vue, je m'imaginais pas que certains y trouvaient des inconvénients. Après je travaille plutôt sur des projets perso mais du coup j'y réfléchirai à deux fois pour des travaux de groupe.
On peut imaginer d'utiliser l'imbrication comme une sorte d'espace de nom pour éviter le scope. Après, l'intérêt de descendre en dessous de 2 sélecteurs imbriqués c'est quoi ?
@@nunn Oui tout à fait j'aurai pas dis mieux, c'est comme une sorte d'espace de noms. Le reste de l'imbrication est ensuite une question d'organisation. Si je veux modifier le lien a dans le li de ce ul particulier, etc. Et aussi pour regrouper tous les styles d'un élément et de ses enfants au même endroit. Notamment lorsqu'il s'agit de composant avec une architecture et un style particulier. Après pour les styles généraux comme la typographie ou les sections je les mets à la racine. Je ne vais pas les imbriquer inutilement dans body par exemple.
Je fais de l'imbrication sur des webapps (Vue, React) parce que les composants sont souvent limités et scopés, sur du WordPress j'évites. L'imbrication me permet de savoir inmediatament l'imbrication HTML sans avoir à l'ouvrir, parfois c'est pratique L'esperluette, jamais, pour les meme raisons que tu evoques, je suis trop souvent tombé sur des recherches longues sur des gros projets ou je ne pouvais pas faire de recherche Rapide sur mon projet, à cause de cette esperluette, j'ai vite trouvé ça relou
Petite précision, je parle ici seulement de l'imbrication. Cela ne remet pas en question mon utilisation du préprocesseur SASS que je trouve toujours utile
Tu conforte ma position 😄, j'avais du abandonné l'imbrication également, ça deviens très vite le bordel à écraser les règles.
Merci pour cette vidéo Grafikart
"Y a des gens qui pensent que je ne sais pas qu'on peut imbriquer les choses", lol qui peut penser ça il s'agit de Grafikart là on est sur le top des créateurs dans le domaine donc un moment donné il faut pas abuser 🤣😂
@@shiftytab Sincèrement y a pas a discuté c'est évident qu'il sait c'est l'une des premières caractéristiques si ce n'est pas la première qu'on découvre lorsque l'on apprend Sass donc stplt ce n'est pas de la philosophie
Juste génial, je me suis reconnu dans chacun des soucis liés à l'imbrication que tu as cité. Du coup j'ai un peu de travail à faire sur ma facon de faire. Merci !
J'avais carrément oublié qu'on pouvait ne pas imbriquer 😅 ça va m'épargner beaucoup de galères, merci
Salut Grafikart, je comprends ton point de vue et j'ai deux remarques / utilisations différentes qui font que je n'utilise que l'imbrication:
- Pour les header__logo qui sont imbriqués en &__logo, je trouve tout simplement que c'est une très mauvaise pratique, que du coup je n'utilise pas
- Pour les imbrications trop profondes, je fini par commenter l'identifiant, pour le retrouver facilement en une recherche
Merci encore pour ton contenu :)
Merci j'attends tellement ce tutoriel depuis le dernier jour . Merci
Merci merci , pour l'éclaircissement . C'est claire maintenant 😇
Salut,
Et vous n’aurez pas de problèmes si vous organisez correctement la construction de la page.
BEM (Block, Element, Modifier) est une approche de composant du développement web. Il est basé sur le principe de la division de l’interface en blocs indépendants. Il vous permet de développer facilement et rapidement des interfaces de toute complexité et de réutiliser le code existant, en évitant le « Copier-Coller »
superbe vidéo, bien expliquer.
en tant que dev surtout orient back, quand je fait du scss j'applique ce qui est déjà en place.... mais en effet j'aime pas trop, quand y a énormément d'imbrication
moi je ne ressent pas les points que tu soulève comme une gène. a part peut-être pour les reviews. Mais je travail sur des projets souvent en atomic design, où BEM prend tout son sens (profondeur limitée : block, element, modifier) et ou le scss de chaque composant n'est pas trop énorme. Associé a ça des mixins et des variables pour gérer le dark mode et tout roule. et au contraire, je trouve le scss bien plus lisible qu'un fichier css classique, bien plus verbeux avec beaucoup de répétitions.
Attention j'utilise quand même le SCSS tout de même (impossible de faire un gros fichier CSS comme avant). Comme tu le dis dans un scope limité, avec une profondeur restreinte ça passe d'utiliser de l'imbrication.
Il faut utiliser l'atomicité avec !important avec la méthodologie BEM. La méthodologie BEM permet de fournir un style de base aux composants et l'atomicité d'écrasé certaine partie du compostant. Quand on met un !important avec qu'une seule propriété, c'est logique que l'on veut dans tout les cas de figure appliqué. Dans ce cas là le !important n'est absolument pas un problème. Il existe aussi une histoire de couplage dans le CSS. Exemple, si tu met une règle de disposition sur un de tes composants.... Il est beaucoup plus intéressant de séparer la disposition des composants avec des styles de base par exemple au risque de rendre la classe peu réutilisable. Et dans un site web le poids du CSS rentre en ligne de compte pour le SEO. Le nouveau Bootstrap à totalement découpler cette logique. Il a un CSS pour le reboot, un autre pour les composants, et encore un autre pour les classes utilitaires et un autre pour la grid. Il a même un système permet d'auto générer les classes utilitaires avec @media-query permettant d'intervenir sur certaines résolution d'écran. Je ne suis personnellement pas trop trop contre les frameworks. Ils fournissent du code open source et donc du travaille gratuit. C'est instructif de lire le code source ^^
Bonjour et merci pour le partage d'expérience. Philippe P.
Salut
J'ai une question hors sujet.
J'aimerais savoir comment être au courant de tes live .
Merci
Sur le discord : grafikart.fr/tchat j'annonce les lives un peu l'avance dans un salon spécial.
Avant que les préprocesseurs CSS existent, il était de bonne pratique d'éviter de descendre en dessous de deux sélecteurs imbriqués. Les préprocesseurs sont arrivés et j'ai gardé cette règle.
Le problème avec les préprocesseurs, c'est que les gens ne font plus attention au code final (souvent dégueulasse) qu'ils génèrent. Ils ont appris à coder avec un outil avant même de savoir coder en vanilla.
C'est d'ailleurs ce que préconise des développeurs comme Kevin Powel, max 3 en ce compris les changements d'état. Ce qui ne pose aucun problème en suivant BEM ou CUBE ;)
c'est quoi ton environnement dans Arch linux , c'est xfce4 ?
Très bonne explication. j'adhère.
Du css couplé avec :root ça peut faire la différence. Le système de variable simplifie la lecture quand elles sont bien écrites et les modifications. Mais si peu de gens utilisent :root...
Merci pour ce rappel...👍
Est-ce que comme moi, avant de passer en SCSS, certains d'entre vous tabulaient leur CSS pour essayer de rester cohérent avec l'HTML? Je trouvais ça tellement pratique et plus propre mais je n'ai jamais vu personne d'autre faire ça 😥
J'ai jamais vu quelqu'un faire ça, mais intuitivement ça me parait absolument horrible. A chaque fois que tu modifie du HTML, il faut que tu ailles dans ton CSS juste pour changer des tabulations. Pas possible 😅
@@drkaaaaaah L'un allait de paire avec l'autre pour moi, et c'est d'ailleurs encore plus le cas avec le SCSS et l'encapsulation finalement.
je voie plus ca comme une facon d'utiliser l'attribut class="" en aval dans le DOM.
soit on part sur une logique full utility-class et la oui l'imbrication n'a pas de raison d'etre , mais ca veux aussi dire utiliser une multitude de class ne serait que pour un bouton
Soit on tire partie de l'imbrication pour creer des component entier a partir de la classe d'un container.
Je suis encore partagé sur ce point entre mon utilisation plutot prompt a avoir un DOM le plus simple possible et la facilité d'utilisation qu'apporte les utility-class en equipe (surtout avec des dev allergiques a la css)
bien expliqué merci.
Personnellement j'utilise SCSS pratiquement que pour l'imbrication.
Je trouve ça plus facile pour me retrouver et organiser mon code plutôt que d'écrire des sélecteurs à rallonge.
Et au contraire, le fait de que ça crée des règles très spécifiques ça permet d'éviter certains conflits.
Mais c'est intéressant comme point de vue, je m'imaginais pas que certains y trouvaient des inconvénients. Après je travaille plutôt sur des projets perso mais du coup j'y réfléchirai à deux fois pour des travaux de groupe.
On peut imaginer d'utiliser l'imbrication comme une sorte d'espace de nom pour éviter le scope. Après, l'intérêt de descendre en dessous de 2 sélecteurs imbriqués c'est quoi ?
@@nunn Oui tout à fait j'aurai pas dis mieux, c'est comme une sorte d'espace de noms.
Le reste de l'imbrication est ensuite une question d'organisation. Si je veux modifier le lien a dans le li de ce ul particulier, etc. Et aussi pour regrouper tous les styles d'un élément et de ses enfants au même endroit.
Notamment lorsqu'il s'agit de composant avec une architecture et un style particulier.
Après pour les styles généraux comme la typographie ou les sections je les mets à la racine. Je ne vais pas les imbriquer inutilement dans body par exemple.
Je fais de l'imbrication sur des webapps (Vue, React) parce que les composants sont souvent limités et scopés, sur du WordPress j'évites.
L'imbrication me permet de savoir inmediatament l'imbrication HTML sans avoir à l'ouvrir, parfois c'est pratique
L'esperluette, jamais, pour les meme raisons que tu evoques, je suis trop souvent tombé sur des recherches longues sur des gros projets ou je ne pouvais pas faire de recherche Rapide sur mon projet, à cause de cette esperluette, j'ai vite trouvé ça relou
4:50 il faut l'extensions cssPeek
Je crois que Kevin Powell a la même position sur le sujet. Si on utilise BEM je trouve que cela grandement à ne plus trop utiliser l'imbrication
salut les Gars !!!svp j'aimerai établir une communication vidéo entre 4 avec WEBRTC ...projet de classe... svp besoin d'aide
Désolé mais le webrtc a déjà été traité : grafikart.fr/tutoriels/webrtc-864
Hello, en gros la majeure partie des problèmes que tu évoques c'est parce que tu utilises BEM
Pas forcément cela arrive quelque soit la structure adopté.
La première fois que j'ai vu de l'imbrication j'ai vu des spaghettis.
Personnellement j'utilise l'imbrication mais sans l'esperluette