Layout Specifications in Version 1.6

From Joomla! Documentation

This page has been archived. This page contains information for an unsupported Joomla! version or is no longer relevant. It exists only as a historical reference, it will not be improved and its content may be incomplete and/or contain broken links.

Principles for Core Layouts

The base for this document is a result of the discussions in the Google group Joomla-CMS-dev during the summer of 2009. Use this document to continue the discussion by fixing this wiki.

Validates to nominated standards

xHTML 1.0 strict. We will validate the core layouts to strict, but the template could still use whichever standards they want, whether that’s xHTML 1.0 strict, transitional or HTML5. It is the template which actually controls the validation standard. Override layouts will be used for full HTML5 use.

Semantically relevant markup


  1. Use tables to display relational information and do not use them for layout.
  2. Use the th (table header) to describe a column or row in a table with relational information and Group rows with only th (table header) cells with the thead (table head) element.
  3. Group the rest of the table with the tbody (table body) element.
  4. Use scope attribute to associate table labels (th cells) with columns or rows and headers and id attributes to associate table labels (th cells) with individual cells in complex tables
  5. Use a class to indicate odd/even rows


  1. Associate the label with the form element by using the "for" in the label
  2. Use fieldset and legend to group appropriate items together
  3. Make sure that the order of the elements makes sense when tabbing through them
  4. Make sure that the form can be completed and submitted using the keyboard
  5. Indicate required fields to the user before they input the field. For this project we will use an asterisk before the field to indicate required fields and will have a JText comment "Required fields are indicated with an *."
  6. Use semantic markup for the form based on the use of the form, not the fact that it is a form. For instance, use divs for contact pages, login screens and creating/editing articles, pagination & filters, use tables for lists of tabular data (e.g. list of articles in Article Manager), use ul for simple lists such as parameters. Decide how you would mark it up if it were not a form, then markup that way.

Hierarchical structure

  1. Use heading tags instead of class names on the component & content headers.
  2. H1 will be reserved for the site header, so h2 is the old componentheader and h3 the old contentheading.
  3. Everyone has different ideas on the best hierarchical method, but choosing to pick one rather than add an additional parameter will give both ease of use and to give the template designers something consistent. Current SEO thought is that headers give weight, but they are no longer distinguishing among the higher header the way they used to. Usability prefers to keep them in order.

ID's & Classes:

  1. Use ID if it really should be an ID, otherwise use CLASS.
  2. Be careful that you can't end up with one ID more than once on a page when the page is actually served lists for menus
  3. Use as many classes as needed and no more.
  4. Use a standardized approach to class names and ids. Change to new class/id if the old ones don't make sense.

Due consideration is given to support RTL sites

  1. We need RTL expertise on this because it's important and we don't have the skills.
  2. text align: right
  3. Should this change the order of fields: e.g. should the columns in Article Manager swap around based on LTR or RTL.
  4. Use sprintf for parameters that require the option to reorder.

Adheres to nominated accessibility principles

  1. Aim for WCAG 2.0 AA compliance
  2. Header mark up for headers, menus (module), filters and selections
  3. Bring forms into compliance
  4. Appropriate relational markup on tables (including scope)
  5. Javascript accessible (the only javascript in the front end layouts is checking for required fields. That's also covered server-side)
  6. Use links for links and mark it up so it can get focus and be seen to have focus
  7. Able to navigate logically and fully with keyboard

Standardised nomenclature (naming practices, etc)

  1. Use existing names where possible and follow similar conventions. (Note: for the change from 1.5 to 1.6 change from jargon names such as componentheading to generic names such as page-title)
  2. For new classes & ids:
  1. One word preferred
  2. When two words are use, use all lowercase, no punctuation
  3. If you are using related classes hyphenate between the words: .button2-left, .button2-right, button2-top, .button2-bottom, #content-box, #submenu-box, #border-top, #border-bottom

Aims to work on nominated browser versions

  1. IE7+, FF2+, Safari 3.1+, Opera 9.0+, Google Chrome
  2. IE6 should be usable
  3. Program for standards compliant browsers and put fixes for non- standard browsers in separate files

Consideration is given to a variety of devices (phones, etc)

  1. Community member to step up on this matter

Principles for use of scripting languages

  1. Includes unobtrusive JavaScript, rich JavaScript, Mootools std, etc
  2. There is very little JavaScript in use in the frontend core at present.
  3. Mootools and compatibility is under discussion in Google group Joomla-CMS-Dev