Maison > Article > interface Web > Comment j'écris des sélecteurs CSS
Il existe de nombreuses méthodologies CSS, et je les déteste toutes. Un peu plus (tailwind & al.) et d'autres moins (BEM, OOCSS, etc.). Mais en fin de compte, ils ont tous des défauts.
Les gens utilisent ces approches pour de bonnes raisons, bien sûr, et bon nombre des problèmes abordés sont ceux que j'ai également rencontrés. Donc, dans cet article, j'aimerais écrire mes propres directives sur la façon dont je garde CSS organisé.
Il ne s'agit pas d'une méthodologie CSS entièrement décrite que n'importe qui pourrait commencer à utiliser. Peut-être que cela pourrait être transformé en un seul travail avec un peu de travail supplémentaire, mais le but de cet article est simplement de montrer comment je prends ces décisions lors de l'écriture de CSS.
En règle générale, j'essaie d'utiliser les types d'éléments intégrés autant que possible et avec le moins de peluches supplémentaires possible.
Avoir besoin d'un millier de types de boutons différents est le signe qu'il pourrait y avoir un problème avec la conception à un niveau plus profond, donc même si dans certains cas, je ressens l'attrait du CSS inerte jusqu'à ce que des classes spécifiques au framework soient utilisées , dans la plupart des cas, je considère comme idéal qu'un bouton soit simplement
div.btton devrait se transformer en bouton
Tous les éléments de conception n'ont pas d'équivalent HTML sémantiquement adapté, et pour ces cas, j'ai généralement recours à des éléments personnalisés.
Je n'ai pas vu beaucoup de cas d'utilisation de noms d'éléments personnalisés sans aucun javascript associé, mais cela s'est avéré être un choix étonnamment solide pour écrire du HTML clair qui ressemble également à ce que je souhaite.
Des éléments entièrement distincts en termes de conception sont également plus susceptibles de développer, au fil du temps, des exigences qui ne peuvent être implémentées qu'avec JavaScript, ce qui vous laisse un chemin clair pour implémenter ceux qui ne nécessitent aucune modification dans le HTML ni le CSS.
div.vsep devrait se transformer en séparateur vertical
Les classes doivent fonctionner comme des modificateurs du nom du nœud existant, plutôt que comme des types d'éléments entièrement nouveaux, et ont souvent des effets similaires mais différents sur différents types d'éléments.
Un bouton dangereux est un bouton.danger
Certaines façons de modifier des éléments ne sont pas de simples interrupteurs marche/arrêt pour lesquels les classes sont utiles, mais se comportent davantage comme des paires clé-valeur.
Dans ces cas, les attributs personnalisés avec des sélecteurs correspondants se sont avérés être la meilleure option presque chaque fois que je les ai utilisés. Contrairement aux classes avec trait d'union, elles indiquent au niveau syntaxique quel est l'attribut et quelle est la valeur, ce qui permet aux éditeurs de les mettre en évidence plus facilement, à l'œil humain de les analyser rapidement et de faciliter l'interface à l'aide de JavaScript.
Pour ceux d'entre nous qui espèrent encore que la fonction attr() puisse un jour faire son chemin dans CSS pour plus que du contenu, il s'agit également d'une couche supplémentaire de pérennité.
Les identifiants sont, par définition, uniques à l'intérieur du document. En tant que telle, toute règle ciblant un identifiant particulier sera limitée et pourra nécessiter une refactorisation s'il s'avère plus tard qu'il devrait y avoir plus d'un élément de ce type sur le lage après tout.
En tant que tels, les identifiants doivent être utilisés avec parcimonie et uniquement lorsque cela n'a aucun sens d'avoir plus d'un élément dans un même document.
Les avantages par rapport aux classes, tant sur le plan pratique que sur le plan de la lisibilité, sont plutôt faibles, donc privilégier les classes est généralement la meilleure idée lorsqu'aucune relation claire de 1 à 1 entre l'élément et le style ne peut être identifiée.
Toute application du monde réel comportera à un moment donné des éléments qui nécessitent simplement des ajustements individuels afin de les rendre plus esthétiques dans le contexte dans lequel ils apparaissent.
Dans ces cas, l'attribut style est la voie à suivre. Toute raison pour laquelle son utilisation est considérée comme une mauvaise pratique s'applique à tout type de style en ligne, y compris les classes utilitaires. Le problème n'est pas l'attribut, c'est le mélange de style et de balisage.
La seule différence entre le style et la classe pour les styles inlining est que l'un indique un objectif, permet d'utiliser du CSS simple et est principalement universel, tandis que l'autre ne l'est pas.
En termes simples, width : 100px a une signification universellement définie, alors que .width-100 pourrait signifier n'importe quoi.
Dans de très rares occasions, les styles spécifiques à un élément deviennent si complexes que les intégrer explicitement nuirait à la lisibilité, voire serait impossible (par exemple si cela nécessite des requêtes multimédias).
Dans ces cas, les classes utilitaires sont fondamentalement la seule option, même si elles sont laides.
Dans un monde idéal, celles-ci pourraient être traitées séparément des classes de mixage spécifiques, et j'ai même envisagé d'utiliser un préfixe pour les distinguer plus facilement, mais je n'ai finalement pas trouvé de bon moyen pour qu'elles ne soient pas laides.
J'aime l'idée de préfixer les classes utilitaires avec un + pour représenter qu'elles ajoutent une sorte de fonctionnalité à l'élément, contrairement aux classes normales, qui spécifient le type d'un élément.
Et c’était à peu près tout. Bien sûr, il n'y a pas deux projets identiques, et parfois les règles doivent être un peu contournées pour rester pratiques, mais dans l'ensemble, c'est mon cadre pour décider comment donner une certaine apparence à une chose à l'écran.
Quelles sont vos pensées ? Est-ce que tu détestes ça ? Pensez-vous que cela a du sens ? Faites-le-moi savoir en commentaire ?
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!