General front-end and HTML guidelines
This document details the guidelines and standards for front-end development at NML, and all web applications built should take these into consideration. It is an evolving document and should be reviewed as and when required to keep up with changes in technology and best practice.
- Front-end code should display clear separation of presentation, content, and behaviour.
- Markup should be well formed, semantically correct and valid.
Always include a readme document (in markdown format) documenting any code dependencies and build processes.
CSS frameworks (Bootstrap, Foundation, etc) are not encouraged for production code but may be used for rapid prototyping.
NML’s own lightweight scalable, responsive SASS framework should be used for creating all sites and applications.
- Backbone with Marionette
but other frameworks may be considered based on context.
As a number of our clients still require IE8 support an appropriate version of jQuery is best in those cases.
All sites should be built mobile first and optimised for a range of devices.
Feature detection is always preferable to device detection.
All work is considered in a responsive, mobile first, way unless the project dictates otherwise.
Responsive design isn't just a way of developing, it is a way of thinking that needs to flow through the entire site development process from content, UX, design and development.
It is out of the scope of this document to go through the specifics of developing responsively, but some suggested techniques to be used during development are talked about in Sass – Mobile First.
The NML custom build process, currently using Grunt, for front-end code should always be used for image optimisation, minification and concatenation. Additional documentation about performance required here.
- Markup and code should be written in a way that is inherently accessible.
- Designers and developers should strive always for organisation of content and clarity of navigation.
- Content should be marked up in a logical reading order.
- Background and text should have enough contrast to be readable even without colour.
- No information should be conveyed by sound alone.
- All websites should be navigable via the keyboard.
- Specify roles for areas using WAI-ARIA document landmark roles.
- Ensure form inputs all have labels.
- Ensure all images have alt tags.
Indentation and spacing
- For all languages, indent your code with spaces.
- For all indents use 2 spaces.
- Use Unix line endings
Readability vs Compression
- Internet Explorer 8+
- Google Chrome
We test in the latest 3 versions of Firefox, Chrome and Safari due to them using incremental auto-updates.
The HTML5 Doctype and HTML5 features will be used on all web projects.
To ensure HTML5 markup compatibility with older browsers, use HTML5shiv to ensure markup compatibility
We will test our markup against the W3C validator, to ensure that the markup is well formed. 100% valid code is not a goal, but validation certainly helps to write more maintainable sites as well as debugging code. We need not guarantee markup is 100% valid, but instead assure the cross-browser experience is consistent.
General Markup Guidelines
The following are general guidelines for structuring your HTML markup. Authors are reminded to always use markup which represents the semantics of the content in the document being created.
<p>elements for paragraph delimiters NEVER multiple
- Create space between elements with CSS margins NEVER multiple
- Items in list form should always be housed in a
<dl>, never a set of
- Place an HTML comment around DIV tags that contain a larger amount of markup to indicate the element you're closing. It will help when there is a lot of nesting and indentation. For example:
<!-- Start of .content -->
//some markup goes here
<!-- End of .content -->
- Make use of
Scopeattribute) when appropriate.
- Make use of
<dl>(definition lists) and
<blockquote>, when appropriate.
<label>fields to label each form field. The
forattribute should associate itself with the input field, so users can click the labels and obtain focus.
- Do not use the
sizeattribute on your input fields. The
sizeattribute is relative to the font-size of the text inside the input. Apply a width via CSS if required instead.
- Always use title-case for headers and titles. Do not use all caps or all lowercase titles in markup, instead apply the CSS property
- Use microformats and/or Microdata where appropriate, specifically
- Tables shouldn't ever be used for page layout – only for tabular data.
While the HTML5 specification defines quotes around attributes as optional for consistency with attributes that accept whitespace, all attributes should be quoted.
<a href="mylink.html" title="My Link Title" data-attribute="32">This is my Link</a>
All markup should be delivered as UTF-8, as it's the most friendly for internationalization. It should be designated in both the HTTP header and the head of the document.
Set the character set using
Also make sure that your IDE is saving as UTF-8.