Pattern Library Development


Anyone using the Pattern Library is encouraged to contribute back to it. If you run into issues or find the documentation unclear, please file an issue on github.

We are also looking for any help with improving the library. Whether it's a bug fix, documentation improvements, a variation of a component, or a brand new component, we can help you contribute.

If you're interested in contributing or getting better at front end development, you can join our loyalty slack channel: #cop-front-end.

If you have any questions at all -- please don't hesitate to ask for help!

Reading the CSS

We developed the library using Sass because it works just like CSS but provides a bit of extra functionality such as variables, reusable functions (called 'mixins'), and easier file structuring. It also helps with maintainability. For example, instead of littering different colour hex codes across the codebase, we use a colour function that only returns colours that the UX team has approved:

.button {
    color: color('pink');

    &:hover {
        color: color('pink-light-1')

Please note that some feature of Sass are easy to overuse, such as nesting and extends, so we limit their use as much as possible. We also use a linter that gives errors when new code does not match our standards.

To learn more about Sass, check out the official website.

Naming Convention: BEM

Except for some basic elements like typography and our grid system, everything in the Pattern Library is prefixed with 'am-' (e.g. 'am-button'). This helps us avoid conflicts with other libraries.

To keep our CSS easy to understand and maintain we adopted a common naming convention for our css classes called BEM: Block, Element, Modifier. We only use classes to add styles, and our styles are named something like this: 'block__element--modifier', which can also be thought of as 'parent__child--variation'.

To learn more about BEM and object oriented CSS, check out this article on BEM.

Here's an example of Sass that uses the BEM naming convention:

.am-button {
    color: color('pink');

    &:hover {
        color: color('pink-light-1');

.am-button__arrow {
    display: block;
    float: right;
    color: color('copy-grey');

.am-button--wide {
    width: 100%;

Just by looking at this Sass, we can understand the structure of the button and how to use the "wide" variation of it in our HTML.


We are building these components so that they are accessible to all visitors to our web projects. Not only is this a legal obligation in Ontario, and it makes a big difference in the quality and experience of the AIR MILES brand.

You will notice that certain styles make use of ARIA attributes for hiding and showing content. This helps us ensure that accessibility devices such as screen readers know how to communicate the content of the page.

Please see the confluence page on accessibility, and Squareknot's guide to accessibility for more information.

Browser support

Modern browsers now have most of the browser market share, and we only support relatively recent browsers: IE11 and up, and the last 2 versions of "evergreen browsers" such as Chrome, Firefox, Safari, and Edge.

Mobile first development

We are embracing a mobile first approach to web development because it makes responsive web development much easier. This means that our media queries, grids, and components are all built first for a mobile sized view, then modified for larger views afterwards. While it might seem counterintuitive at first, there are plenty of good reasons to adopt this standard.