28172 sujets

CSS et mise en forme, CSS3

Pourquoi éviter les sélecteur ID ? (blog.goetter.fr)

Administrateur
Bonjour,

l'origine de cette recommandation est chez OOCSS et N. Sullivan.
Mieux vaut utiliser uniquement des classes que des id et des classes parce que quand il s'agit d'écraser des instructions dont le sélecteur contient un id, il faut un autre id vu que même 15 classes n'auront pas autant de poids que cet id.
C'est comme le !important en moins pire.

Et je rajoute parce que la confusion est faite (pas par toi mais trop souvent) :
Ce que ne dit pas cette phrase : qu'il faudrait éviter les id partout. C'est obligatoire pour l'accessibilité des formulaires (for sur label et id sur input/textarea/select) et incontournable en JS
Hello,

Je pense que ce que Raphaël a voulu dire, c'est que vu qu'un id a plus de poids qu'une classe, il est plus difficile d'y redefinir du css en passant seulement par une classe. Tu devras alors créer un sélecteur plus compliqué.

Par exemple dans le code suivant :

#monInput {
    border: 1px solid blue;
}
.error {
    border-color: red;
}


si tu as un input avec l'id "monInput" et que tu lui rajoute la classe "error" (lorsque l'user se trompe par exemple), la border restera bleu.

Pour ma part, depuis cet article, je n'utilise les id qu'en js (sauf quand je n'ai pas le choix) et je trouve que mon code HTML a gagné en lisibilité.

Voilà, j'espère avoir bien répondu à la question, j'imagine que si je me trompe on me rectifiera rapidement ^^.
Merci pour vos réponse.
C'est bien ce que je pensais, même si personnellement je trouve l'utilisation de l'idi justifie dans certain cas.

D'autant qu'un élément avec un id est unique, donc pourquoi ne pas écraser une regles sur un id, par une règle sur un id?


#menu {
	display: none;
}
@media screen and (min-width: 768px) {
	#menu {
		[...]
	}
}
Ton nouvel exemple est tout à fait correct.

C’est un principe de OOCSS et ne doit être envisagé qu’en tant que principe. Pour styler un élément unique et transverse à un site (au hasard, l’entête de la page) un identifiant reste justifié.

Ce principe tire ses origines dans les feuilles de styles extrêmement volumineuses qui sont apparues au milieu des années 2000 dans des grands systèmes d’information. Dans ce genre de contexte, un identifiant utilisé dans les CSS pourra avoir un effet désastreux en cascade si un nouveau contributeur doit apporter une modification ou ré-utiliser une portion de CSS. C’est pour cette raison qu’on recommande l’usage de classes, qui peuvent être multiples sur la même page et ré-utilisable par nature. Ce principe a donc été extrapolé pour limiter les risques auxquels s’exposent des intégrateurs ayant peu conscience du poids des sélecteurs ou des contraintes particulières comme le travail en équipe.

Cependant, il n’est absolument pas interdit d’utiliser des identifiants, il faut simplement en connaitre les limites.

PS : J’appuie la remarque de Felipe, ce principe de limiter l’usage des identifiants ne s’applique qu’au CSS. Il est indispensable dans de nombreux d’avoir un identifiant sur vos éléments HTML (ancres, champs et labels de formulaires, etc.).
Administrateur
Ten a écrit :
Ce principe tire ses origines dans les feuilles de styles extrêmement volumineuses qui sont apparues (...)

Ah oui tu fais bien de le rappeler : avec 5 gabarits pour un site complet, les sources d'ennui et les exigences ne sont pas aussi nombreuses ni les mêmes qu'avec des dizaines ou des centaines de gabarits.
Perso je suis abonné aux gros clients d'alsacreations.fr et si j'utilisais (aussi) les id il y a quelques années pour quelques dizaines de gabarits à l'époque IE6 bien avant les Media Queries, ça aurait été une source infinie d'ennuis et d'!important sur mon projet actuel : quelques centaines de gabarits, 4 Media Queries pour IE9+ et desktop first (enfin IE first plutôt) pour IE8 et 4-5 personnes en parallèle pendant des mois.
Le point le plus important c'est d'avoir une convention et de l'appliquer. Peu importe laquelle à la limite mais tout le monde la même !
Après si je colle des !important dans la MQ pour <320px, je m'en fiche un peu : y a plus rien censé venir après. Si je le colle en 1024px, je vais devoir faire au moins autant bourrin en 768 puis 480 puis 320...
Pour les id, je pourrais intégrer avec puis 2 mois plus tard le client m'envoie d'autres gabarits où le look d'un composant est similaire mais le nom de l'id existant a rien à voir avec ce que je veux faire... Soit je nomme un composant de manière contre-intuitive et personne ne comprendra pourquoi ça s'appelle comme ça là ou bien je duplique mes CSS en espérant que GZip envoyé par le serveur aux navigateurs rattrappe le surpoids de cette duplication. Ou bien maintenant un composant est présent en plusieurs occurences mais je dois utiliser un id pour le styler...
Moins j'ajoute de spécificité, moins la cascade est utilisée et mieux je peux voir venir les variantes de blocs (composants), les changements complets dans une MQ (plus d'une fois pour certains cas). Du progressive écrasement quoi Smiley lol
Modifié par Felipe (30 Oct 2014 - 14:25)
Sujet clos
Aller à