Frontend Code Standards and Best Practice
This post primary motivation is two- fold:
- code consistency and using best practices.
The starting blocks of any website is HTML. There was some discussions around XHTML, but industry has accepted that HTML is the future of the web.
Markup defines the structure and outline of a document and offers a structured content. Markup is not intended to define the look and feel of the content on the page beyond rudimentary concepts such as headers, paragraphs, and lists. The presentation attributes of HTML have all been deprecated and style should be contained in style sheets.
HTML5 is a new version of HTML and XHTML. The HTML5 draft specification defines a single language that can be written in HTML and XML. It attempts to solve issues found in previous iterations of HTML and addresses the needs of web applications, an area previously not adequately covered by HTML. (source).
We will use the HTML5 Doctype and HTML5 features when appropriate.
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. Isobar does not guarantee code is 100% valid, but instead assures the cross-browser experience is fairly consistent.
A proper Doctype which triggers standards mode in your browser should always be used. Quirks mode should always be avoided.
All markup should be delivered as UTF-8, as its the most friendly for internationalization. It should be designated in both the HTTP header and the head of the document.
Setting the character set using <meta> tags.
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.
- Use actual P elements for paragraph delimiters as opposed to multiple BR tags.
- Make use of DL (definition lists) and BLOCKQUOTE, when appropriate.
- Items in list form should always be housed in a UL, OL, or DL, never a set of DIVs or Ps.
- Use label fields to label each form field, the for attribute should associate itself with the input field, so users can click the labels. cursor:pointer; on the label is wise, as well. note 1 note 2
- Do not use the size attribute on your input fields. The size attribute is relative to the font-size of the text inside the input. Instead use css width.
- Place an html comment on some closing div tags to indicate what element you’re closing. It will help when there is lots of nesting and indentation.
- Tables shouldn’t be used for page layout.
- Use microformats and/or Microdata where appropriate, specifically hCard and adr.
- Make use of THEAD, TBODY, and TH tags (and Scope attribute) when appropriate.
- Always use title-case for headers and titles. Do not use all caps or all lowercase titles in markup, instead apply the CSS property text-transform:uppercase/lowercase.
The HTML5 specification defines quotes around attributes as optional. For consistency with attributes that accept whitespace, all attributes should be quoted.