---
tags: IAS
---
# IAS - External Developers Standards

This document outlines the standards that are expected of external developers when working on any IAS project. This is a living document and will be updated regularly. Any work being carried out on the IAS systems should be completed inline with these standards.

## General Development

You must aim to reuse code where possible. This makes maintaining the site easier, and makes the projects build faster.

All IAS sites have their own repository on github. Where possible, external developers will be invited to the relevant repository and must work alongside a Fresh developer using branches and pull requests at all times.

If only frontend work is to be completed, it may be the case that only asset files are provided and further instructions will be given for those requirements on a per-project basis. When this is the case all standards outlined must be met to avoid any clashes with other areas of the project.

## SVG Icons

Most IAS projects use a symbols (aka sprite) file for holding icons that are used. You should use SVGs where possible instead of images.

If the project uses a symbols file you must add the symbol to the file. It must contain an id prefixed with `ic_` eg `ic_book` or `ic_complex`

## Per-Project Standards

- [IAS Course Bookings](#Project-IAS-Course-Bookings)

## Project: IAS Course Bookings

The IAS Course bookings system is a booking system written in PHP/Laravel.

### CSS

You must use SCSS and strictly BEM style.

:::danger
No deviation from BEM is allowed. You must not use html tag selectors, only classes are allowed.
:::

We have full control over all templates for this system, therefore we also have full control over what classes are used.

If you need to style a child element then you must add a class to that element.

For example:

.form {
    ...
    &__field {
        input {
        ...
        }
    }    
}    

<form class="form">
    <div class="form__field">
        <input type="text" name="email">
    </div>
</form>

The above is not acceptable. Below is an example of how this should be implemented using BEM.

.form {
  ...
  &__field {
    ...
  }
}

.field {
  &__input {
    ...      
  }    
}

<form class="form">
    <div class="form__field field">
        <input class="field__input" type="text" name="email">
    </div>
</form>

This would be the correct way to add classes using BEM. The form is a block element, but the `field` div functions both as an element (for the `.form` class) and a block itself. `input` then becomes an element of the `.field` block.

### File Structure

Each component you make must be a partial, contained in it's own SCSS file. These must be imported into one central file, which is then set as Webpack's entrypoint.

Each SCSS file, with the exception of the Webpack entrypoint, must be prefixed with an underscore.

**Example File Structure**

- index.scss
- _typography.scss
- _reset.scss
- _variables.scss
- components/
- _hero.scss
- _footer.scss
- _cta.scss
- pages/
- _homepage.scss
- _contact.scss
- _service.scss

### Future proofing SCSS components

Where possible every effort should be made to generalise any component that needs to be created so that it may be used in different configurations using BEM modifiers. Naming of classes should reflect what their base component is, and what it's purpose is.

For example, take a component that has an image on the right, and content on the left.

It could be coded so that it must always be an image on the right, and content on the left, but this is not a resuable component.

What if we wanted to use it so that it had the image on the right? Or two columns of content, or two images? These things must be considered when creating the classes.

.two-column {
  display: flex;

  &__item {
    flex: 1 1 50%;
    
    &--content {
      padding: 2rem;
      ...
    }

    &--image {
      margin: 0;
      object-fit: cover;
      ...
    }
  }

  &--reverse {
    flex-direction: row-reverse;
  }
}

Content Left - Image Right

<div class="two-column">
    <div class="two-column__item two-column__item--content">
        <p>
            Here's some content
        </p>
    </div>
    <div class="two-column__item two-column__item--image">
        <img src="#" alt="" />
    </div>
</div>

That same element but Image Left - Content Right

<div class="two-column two-column--reverse">
    <div class="two-column__item two-column__item--content">
        <p>
            Here's some content
        </p>
    </div>
    <div class="two-column__item two-column__item--image">
        <img src="#" alt="" />
    </div>
</div>

### Responsive design

You must develop mobile first.

Typography should use breakpoints in the global styles, so typography is consistent across the site.

Components should break where it makes sense for that component. You should not use standardised breakpoints for components across the whole site, like with typography. You should consider the best breakpoint on a per-component basis.

Media queries should use px units.

### Units and spacing

You should not use pixels (px) as a unit within CSS with the exception of:

- borders
- box-shadows

You should use a combination of REMs, %, VW/VH, and sometimes EMs.
REMs are based on the root element font size (Root Element). You should always use whole numbers of REM units. This will improve consistency throughout the site. See the next section (typography) for more on using REMs.

Obviously for column widths REM isn't suitable, so you will need to use % or VW/VH.