DokuWiki css_guidelines

css_guidelines:80_characters_wide

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:00:24+00:00

<- Table of ContentsTitling -> 80 caractères de large Quand cela est possible, limitez la largeur des fichiers CSS à 80 caractères. Les raisons à cela incluent : * La capacité à avoir de the ability to have multiple files open side by side; * viewing CSS on sites like GitHub, or in terminal windows;

css_guidelines:anatomy_of_a_ruleset

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:03:42+00:00

<- TitlingMulti-line CSS -> Anatomie d'une base de règles Avant de discuter comment écrire nos bases de règles, familiarisons-nous avec la terminologie en vigueur : [selector] { [property]: [value]; [<--declaration--->] } Par exemple: .foo, .foo--bar, .baz { display: block; background-color: green; color: red; }

css_guidelines:architectural_principles

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:11:45+00:00

<- Hacking SpecificityHigh-level Overview -> Architectural Principles On peut vous pardonner si vous pensez que l'idée d'architecture pour du CSS est un concept quelque peu grandiose et inutile : pourquoi quelque chose de si simple et évident ( straightforward) aurait besoin de quelque chose de si comlexe ou considéré comme tel qu'une architecture ?! Eh bien, comme nous l'avons vu, la simplicité du

css_guidelines:bem-like_naming

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:32:48+00:00

<- Hyphen DelimitedNaming Conventions in HTML -> BEM-like Naming Pour de plus étendus, interrelated éléments d'interface utilisateur requiérant un nombre de classes, on utilise des conventions de nommage BEM-like. BEM, signifiant Block, Element, Modifier, est une méthodologie front-end mise au point par des développeurs travaillant à Yandex. Alors que BEM est une méthodologie complète, nous nous intéressons ici seulement à ses conventions de nommages. Et au-delà de cela, les conventions de nom…

css_guidelines:commenting

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:14:45+00:00

<- HTMLHigh-level -> Commenter La charge cognitive du travail avec CSS est énorme. Avec tant de choses dont il faut être conscient, et tant de nuances spécifiques aux projets dont se souvenir, la pire situation dans laquelle se trouvent les développeurs est d'être la-personne-qui-n'a-pas-écrit-ce-code. Ce souvenir de ses propres classes, règles, objets, et aide et possible a un certain point, mais toute personne qui hériterait de code

css_guidelines:composition_over_inheritance

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:35:00+00:00

<- DRYThe Separation of Concerns -> Composition over Inheritance Maintenant que nous sommes habitués à repérer les abstractions et à créer des responsabilités uniques, nous devrions être en bonne position pour créer des omposites plu scomplexes d'une série de composants bien plus petits. Nicole Sullivan fait une analogie avec l'usage de légos; de petites pièces à responsabilité unique qui peuvent être combinées en un nombre de quantités et permutation différentes pour créer une multitude de rés…

css_guidelines:css_selectors

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:39:10+00:00

<- Taking It FurtherSelector Intent -> Sélecteurs CSS Un des aspect les plus fondamental et critique de l'écriture de CSS maintenable est extensible est, peut-être surprenamment, les sélecteurs. Leur spécificité, portabilité et réusabilité ont tous un impact direct sur l'usage que nous en tirerons, et des maux de tête qu'ils nous donneront peut-être.

css_guidelines:disclaimers

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T15:55:37+00:00

<- The Importance of a StyleguideSyntax and Formatting -> Disclaimers CSS Guidelines est un guide de style; il n'est pas le guide de style. Il contient des méthodologies, techniques, trucs et astuces que je recommanderais fermement à mes clients et équipes, mais vos propre goût et circonstances pourraient être différents. Votre usage peut varier. Ces lignes directrices sont très arrêtées, mais elles ont été essayées, testés, stressed, raffinées, cassées, retravaillées et revisitées au travers d…

css_guidelines:dry

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:34:17+00:00

<- The Open/Closed PrincipleComposition over Inheritance -> DRY DRY, qui correspond à Don’t Repeat Repeat Yourself, est un micro-principe utilisé en développement logiciel et qui vise à éviter la répétition d'éléments clé au minimum. Une définition formelle est : " [e]very piece of knowledge must have a single, unambiguous, authoritative representation within a system.

css_guidelines:general_rules

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:53:25+00:00

<- Selector PerformanceSpecificity -> General Rules Vos sélecteurs sont fondamentaux dans l'écriture de bon CSS. Pour résumer rapidement les sections plus haut : * Sélectionnez ce que vous souhaitez de manière explicite, plutôt que de dépendre des circonstances ou coincidences. Une bonne Selector Intent will rein in the reach and leak of your styles.

css_guidelines:hacking_specificity

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:10:55+00:00

<- !importantArchitectural Principles -> Hacking Specificity Avec tout ce que nous avons dit sur la spécificité et la nécessité de la garder aussi basse que possible, il est inévitable que nous rencontrions des problèmes. Quels que soient les efforts que nous y mettions, aussi consciencieux que nous soyons, il y aura toujours des cas où nous devrons nous battre avec et hacker les spécificités.

css_guidelines:high-level_overview

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:19:49+00:00

<- Architectural PrinciplesObject-orientation -> High-level Overview À un très haut niveau, notre architecture peut vous aider à : * fournir un environnement sain et constant; * s'adapter au changement; * grow and scale your codebase; * promouvoir la réutilisation et l'efficacité;

css_guidelines:high-level

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:17:03+00:00

<- CommentingLow-level -> High-level Pour les commentaires longs qui documentent des sections ou composants entier du document, on utilises des commentaires multilignes DocBlock-esque qui répondent à la règle des 80 caractères de large.. Voici un exemple réel du

css_guidelines:html

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:13:26+00:00

<- Meaningful WhitespaceCommenting -> HTML Étant donné la nature intrinsèquement interconnecté du HTML et CSS, il serait négligent de ma part de ne pas couvrir quelques règles concernant la syntaxe et le formatage du balisage. Toujours mettre les attributs entre “”, même s'ils marcheraient sans cela. Cela réduit les chances d'accident, et est davantage familier pour une majorité de développeurs. Bien que les deux possibilités suivantes fonctionnent (et soient valides) :

css_guidelines:hyphen_delimited

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:22:09+00:00

<- Naming ConventionsBEM-like Naming -> Hyphen Delimited Toutes les classes sont délimitées avec un tiret tel que : .page-head { } .sub-content { } Le Camel case et les underscores ne sont pas utilisées pour les classes habituelles, les exemples suivant sont incorrects : .pageHead { } .sub_content { }

css_guidelines:ids_in_css

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:59:46+00:00

<- SpecificityNesting -> IDs in CSS Si nous voulons garder la spécifité basse, ce qui est le cas, il existe une règle simple, facile et immédiate que nous pouvons respecter pour nous aider : éviter d'utiliser les Id en CSS. Non seulement les Id sont par nature non réutilisables, mais elles sont aussi largement plus spécifiques que tout autre sélecteur, et deviennent donc des anomalies en terme de spécificité. Alors que le reste des sélecteurs conservent une spécificité très basse, les sélecteu…

css_guidelines:important

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:07:15+00:00

<- NestingHacking Specificity -> !important Le terme !important donne la chair de poule à la plupart des développeurs front-end. !important est une manifestation directe de problèmes de spécificité; c'est une manière de tricher pour échapper aux guerres de spécificités, mais vient généralement avec un prix élevé. Il est parfois vu comme un dernier recours — une tentative désespérée de parer aux conséquences d'un bien plus grave problème dans votre code.

css_guidelines:indenting

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:06:32+00:00

<- Multi-line CSSMeaningful Whitespace -> Indentation Tout comme l'indentation des déclaration individuellesn=, indenter des bases de règles entières pour signaler leur relation l'une à l'autre, par exemple : .foo { } .foo__bar { } .foo__baz { } En faisant cela, un développeur peut voir d'un coup d'œil quet .foo

css_guidelines:index

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:37:25+00:00

* Introduction * The Importance of a Styleguide * Disclaimers * Syntax and Formatting * Multiple Files * Table of Contents * 80 Characters Wide * Titling * Anatomy of a Ruleset * Multi-line CSS * Indenting * Indenting Sass * Alignment * Meaningful Whitespace * HTML * Commenting * High-level * Object–Extension Pointers * Low-level * Preprocessor Comments * Removing Comments * Naming Conventions * Hyphen Delimited * BEM-lik…

css_guidelines:introduction

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T15:53:31+00:00

<- The Importance of a Styleguide -> Introduction CSS n'est pas un joli langage. S'il est simple à apprendre et de démarrer avec celui-ci, il devient rapidement problématique à n'importe quelle échele raisonnable. Il n'y a pas grand chose que nous puissions faire pour changer comment le

css_guidelines:javascript_hooks

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:35:58+00:00

<- Naming Conventions in HTMLTaking It Further -> JavaScript Hooks La règle est qu'il n'est pas sage de lier CSS et JavaScript avec les même classes que celles-qui lient HTML & CSS. Cela car en agissant ainsi vous ne pourriez appliquer (ou enlever) uniquement le JavaScript où le CSS en ajoutant (ou enlevant) ladite classe. Il est bien plus propre, plus évident, et bien plus maintenable, de lier votre JavaScript à des classes spécifiques.

css_guidelines:location_independence

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:41:49+00:00

<- ReusabilityPortability -> Location Independence Étant donné la nature toujours changeante de la plupart des projets d'UI, et l'avancée vers davantage d'architectures basées sur des composants, il est dans notre intérêt de ne pas seulement styler les choses selon où elle sont, mais aussi selon ce qu'elles sont. C'est à dire que le style de nos composants ne devrait pas être lié à l'endroit où ils sont — il devrait être totalement indépendant de leur emplacement. Prenons l'exemple d'un bouton …

css_guidelines:low-level

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:18:41+00:00

<- High-levelPreprocessor Comments -> Low-level Nous voulons parfois commenter certaines déclarations spécifiques ( = ligne ) dans une base de règles. Pour cela on utilise une sorte de note de bas de page inversée. Voici un commentaire plus complexe détaillant les headers de site mentionnés plus haut :

css_guidelines:meaningful_whitespace

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:08:00+00:00

<- IndentingHTML -> Espaces signifiants Tout comme avec l'indentation, on peu fournir beaucoup d'information à travers un usage abondant et judicieux d'espaces entre les bases de règles. On utilise : * Une (1) ligne vide entre deux bases de règles closely related.

css_guidelines:multi-line_css

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:04:43+00:00

<- Anatomy of a RulesetIndenting -> CSS Multilignes Le CSS devrait être écrit sur plusieurs lignes, à l'exception de circonstances très spécifiques. Il existent de nombreux bénéfices à cela : * Des chances réduites de voir apparaîtres des merge conflicts, car chaque fonctionnalité existe sur sa propre ligne.

css_guidelines:multiple_files

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T15:57:49+00:00

<- Syntax and FormattingTable of Contents -> Fichiers multiples Avec l'avénement récent des préprocesseurs, l'usage courant est de diviser le CSS en différents fichiers. Même sans préprocesseur, c'est une bonne idée de découper les blocs de code distincts en différents fichiers qui sont concaténés durant l'étape de build.

css_guidelines:naming_conventions_in_html

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:34:30+00:00

<- BEM-like NamingJavaScript Hooks -> Conventions de nommage en HTML As I previously hinted at, les conventions de nommage ne sont pas nécéssairement si utiles dans notre CSS. Là où la puissance des conventions de nommage se situe réellement est dans notre balisage. Prenez le nommage

css_guidelines:naming_conventions

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:21:17+00:00

<- Removing CommentsHyphen Delimited -> Conventions de nommage Les convention de nommage en CSS sont très utiles pour rendre le code plus strict, plus évident, et plus informatif. De bonnes conventions de nommages vous indiquerons à vous et votre équipe : * quel type d'effets à une classe;

css_guidelines:naming

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:47:18+00:00

<- PortabilitySelector Performance -> Naming Comme l'a dit une fois Phil Karlton, “There are only two hard things in Computer Science: cache invalidation and naming things.” Je ne commenterais pas l'affrimation ci-dessus, mais la seconde partie m'a tourmenté pendant des années. My advice with regard to naming things in

css_guidelines:nesting

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:04:11+00:00

<- IDs in CSS!important -> Nesting Nous avons déjà vu comment le nichage peut amener à une dépendance à la localisation et à du code potentiellement inefficace, mais il est temps de regarder à un autre de ses problèmes : il rend les sélecteurs plus spécifiques.

css_guidelines:object-orientation

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:21:37+00:00

<- High-level OverviewThe Single Responsibility Principle -> Object-orientation L'orientation objet est un paradigme de programmation qui divise un programme plus large en de plus petits objets in(ter)dépendants qui ont tous leur propre rôle et responsabilité. Citons Wikipédia : " La programmation Orientée Objet (POO) est un paradigme de programmation qui représente le principe d'objets (…) qui sont généralement des instances de classes, (et sont) utilisées les unes avec les autres pour conce…

css_guidelines:portability

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:43:46+00:00

<- Location IndependenceNaming -> Portabilité Réduire, ou, idéalement, enlever les dépendances de localisation signifie que nous pouvons déplacer nos composants plus librement au sein de notre balisage, mais pouons-nous améliorer notre capacité à bouger nos classes de composant à composant ? À un plus bas niveau, voici les changement que nous pouvons opérer sur les sélecteurs qui font les sélecteurs eux-même — en opoosition aux composants qu'ils créént — pour les rendre plus portables. Prenons …

css_guidelines:preprocessor_comments

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:19:31+00:00

<- Low-levelRemoving Comments -> Preprocessor Comments Avec la plupart — si ce n'est tous — les préprocesseurs, nous avons l'option d'écrire des commentaires qui ne seront pas compilés dans le fichier CSS de sortie. Comme règle, utilisez ces commentaires pour commenter du code qui ne sortira pas du fichier SCSS. Si vous documentez du code qui sera compilé, utilisez des commentaires qui seront aussi compilé. Par exemple ceci est correct :

css_guidelines:removing_comments

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:20:19+00:00

<- Preprocessor CommentsNaming Conventions -> Enlever les Commentaires Il va de soi qu'aucun commentaire ne devrait trouver le chemin des environnement de production. Tout le CSS devrait être minifié, résultant en la perte des commentaires, avant d'être déployé.

css_guidelines:reusability

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:40:49+00:00

<- Selector IntentLocation Independence -> Reusability En avancant vers une approche davantage basée sur des composants pour la construction d'UI, l'idée de réusabilité est une pierre angulaire. Nous voulons être capable de déplacer, recycler, dupliquer et regrouper des composants au sein de nos projets.

css_guidelines:selector_intent

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:40:10+00:00

<- CSS SelectorsReusability -> Selector Intent Il est important lorsque l'on écrit du CSS d'établir correctement la portée de nos sélecteurs, et de sélectionner les bonnes choses pour de bonnes raisons. Le Selector Intent est le processus de décision et définition de ce que vous souhaitez comme style et comment vous allez le sélectionner. Par exemple, si vous souhaitez styler le menu principal de navigation de votre site, un sélecteur comme celui-ci serait incroyablement peu sage :

css_guidelines:selector_performance

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:50:09+00:00

<- NamingGeneral Rules -> Performances des Sélecteurs Un sujet qui est—avec la qualité des navigateurs modernes—plus intéressante qu'importante, est les performances des sélecteurs. En gros, avec quel rapidité le navigateur peut déterminer la correspondance des sélecteurs de votre

css_guidelines:specificity

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:01:03+00:00

<- General RulesIDs in CSS -> Specificity comme nous l'avons vu, CSS n'est pas le langage le plus sympatique: opérant globalement, fuyant de partout, dépendant de la localisation, difficile à encapsuler, basé sur l'héritage… Mais ! rien de tout cela n'approche les horreurs de la spécificité.

css_guidelines:syntax_and_formatting

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T15:57:08+00:00

<- DisclaimersMultiple Files -> Syntaxe et formatage Une des formes les plus imples d'un guide de style est une série de règles concernant la syntaxe et le formatage. Avoir une manière d'écrire standard en CSS signifie que le code aura toujours l'air familier à tous les membres de l'équipe. Au-delà de ça, un code qui à l'air propre feels propre. C'est un environnement de travail bien plus agréable, et incite les autres emmbres de l'équipe à maintenir le standard de propreté qu'ils ont trouvé. U…

css_guidelines:table_of_contents

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T15:59:27+00:00

<- Multiple Files80 Characters Wide -> Table des matières Une table des caractères est un élément dont la maintenance est substentielle, mais les bénéfices données dépassent largement ses coûts. Il requiert un développeur appliqué de maintenir une table des matières à jour, mais le jeu en vaut la chandelle. Une table des matières fourni à l'équipe une référence uniique et complète de ce que contient le projet

css_guidelines:taking_it_further

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:38:23+00:00

<- JavaScript HooksCSS Selectors -> Taking It Further Comme mentionner précédemment, il s'agit de conventions très simples, dont une qui ne fait pas grand chose d'autre que de dénoter trois groupes distincts de classes. Je vous encourage à lire davantage sur les conventions de nommage afin de disposer de davantages de fonctionnalités —c'est quelque chose qu'il m'intéresserait d'approfondir.

css_guidelines:the_importance_of_a_styleguide

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T15:55:49+00:00

<- IntroductionDisclaimers -> L'importance d'un guide de style Un guide de style est un outil précieux pour une équipe qui : * conçoit et maintient des produits pour une durée raisonnable; * comporte des développeur aux différentes compétences et spécialités;

css_guidelines:the_open_closed_principle

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:32:42+00:00

<- The Single Responsibility PrincipleDRY -> The Open/Closed Principle Le open/closed principle est, à mon avis, piètrement nommé. cela car 50% des informations vitales sont omises de ce titre. Le open/closed indique que : " [s]oftware entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

css_guidelines:the_separation_of_concerns

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:36:54+00:00

<- Composition over Inheritance -> The Separation of Concerns (séparation des préoccupations) La separation of concerns est un principe qui, au premier abord, ressemble beaucoup au principe de responsabilité unique. La separation of concerns établit que le code ne devrait jamais être broken up

css_guidelines:the_single_responsibility_principle

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T17:23:37+00:00

<- Object-orientationThe Open/Closed Principle -> The Single Responsibility Principle Le single responsibility principle est un paradigme qui, de manière très libre, établit que tous les éléments de code (dans notre cas, les classes) devraient se focaliser sur une seule et unique chose. Plus formellement :

css_guidelines:titling

Anonymous (anonymous@undisclosed.example.com) — 2016-08-10T16:01:50+00:00

<- 80 Characters WideAnatomy of a Ruleset -> Titrage Commencez chaque nouvelle section majeure d'un projet CSS par un titre : /*------------------------------------*\ #SECTION-TITLE \*------------------------------------*/ .selector { } Le titre de la section est préfixé avec un symbole dièse afin de permettre de faire des recherches ciblées (avec grep ou autre) : au lieu de recherche titre-de-section qui peut renvoyer différents résultats, une recherche ciblée sur #titre-de-section ne r…