| |
| css_guidelines:bem-like_naming [2016/08/10 16:27] – created leo | css_guidelines:bem-like_naming [2016/08/10 16:32] (current) – leo |
|---|
| </code> | </code> |
| |
| Les éléments sont délimitées avec 2 underscores (__), et les modifieurs sont délimités par deux tirets (--). | Les éléments sont délimitées avec 2 underscores ([[__]]), et les modifieurs sont délimités par deux tirets (--). |
| |
| On peut voir ici que .person {} est le bloc, il s'agit de la racine d'une entité distinct. .person__head {} est un élément; c'est une plus petite partie du bloc .person {}. Enfin, .person--tall {} est un Modifier; c'est une variante spécifique du bloc .person {}. | On peut voir ici que .person {} est le bloc, il s'agit de la racine d'une entité distinct. .person[[__]]head {} est un élément; c'est une plus petite partie du bloc .person {}. Enfin, .person--tall {} est un Modifier; c'est une variante spécifique du bloc .person {}. |
| |
| ===== Starting Context ===== | ===== Starting Context ===== |
| |
| Votre contexte de bloc démarre à l'endroit le plus logique, self-contained, distinct. Pour continuer avec notre analogie basée sur la personne, nous ne devrions pas avoir de classe comme .room__person {}, étant donné que la pièce (room) est un autre contexte bien plus élevé. Nous aurons sans doute des blocs séparés tels que : | Votre contexte de bloc démarre à l'endroit le plus logique, self-contained, distinct. Pour continuer avec notre analogie basée sur la personne, nous ne devrions pas avoir de classe comme .room[[__]]person {}, étant donné que la pièce (room) est un autre contexte bien plus élevé. Nous aurons sans doute des blocs séparés tels que : |
| |
| <code> | <code> |
| .room { } | .room { } |
| |
| .room__door { } | .room[[__]]door { } |
| |
| .room--kitchen { } | .room--kitchen { } |
| .person { } | .person { } |
| |
| .person__head { } | .person[[__]]head { } |
| </code> | </code> |
| |
| ===== More Layers ===== | ===== More Layers ===== |
| |
| Si nous devions ajouter un autre élément — appelé, disons, .person__eye {}— à ce composant .person {} , nous n'aurions pas besoin de parcourir chaque niveau du DOM. c'est facile à dire, mais la notation serait .person__eye {}, et non .person__head__eye {}. Vos classes ne reflètent pas l'entièreté du DOM. | Si nous devions ajouter un autre élément — appelé, disons, .person[[__]]eye {}— à ce composant .person {} , nous n'aurions pas besoin de parcourir chaque niveau du DOM. c'est facile à dire, mais la notation serait .person[[__]]eye {}, et non .person[[__]]head[[__]]eye {}. Vos classes ne reflètent pas l'entièreté du DOM. |
| |
| ===== Modifying Elements ===== | ===== Modifying Elements ===== |
| </code> | </code> |
| |
| Notez que nous ne nichons pas la nouvelle instance de .person__face {} dans .person--handsome {}; à la place, nous faisons usage du sélecteur de parent SASS pour prépend .person--handsome sur le sélecteur .person__face {} existant. cela signifie que toutes les règles related à .person__face {} existent à un seul endroit, et ne s'étalent pas dans tout le fichier. C'est une bonne pratique général lorsque l'on a affaire à du code niché : garder tout votre contexte (ici tout le code de .person__face {}) encapsulé en un unique endroit. | Notez que nous ne nichons pas la nouvelle instance de .person[[__]]face {} dans .person--handsome {}; à la place, nous faisons usage du sélecteur de parent SASS pour prépend .person--handsome sur le sélecteur .person[[__]]face {} existant. cela signifie que toutes les règles related à .person[[__]]face {} existent à un seul endroit, et ne s'étalent pas dans tout le fichier. C'est une bonne pratique général lorsque l'on a affaire à du code niché : garder tout votre contexte (ici tout le code de .person[[__]]face {}) encapsulé en un unique endroit. |
