Layout Specifications in Version 1.6

From Joomla! Documentation

Revision as of 00:12, 24 December 2009 by Andrea.tarr (Talk | contribs)

Replacement filing cabinet.png
This page has been archived - Please Do Not Edit or Create Pages placed in this namespace. The pages in the Archived namespace exist only as a historical reference, it will not be improved and its content may be incomplete.
Documentation all together tranparent small.png
Under Construction

This article or section is in the process of an expansion or major restructuring. You are welcome to assist in its construction by editing it as well. If this article or section has not been edited in several days, please remove this template.
This article was last edited by Andrea.tarr (talk| contribs) 6 years ago. (Purge)

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.

1. 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.

2. 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.

3. 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. 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

5. 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

6. 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

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

  1. Community member to step up on this matter

8. 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