Development standards

SCSS

General

• Production CSS MUST be written in SCSS files. Inline styles MUST NOT be used.
• SCSS files should be developed as non-compiling partials with an underscore prefix and included into an overall compiling site/application SCSS file.
• Compiling SCSS files should only include partials from the same project or global folders, but NOT reference partials from other projects. If such a partial is needed it should be promoted to be a global partial.
• Partials should be given relevant, semantic names.
• All pages should work with JavaScript disabled so that no content is withheld from the user.

Standards and Naming conventions

• Selectors MUST be given names relating to their function, not their properties. (i.e. class=“urgent” not class=“red”)
• Selectors MUST use hyphen notation (lower case hyphen delimited).
• Colour lighten / darken MUST NOT be used to change globally defined colours
• Font sizes MUST be declared in rems.
• !important may ONLY be used on an exception basis to override a value which cannot be changed. !important declarations MUST always be followed by a comment explaining why it has been used.

Variables

• Variables MUST be defined in the global _classes.scss file.
• Variables should be named using a BEM style convention $block__element--modifier (eg. $colour__teal--70 or $settings__font-size--annotation)
• All colours MUST be declared globally as a variable referenced from the _classes.scss file.

Variable groups

$font__

Variables for the available font stacks. Used in the $font mixins with other standard parameters or as a variable for specific overrides.

$path__

Standard path prefixes to reused locations (e.g. images, fonts etc).

$settings__

Variables for standard global values, such as font sizes, border radius etc.

$colour__

Base colours and their permitted variations.

$link-colour__ *set to values defined with $colour__

Link colours and their permitted variations.

$cta-colour__ *set to values defined with $colour__

CTA colours and their permitted variations.

Mixins / Extends

• SCSS mixins should be named using a BEM style convention.
• Code to be reused without a variable parameter should be defined in an extend unless required inside a media query.
• Flexbox rules should be defined through the mixins contained in the _flex.scss file.

Mixin groups

$font__

Mixins to all the addition of standard fonts and variations to components (serif / sans-serif / bold / demi /regular).

$text-style__

Mixins for to apply specific consistent text styles to components to override their default behaviour (headings / stand first / annotations etc).

Media queries

• Rules should not be defined in the ‘For all' section and then overridden in each media query.
• Each partial should contain media queries for different breakpoint variances. Styles that apply across all breakpoints should be in the ‘For all' section and variations between different breakpoints defined inside the relevant media queries.
• All partials should begin with the standard layout in Appendix 1. Variances may be added if needed following the same conventions as the default (eg. @media #{$large-only} { })

Grid usage

• Nested grids MUST be used in line with Zurb Foundation 5 standard markup.
• Grids MUST be contained inside a <div class=“row”> and child <div> elements MUST at least have the class “columns” as well as any supplementary breakpoint or layout classes.

Form/application design

• Grids should be used only for overall layout rather than customised element width.
• Form elements should be appropriately sized for affordance to relate to their purpose and amount of anticipated data. Input fields in the small breakpoint should be 100% width by default.
• Input elements should have an ID, associated with the appropriate label element, and customised widths applied to this ID in percentage values.
• Labels should be positioned above form elements in line with the input's left edge and should have a for attribute to the associated input ID.
• Input elements should be populated with a placeholder attribute to demonstrate anticipated content format supported by a standard IE8 + 9 javascript polyfill to overcome browser shortcomings.
• Capture forms of up to three fields may have no visible label and use only placeholder attributes. In this instance labels should still be in the markp but visually hidden.
• Primary action buttons (submit / next) should be in line with form inputs (i.e. left aligned). Secondary action buttons (back / cancel) should be afte the primary action button but in line with it.
• Errors should be highlighted by a halo on the input and text beneath in a standard error design.
• Inline form validation sould be used if possible, supported by identical server side validation where javascript is disabled. When a form is submitted containing errors, as well as the inline error markers, a panel at the top of the form listing the errors should also be displayed.
• HTML5 input types should be used where appropriate (eg. <input type=“email”>, type=“number”, type=“url”) to aid usability of more capable browsers and devices.
• Adding form input attributes to over-ride unhelpful native mobile browser behaviour should be considered for use as appropriate (eg. turn off autocorrect on a name input).
• Example attributes include: autocomplete=“off”, autocorrect=“off", autocapitalize=“off” or “words”, spellcheck=“false".
• Telephone numbers should be wrapped in an anchor with a tel: href attribute e.g. <a href=“tel:+1234567890”>

Buttons/CTAs

• Buttons and call to action links use the standard styling %cta-styles. Natively the styling of cta links will change depending on their location within the page between the <main class=“primary”>, <aside class=“secondary”> and <aside class=“tertiary”> elements.
• When it is necessary to over-ride the default cta link behaviour, the class “over-ride” should be added along with either “alpha”, “beta” or “gamma” to invoke the styling of primary, secondary or tertiary respectively.
• Pages should only contain one primary CTA.

Links

• Inline text links within paragraphs MUST be styled with a native underline which disappears on hover.
• Lists of links should not be underlined natively but underline on hover.
• Links that are styled as CTA buttons should not be underlined either natively or on hover.

Old IE

• CSS that applies to old version of IE (IE9 and below) should be created in a single SCSS partial file per area (eg. corporate, global, economia) which are then compiled into a single CS S file per instance (eg. corporate-ie.css).
• Version specific CSS should be targeted using the IE version class assigned to the html element via conditional comments.
  • .oldie targets IE8 and below
  • .ie8 targets IE8 only
  • .ie9 targets IE9 only

Style and messages

We want to ensure that what and how we communicate is consistent across all our channels and audiences.

Please visit the company intranet section 'Style and Messages' for full details