ძირითადად გონივრული მიდგომები CSS-სა და Sass-თან დაკავშირებით

1. ტერმინოლოგია
   • ინსტრუქციის გამოცხადება
   • სელექტორები
   • მახასიათებლები
2. CSS
   • გაფორმება
   • კომენტარები
   • OOCSS და BEM
   • ID Selectors
   • JavaScript hooks
   • საზღვრები
3. Sass
   • სინტაქსი
   • თანმიმდევრობა
   • ცვლადები
   • Mixins
   • Extend directive
   • Nested selectors
4. თარგმანები
5. ლიცენზია

ინსტრუქცია არის სელექტორის(ან სელექტორების ჯგუფის) სახელისა და მახახასიათებლების ერთობლიობა რომელსაც აქვს შემდეგი სახე:

.listing {
  font-size: 18px;
  line-height: 1.2;
}

ინსტრუქციის გამოცხადებისას, "სელექტორები" განსაზღვრავენ თუ DOM-ის რომელ ელემენტებზე გავრცელდება მითითებული მახასიათებლები. სელექტორი შეიძლება განისაზღვროს HTML ელემენტის, ელემენტის კლასის, აიდის ან მისი რომელიმე ატრიბუტის მეშვეობით. ქვემოთ მოყვანილია რამდენიმე მაგალითი:

.my-element-class {
  /* ... */
}

[aria-hidden] {
  /* ... */
}

და ბოლოს, მახასიათებლები ანიჭებენ სელექტორებით არჩეულ ელემენტებს სტილს. თითოეული მახასიათებელი შედგება სახელისა და მნშვნელობისაგან, ნებისმიერი ინსტრუქცია შეიცავს ერთ ან რამდენიმე მახასიათებელს. მაგალითად:

/* some selector */ {
  background: #f1f1f1;
  color: #333;
}

⬆ დასაწყისში ასვლა

• გამოიყენე მარტივი tab(2 გამოტოვება) სტრიქონის დაწყებისას.
• კლასის სახელის განსაზღვრისას უპირატესობა მიანიჭე ტირეს და არა camelCase-ს.
  • ქვედა ტირის და PascalCase-ების გამოყენებაც დაშვებულია თუ იყენებ BEM მიდგომას(დეტალები OOCSS და BEM სექციაში)
• არ გამოიყენო ID სელექტორები.
• ერთ ინსტრუქციაში რამდენიმე სელექტორის გამოყენების შემთხვევაში თითოეული მათგანი დაწერე ცალკე სტრიქონზე.
• ინსტრუქციის გამოცხადებისას, გამხსნელი ფიგურული ბრჩხილის } წინ დასვი გამოტოვება.
• მახასიათებელში, გამოტოვება დასვი ორწერტილის : შემდეგ და არა წინ.
• ჩამკეტი ფიგურული ბრჩხილი } დასვი ახალ სტრიქონზე.
• ინსტრუქციებს შორის გამოიყენე ცარიელი სტრიქონი.

ცუდი პრაქტიკა

.avatar{
    border-radius:50%;
    border:2px solid white; }
.no, .nope, .not_good {
    // ...
}
#lol-no {
  // ...
}

კარგი პრაქტიკა

.avatar {
  border-radius: 50%;
  border: 2px solid white;
}

.one,
.selector,
.per-line {
  // ...
}

• უპირატესობა მიანიჭე სტრიქონის კომენტარებს(// Sass-ის გარემოში) და არა ბლოკისას.
• უმჯობესია კომენტარი განათავსო თავის დამოუკიდებელ სტრიქონზე ვიდრე იმავე სტრიქონის ბოლოში სადაც კოდია.
• კოდისთვის რომელიც თვითონ ვერ აღწერს დანიშნულებას დაწერე დეტალური კომენტარი:
  • z-index მახასიათებლის შემთხვევაში
  • ბრაუზერთან თავსებადობის ან მასთან დაკავშირებული სხვა განმარტებისთვის

რეკომენდაციას ვუწევთ OOCSS და BEM-ის გარკვეული კომბინაციების გამოყენებას შემდეგი მიზეზების გამო:

• ისინი გვეხმარება HTML და CSS-ს შორის გასაგები, მკაცრად განსაზღვრული კავშირების შექმნაში
• ისინი გვეხმარება განმეორებით გამოყენებადი, დამოუკიდებელი კომპონენტების შექმნაში
• იძლევა ერთმანეთში ნაკლებად ჩალაგებული და ნაკლებად სპეციფიკური კოდის წერის საშუალებას
• გვეხმარება მასშტაბირებადი სტილების ცხრილების შექმნაში

OOCSS, ანუ ობიექტზე ორიენტირებული CSS, არის მიდგომა რომელიც ხელს გვიწყობს ვიფიქროთ ჩვენი სტილების ცხრილებზე როგორც ობიექტების ერთობლიობაზე, რომლებიც არის ხელახლა გამოყენებადი, განმეორებადი კოდის ამონარიდები რომელთა დამოუკიდებლად გამოყენება შესაძლებელია ვებსაიტის ნებისმიერ ნაწილში.

• Nicole Sullivan's OOCSS wiki
• Smashing Magazine's OOCSS-ს შესავალი

BEM ანუ "ბლოკი-ელემენტი-მოდიფიკატორი" არის HTML და CSS-ში სახელის განსაზღვრის შეთანხმება. აღნიშნული მიდგომა შემუშავებული იქნა "იანდექს"-ში კომპლექსური და მასშტაბური აპლიკაციებისთვის და ითვლება როგორც საფუძვლიანი მეთოდოლოგია OOCSS იმპლემენტაციისთვის.

• CSS Trick's BEM 101
• Harry Roberts' BEM-ის შესავალი

We recommend a variant of BEM with PascalCased “blocks”, which works particularly well when combined with components (e.g. React). Underscores and dashes are still used for modifiers and children. რეკომენდაციას ვუწევთ BEM-ის და PascalCased ბლოკების სინთეზის ვარიანტს, რომელიც განსაკუთრებულად კარგად მუშაობს კომპონენტებთან(მაგ. რეაქთ) კომბინაციის შემთხვევაში. ქვედა ტირეები და ტირეები კვლავინდებურად გამოიყენება მოდიფიკატორებსა და შვილებთან.

მაგალითი

// ListingCard.jsx
function ListingCard() {
  return (
    <article class="ListingCard ListingCard--featured">

      <h1 class="ListingCard__title">Adorable 2BR in the sunny Mission</h1>

      <div class="ListingCard__content">
        <p>Vestibulum id ligula porta felis euismod semper.</p>
      </div>

    </article>
  );
}

/* ListingCard.css */
.ListingCard { }
.ListingCard--featured { }
.ListingCard__title { }
.ListingCard__content { }

• .ListingCard არის ბლოკი და წარმოადგენს ყველაზე ზედა დონის კომპონენტს
• .ListingCard__title არის ელემენტი და წარმოადგენს .ListingCard-ის შთამომავალს რომელიც მონაწილეობს მთლიანი ბლოკის შექმნაში.
• .ListingCard--featured არის მოდიფიკატორი რომელიც წარმოადგენს .ListingCard ბლოკის ერთ-ერთ ვარიაციას ან მდგომარეობას.

მიუხედავად იმისა რომ CSS-ში ელემენტების დასელექთება შესაძლებელია ID-ს მეშვეობით, ეს მიდგომა ზოგადად მიჩნეულია როგორც ცუდი პრაქტიკა. ID სელექტორებს შემოაქვთ ზედმეტად მაღალი დონის სპეციფიკურობა ინსტრუქციებში და მათი ხელახლა გამოყენება შეუძლებელია.

სპეციფიკურობასთან დაკავშირებით დამატებითი ინფორმაციისთვის წაიკითხეთ CSS Wizardry-ს სტატის

Avoid binding to the same class in both your CSS and JavaScript. Conflating the two often leads to, at a minimum, time wasted during refactoring when a developer must cross-reference each class they are changing, and at its worst, developers being afraid to make changes for fear of breaking functionality.

We recommend creating JavaScript-specific classes to bind to, prefixed with .js-:

<button class="btn btn-primary js-request-to-book">Request to Book</button>

Use 0 instead of none to specify that a style has no border.

Bad

.foo {
  border: none;
}

Good

.foo {
  border: 0;
}

⬆ back to top

• Use the .scss syntax, never the original .sass syntax
• Order your regular CSS and @include declarations logically (see below)

1. Property declarations

   List all standard property declarations, anything that isn't an @include or a nested selector.

   .btn-green {
     background: green;
     font-weight: bold;
     // ...
   }

2. @include declarations

   Grouping @includes at the end makes it easier to read the entire selector.

   .btn-green {
     background: green;
     font-weight: bold;
     @include transition(background 0.5s ease);
     // ...
   }

3. Nested selectors

   Nested selectors, if necessary, go last, and nothing goes after them. Add whitespace between your rule declarations and nested selectors, as well as between adjacent nested selectors. Apply the same guidelines as above to your nested selectors.

   .btn {
     background: green;
     font-weight: bold;
     @include transition(background 0.5s ease);
   
     .icon {
       margin-right: 10px;
     }
   }

Prefer dash-cased variable names (e.g. $my-variable) over camelCased or snake_cased variable names. It is acceptable to prefix variable names that are intended to be used only within the same file with an underscore (e.g. $_my-variable).

Mixins should be used to DRY up your code, add clarity, or abstract complexity--in much the same way as well-named functions. Mixins that accept no arguments can be useful for this, but note that if you are not compressing your payload (e.g. gzip), this may contribute to unnecessary code duplication in the resulting styles.

@extend should be avoided because it has unintuitive and potentially dangerous behavior, especially when used with nested selectors. Even extending top-level placeholder selectors can cause problems if the order of selectors ends up changing later (e.g. if they are in other files and the order the files are loaded shifts). Gzipping should handle most of the savings you would have gained by using @extend, and you can DRY up your stylesheets nicely with mixins.

Do not nest selectors more than three levels deep!

.page-container {
  .content {
    .profile {
      // STOP!
    }
  }
}

When selectors become this long, you're likely writing CSS that is:

• Strongly coupled to the HTML (fragile) —OR—
• Overly specific (powerful) —OR—
• Not reusable

Again: never nest ID selectors!

If you must use an ID selector in the first place (and you should really try not to), they should never be nested. If you find yourself doing this, you need to revisit your markup, or figure out why such strong specificity is needed. If you are writing well formed HTML and CSS, you should never need to do this.

⬆ back to top

This style guide is also available in other languages:

• Bahasa Indonesia: mazipan/css-style-guide
• Chinese (Traditional): ArvinH/css-style-guide
• Chinese (Simplified): Zhangjd/css-style-guide
• French: mat-u/css-style-guide
• Japanese: nao215/css-style-guide
• Korean: CodeMakeBros/css-style-guide
• Portuguese (Brazil): felipevolpatto/css-style-guide
• Portuguese (Portugal): SandroMiguel/airbnb-css-style-guide
• Russian: rtplv/airbnb-css-ru
• Spanish: ismamz/guia-de-estilo-css
• Vietnamese: trungk18/css-style-guide
• Italian: antoniofull/linee-guida-css
• German: tderflinger/css-styleguide

⬆ back to top

(The MIT License)

Copyright (c) 2015 Airbnb

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

⬆ back to top