Demologo

Menar du...

    • Kategorier för din sökning

    • VISA ALLA SÖKRESULTAT

    Inget resultat
    Plattformen

    CSS & SASS - Kodstandard

    1. Architecture

    For scalable and maintainable projects, follow the principles of ITCSS. ITCSS stands for Inverted Triangle CSS and it helps you to organize your project CSS files in such way that you can better deal with CSS specifics like global namespace, cascade and selectors specificity.

    • Settings – contain grid, font, colors definitions, etc.
    • Tools – globally used mixins and functions. It’s important not to output any SCSS in the first 2 layers.
    • Generic – reset and/or normalize styles, box-sizing definition, etc. This is the first layer which generates actual SCSS.
    • Elements – styling for bare HTML elements (like H1, A, etc.). These come with default styling from the browser so we can redefine them here.
    • Objects – class-based selectors which define undecorated design patterns, for example media object known from OOCSS
    • Components – specific UI components. This is where majority of our work takes place and our UI components are often composed of Objects and Components
    • Utilities – utilities and helper classes with ability to override anything which goes before in the triangle, eg. hide helper class

    The triangle also shows how styles represented by selectors are ordered in the resulting CSS: from generic styles to explicit ones, from low-specificity selectors to more specific ones and from far reaching to localized ones.

    2. Guidelines

    2.1 Selectors

    • Do not use id or data attributes in CSS selectors.
    • Prefer classes over generic HTML elements (like span).
    • One selector per line

     

     

    Bad Practice:

    span { ... }
.page-container #stream .stream-item .tweet .tweet-header .username { ... }
.tweet span { ... }
.avatar { ... }
ul.top-menu li { ... }
ul.top-menu li ul li { ... }

     

     

    Good Practice:

    .avatar { ... }
.tweet-header .username { ... }
.tweet .avatar { ... }
.top-menu .first-level { ... }
.top-menu .second-level { ... }
    .one,
.selector,
.per-line {
  ...
}

    2.2 Nesting

    Avoid unnecessary nesting. Just because you can nest, doesn't mean you always should. Consider nesting only if you must scope styles to a parent and if there are multiple elements to be nested.
    • Keep selectors short and strive to limit the number of elements in each selector to three.
    • Scope classes to the closest parent only when necessary (e.g., when not using prefixed classes).

     

     

     

    Bad Practice:

    .product-box {
  h2 {
    font-size: 13px;
  }
  span {
    font-size: 11px;
  }
}

     

     

     

    Good Practice:

    }

.product-box-title {
  font-size: rem-calc(13);
}

.product-box-description {
  font-size: rem-calc(11);
}
    .page-container {
  .content {
    .profile {
      // STOP!
    }
  }
}

    2.3 Media Queries

    • Place media queries as close to their relevant rule sets whenever possible. 
    • Don't bundle them all in a separate stylesheet or at the end of the document.
    • Use Foundations mixin for breakpoints
    • Use Foundations breakpoint variables as the parameter  
    .three-images-block-item {

  @include breakpoint(medium down) {
    margin-bottom: 10px;
  }
}

     

    2.4 Comments:

    • Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.
    /* Bad example */
/* Modal header */
.modal-header {
  ...
}

/* Good example */
/* Wrapping element for .modal-title and .modal-close */
.modal-header {
  ...
}

     2.4 Class names

    • Keep classes lowercase and use dashes (not underscores or camelCase). Dashes serve as natural breaks in related class (e.g., .btn and .btn-danger).
    • Avoid excessive and arbitrary shorthand notation. .btn is useful for button, but .s doesn't mean anything.
    • Keep classes as short and succinct as possible.
    • Use meaningful names; use structural or purposeful names over presentational.
    • Prefix classes based on the closest parent or base class.
    .t { ... }
.red { ... }
.header { ... }

/* Good example */
.tweet { ... }
.important { ... }
.tweet-header { ... }

    2.5 Media Queries

    • Place media queries as close to their relevant rule sets whenever possible.
    • Don't bundle them all in a separate stylesheet or at the end of the document.
    • Use Foundations mixin for breakpoints
    • Use Foundations breakpoint variables as the parameter

    2.5 Components

    To keep stylesheets short and efficient it is usually a good idea to think of an interface as a collection of components.
    Components can be anything, as long as they:

    • Do one thing and one thing only;
    • Are re-usable and re-used across the project;
    • Are independent.

    For instance, a search form should be treated as a component. It should be reusable, at different positions, on different pages, in various situations. It should not depend on its position in the DOM (footer, sidebar, main content…).

     

    Most of any interface can be thought of as little components and I highly recommend you stick to this paradigm. This will not only shorten the amount of CSS needed for the whole project, but also happens to be much easier to maintain than a chaotic mess where everything is flustered.

     

    2.5.1 Component structure
    Ideally, components should exist in their own Sass partial, such as components/_button.scss. The styles described in each component file should only be concerned with:

    • The style of the component itself;
    • The style of the component’s variants, modifiers, and/or states;
    • The styles of the component’s descendents (i.e. children), if necessary.
    // Button-specific variables
$button-color: $secondary-color;

// Buttons
.button {
  display: block;
  padding: 1rem;
  background-color: $button-color;
  // … etc.

  &:hover,
  &:focus {
    background-color: darken($button-color, 10%);
  }

  // Breakpoints inside of the element
  @include breakpoint(medium) {
    display: inline-block;
  }
}

 // Variant of button
.button-large {
  padding: 2rem;
}

 // Icons within buttons
.button > i {
  color: $primary-color;
}

    2.6 Sizing

    Always use rem or rem-calc instead of pixel values. Avoid em unless there is a very good reason since it increases code complexity unnecessarily. 

      .footer {
    padding-top: rem-calc(20);
  }
     2.6.1 Unitless line-heights


    Use unitless values for line-heights when possible.

     

    .footer-button {
font-size: 1rem;
line-height: 1.5;

    "Unitless line heights are recommended due to the fact that child elements will inherit the raw number value, rather than the computed value. With this, child elements can compute their line heights based on their computed font size, rather than inheriting an arbitrary value from a parent that is more likely to need overriding."

    Css-tricks link

    2.5 File structure

    When using multiple CSS files, break them down by component instead of page. Pages can be rearranged and components moved.
     

    3. Recommendations

    3.1 Foundation

    • Do not use id or data attributes in CSS selectors.
    • Prefer classes over generic HTML elements (like span).
    • One selector per line

    Bad Practice 

    <button type="button" class="my-own-class-that-does-the-same-thing">Save</button>

    Good Practice 

    <button type="button" class="button success small">Save</button>

    Don't use Foundations classes as selectors in your own stylesheets and avoid to add classes to elements with Foundations classes if not necessary.

    Bad Practice:

    .row {
  background-color: #000;
}

.small-6 {
  margin-top: 10px;
}

     

    Good Practice:

    <div class="row column">
  <div class="category-description">
    
  </div>
</div>

    Also try keep code at minimum. Don't ever write out small-12 because it's standard for column and let's use column instead of columns, like following.

    Bad Practice:

    <div class="small-12 columns medium-6">
  Content
</div>

     

    Good Practice:

    <div class="column medium-6">
  Content
</div>

    3.2 Responsive

    • Have a responsive mindset when implementing a new design. Always code your components for all screen sizes, don't complete the "desktop" version first just to adjust it for mobile screens later. That makes it much easier for the next coder to make responsive adjustments without changing the entire code base.

    3.3 Practicality over purity

    • Strive to maintain HTML standards and semantics, but not at the expense of practicality. Use the least amount of markup with the fewest intricacies whenever possible.

    3.4 Editor preferences

    • Use soft-tabs set to two spaces.
    • No tabs allowed.
    • Trim trailing white space on save.
    • Set encoding to UTF-8.
    • Add new line at end of files.
    SCSS/CSS
    {{ langstr.C_JUMP_TO_TITLE }}
    • {{ headline.content }}
    SCSS/CSS