This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
This document is incomplete and I am rewriting it in several places to incorporate new perspectives I have gained over the last year. Ultimately, I will be able to simplify the naming conventions so I hope you will find the next version easier to digest. I advise that you not use this fplan in its present state.
Fortenberry Page Layout Access Nomenclature (FPLAN): An XHTML Structure-Naming Convention - October 2007
Introduction
As web developers strive (or in some cases struggle) to integrate semantic markup, accessibility and adhere to the Progressive Enhancement approach, separating structure (XHTML), presentation (CSS), behavior (JavaScript) and content (XML), there becomes an increasing pressure to use similar practices of standardization in the naming convention for the id and class attribute value assignments to enhance access in the foundational level, the structured XHTML document. Such a naming convention should be viewed as integral to the semantic markup and provides great value in that one does not have to "recreate the wheel" when designing page structure/layout nomenclature for each new website. This convention thus provides increased efficiency through automation. Also, such a naming convention can be designed so that it assures extensible and semantic hooks for specifying elements in CSS styles and JavaScript DOM node selections. This makes it a natural fit for the semantic web. The page nomenclature described below meets these criteria. I have found that if used as outlined below, this nomenclature turns a process that at present can be a cumbersome chore into one of the simplest and easy parts of web development. Just as with any good standard, framework or boundary, when followed, this nomenclature can provide greater freedom overall and truly liberate the web designer who would prefer to spend more time on more creative aspects of web development.
Space Is Semantic: Missing The Trees for the Forest
Not every xhtml tag can or should be marked up with a non-positional reference as it's id and class name. While it is valuable to use function rather than position/presentation to name id and class attribute values, there is a tendency to forget that there are a few elements on a web page that do not benefit from this behavior. You will understand this when you come to the realization that a web page is inherently a spatial element, at least partially defined by place. Web developers/designers get into a predicament if they do not recognize that only most of the markup on a web page is about something other than space. There remains a few useful (perhaps necessary) parts of the web page that are inherently (thus semantically) spatial and must be named as such in their id and class attribute value names. There must be some reference to this space when it comes down to actually assigning the semantic id and class names into larger spaces/shells. Using only semantic names works well in the abstract world of xml but once it comes time to put that semantically-wrapped data on "paper", we must tell it where. We do this with css. But, css must have a name for this "where". Isn't the css hook that refers to a spatial element such as a container, wrapper or shell only truly semantic when it refers to that element as such?
Naming Predicament
The W3C describes the body of websites that practice this coding technique as the semantic web. The goal of a semantic web is to provide "a common framework that allows data to be shared and reused across application, enterprise and community boundaries". The semantic naming practice works well for the tag pieces of markup because the non-semantic tags have largely been deprecated and are no longer available, leaving only the approved tags. We now know, for example, that the heading tags (h1, h2, h3, h4, h5 and h6), although inferring a position, they are technically considered structural (even though it is not truly semantic). The inferred position of these header tags is based on it's relationship with the other structured elements on the page, for example, headers go just ahead of new sections and never occur inside a paragraph. The other parts of a web page, when treated with the same logic, are not found to be acceptable. For example, when defining a 2-column layout, it would be better to name the columns based on the content they will hold rather than "leftcol" or "rightcol". Even though the column placement is strictly structural, it's lack of semantic purity makes it undesirable. In the case of value assignments, the freedom to choose any word is available to us. So how does one choose in similar predicaments with css hooks..it boils down to minimizing the evils or using the most logical. For these reasons, being a semantic purist is impossible. Just as in many other aspects of life, the world is full of relationships that do not readily lend themselves to easy categorization. There will always be overlap and the exceptions to the rule. Nevertheless, it is valuable and desirable to keep in the spirit of the semantic web. that when one is choosing names for should base the choice of names. This semantic naming practice, when applied to css hooks can be a bit of a paradox.
The page nomenclature described herein works on the assumption that a limited, underlying XHTML page structure or "skeleton" is necessary to provide access points used as hooks by CSS and JavaScipt for applying broad layout or behavior control. Under this assumption, this minimal skeletal structure can be described as a collection of shells which are accessed using any one of a number of the id and class attribute values (described below) inside div tags in the XHTML file. The permutation choices for the page structure, skeletal divs, or shells, should be finalized during the earliest stages of design, preferably on paper, to describe only coarse, basic layouts such as a 2-column layout, 3-column layout, etc. The page's finer-grained layout will be defined later using CSS positioning and presentation styles applied to the sections. Even finer granularity will be applied in the id and class attribute values for proximate data and ultimate data (described below). While you should expect to use more shells in a home page layout than you would in the layout of internal pages of a web site, these shells must be used sparingly and only for coarse layout.
Anatomy of FPLAN
In accordance with the FPLAN, each XHTML page is a document (html root) with a head and a body as usual; but, there is a difference in nomenclature lying inside the body. The body contains a collection of shells defined by their id or class attribute value in a div tag. Shells are collections of sections defined by their id or class attribute value in a div tag. Sections are collections of proximate data (referenced content) or ultimate data (embedded content) represented by the various available XHTML tags (e.g. paragraph, ordered list, image, etc.).
Data
Data refers to the referenced (proximate) or embedded (ultimate) content. This content may be stored in a remote xml file, a database, an include file or embedded into the XHTML file itself.
Proximate Data
Proximate data is that which is referenced in the XHTML file but not contained there. Instead, it may be stored in an XML file, a database, an include file or generated on-the-fly. Divs holding the proximate data, or references to the ultimate data should be contained inside sections. Names for the containing divs should have content-describing id or class names.
Ultimate Data
Ultimate data is that which is embedded in the XHTML file itself. This method of data storage is increasingly discouraged for complex or large sites since it is inefficient and unwieldy. Divs holding the ultimate data should be contained inside sections. Names for the containing divs should have content-describing id or class names.
Types of Content
This nomenclature treats all content (on a meta level) as nouns rather than as verbs and thus, all content on a web page can be said to be divided into two types of nouns based on their form or function. Features and menus are the two types of content and represent its form and function, respectively.
The term "menu" is used rather than "navigation", for describing function content because navigate is a verb and menu is a noun. A menu is not navigation, rather, it is used for navigation. Features are the "content" that is accessed via the navigation of menus. More simply put, menus navigate features. Some traditional examples of features and menus are seen in the lists below. Some of the following traditional label references to features and menus will be used in the FPLAN, but many will be discarded and replaced with more generic, space-agnostic, semantic labels. As you will see, there is no shortage of name choices and there should be no problem finding the right name for the specific needs of your web page.
Feature references include but are not limited to the following traditional labels:
- main content
- banners
- headers
- footers
- containers
- primarycontent
- secondarycontent
- supporting "content"
- supplemental "content"
- media, documents, images, etc.
- articles, blog entries
- forms
- logos/branding
- data (structured in tables)
- etc.
Menu references include but are not limited to the following traditional labels:
- global navigation
- section navigation
- local navigation
- breadcrumbs
- previous, next, back and top buttons
Levels of Prominence (LOPs)
All content on a web page can be described by it's Level of Prominence, or priority relative to the rest of the content on that page. The Levels of Prominence do not necessarily reflect the size or importance of the feature or menu they name. Sometimes, a very strong message may be conveyed through an item of lesser prominence such as a login or shopping cart menu. These tiny items, while found up in the corner and very small (with little prominence), are nevertheless very important. Importance can be conveyed through consistency of location, (such as logo placement in the top left corner or shopping cart placement in the top right corner) or through Level of Prominence. The 8 Levels of Prominence follow, listed in order (with the exception of the neutral "meta") from highest prominence to lowest prominence:
Eight Levels of Prominence
- meta (feature refers to self - i.e. sitemap, about, etc.)
- main (most prominent feature or menu - i.e. article or global navigation)
- major (feature or menu of major prominence - i.e. second column or section navigation)
- meso (feature or menu of moderate prominence - i.e. third column or local navigation)
- minor (feature or menu of minor prominence - i.e. article teasers or kickers or previous, next, back, top button)
- mini (feature or menu with reduced prominence - i.e. supporting text or archive category links)
- minute (feature or menu with little prominence - i.e. supplemental text or tag clouds or shopping cart icon)
- micro (feature or menu with very little prominence - i.e. captions or article date/time stamps or bookmark/favorite/rss icons)
The Levels of Prominence should be assigned to shells and sections in order from highest to lowest (i.e. first meta, then main, then major, then meso, and so on...) without skipping when appropriate (but this is not required) just as one should use heading tags h1 - h6 in order without skipping. There are some cases where it would be more appropriate to skip an LOP however, depending on the site's complexity. For example, a simple site will only use two hbars (one at the top and one at the bottom) and assigning the bottom hbar a major LOP might not be as appropriate as assigning it a minor LOP. Developers should use their best judgement.
Shells
Shells are a collection of sections. Shells are strictly used as layout hooks for CSS and therefore may NOT contain proximate or ultimate data, similar in function to the traditional use of the "container", which is used here as well. A shell is implemented by assigning a class or id attribute to a div tag surrounding the content for that collection of sections.
The container shell is required and may only be used once because it is the root shell and will contain all the other shells. Its div tag therefore must be identified using an id attribute rather than a class attribute. The other shells may be used an unlimited number of times and thus, their div tags may be identified using either an id attribute or a class attribute. Shells may contain other shells but care should be used to minimize this for the sake of efficiency, elegance and clean code. Remember the purpose of a shell is to define the page layout or skeletal framework within which the sections will rest.
Attribute values used as shell names are predetermined and may be used alone as Base Shells or may be extended to represent more complex layouts by using them in conjunction with a prefix containing one of the 8 Levels of Prominence as follows in the prominence/shell permutations (called Complex Shells). Complex shells should be used in order from most to least prominent where appropriate:
Four Base Shell Names
- container
- wrap (short form of "wrapper")
- block
- bar
Twenty-Two Complex Shell Names
|
|
|
Shell Considerations
A significant effort was made to use semantically pure structure names in defining the page layout nomenclature; however, you will note the use of spatially-referenced names used in the shells col and ban. A column implies a long vertical extent to it's content that could be rendered erroneously after a site redesign in which this was not considered and the content was subsequently styled, for example, with a width of 100%, essentially becoming a ban rather than a col. Although the chances of this causing any real problems is minimal, it is worth noting. The same applies to the banner which implies a broad horizontal swathe for it's content. The pros and cons of using these semantic impurities were considered in great depth and determined to be worth the risk since it was determined that there does not seem to be a better option available and this one minimizes any risks. However, their use means that one must be careful during a site redesign to change the shell names if they are no longer semantically consistent with their content and applied styles. This task should require minimal effort using a find/replace function since all of the shell names will be consistent and logical. One should also note that this lends further strength to the conviction that shells should be used sparingly, only for describing broad layouts. For example, the nesting of shells inside other shells beyond a few layers of depth could quickly become unwieldy during a site redesign or during routine maintenance by a new designer and would defeat the purpose of this nomenclature.
Sections
Sections are div elements that contain a collection of proximate and ultimate data features or menus; therefore, the base of all sections is either a feature or a menu type. All sections must be contained in a shell or another section. There may be multiple sections per shell. Sections may contain other sections. Just as with any id or class, when sections are named using ids, they may occur only once on the page and if they are used as a class, they may occur multiple times on a page. The use of sections should be minimized in favor of shells. If sections are used, they must match their containing shell. For example, the "mainbanmenu" section must be contained in the "mainban" shell or it should not be used at all. In other words, you may use a section as long as the shell is also being used and found to need extending. Because section names are hierarchical, care must be taken to use them as classes only in situations where they are true siblings to one another to remain semantically pure. Otherwise, the sections are best labeled as ids rather than classes. This strict usage encourages efficient coding practice. Attribute values used as section names are predetermined and may be used alone or may be extended to represent more complex layouts by using them in conjunction with a prefix containing one of the 8 Levels of Prominence and/or shell names. The sections are thus named using the label permutations of shell/type, prominence/type or for the Complex Sections, prominence/shell/type. Every section name must contain either "feature" or "menu". Shells may not contain either of these two names; therefore, their presence makes it easy to distinguish shells and sections.
Base Sections
Base sections should be used in order of prominence when used in conjunction with LOPs
| Prominence/Type Section Names | Type/Shell Section Names |
|
|
Complex Sections
Complex sections should be used in order of prominence. Complex sections are assumed to be used only in complex layouts for large and complex sites and therefore, adherence to LOPs order is crucial.
Forty-Eight Prominence/Shell/Type Section Names
|
|
|
|
|
|
Choosing Attribute Value Names
As you can see, there is no shortage of name choices and there should be no problem finding the right shell/section matches for the needs of your web page. With so many options, it behooves one to choose well. Unless your website has pages numbering in the tens of thousands with several subsites, you will not even come close to needing this many options. Developers of small sites might prefer to use only the base shells and sections rather than extending them with Levels of Prominence. Developers of medium sites may prefer to limit themselves to using the first 5 Levels of Prominence (meta, main, major, meso and minor) in extending their shells and sections. Others may prefer to choose one of the handpicked nomenclatures outlined below. One useful tip when using LOPs is to match the LOP in complex sections with those in their respective complex shells (e.g. mainmenu section inside mainvbar shell, minorfeature section inside minorblock shell, etc.). Also, be sure to choose the names that are most intuitive to you and reuse them as often as possible. For example, anytime I design a site with a small menu in the top right corner containing links for search, home, contact, about, etc., I always name this shell the "metahbar". The menu section inside the metahbar is called "metamenu". This consistency makes it easy for me to work with the css faster and make fewer mistakes.
Assigning Attribute Value Names
Anytime you learn a new way of doing a thing, there is a brief period of discomfort. If one takes the attitude that this is expected and must be patiently endured, then the process of learning becomes quite easy. Such is the case with learning this new way of assigning attribute value names in your layouts. The easiest way to train your mind to work easily with this new nomenclature is to take small steps. First draw out on paper the layout you desire (such as a 2-column or 3-column layout, etc.). Then, determine if your site will benefit or be overly burdened by using the Levels of Prominence (LOPs) prefixes. Assign a shell to the different areas of that layout. Once the shells have been assigned, you can add matching sections if needed.
Steps
- Draw rough areas for desired home page layout
- Look at each area and decide if the base shells are sufficient or not
- If you need to extend the base shells, determine how many LOPs deep is needed
- Assign shells to rough areas
- Decide if and/or to what extent, you need LOPs for sections
- Assign section areas to each shell
- Assign proximate or ultimate data to sections
- Repeat process for internal page layout
- Remove any overlap by matching up and using the same shells and sections from home page on internal page
- Type your divs (with closing div comments) into your XHTML file to finish your layout structure.
- Enter proximate and/or ultimate data.
Sample Layouts
Simple Personal Site (one-column layout)
For the simple layout, you really only need to use base shells and base sections except for the hbar (horizontal bar) shell because there is one in the top and one in the bottom of the layout. Because we use hbar twice, we need to apply an LOP to the two hbars, starting with main. Using common sense, it seems appropriate that the second hbar does not need to be assigned a major LOP so we give it a minor LOP.
- container shell
- metabar shell (holds top data)
- majorbar shell (holds side data)
- mainbar shell (holds main data)
- colophon shell (holds bottom data)
- metafeature section (holds logo and graphic)
- mainmenu section (holds menu)
- mainfeature section (holds main data)
- minorfeature section ()
Simple Business or Non-profit Site (two-column layout)
- container shell
- metabar
- metamenu
- mainbar shell (holds top data)
- mainmenu section (holds menu)
- majorbar shell (holds side data)
- mainfeature shell (holds main data)
- colophon shell (holds bottom data)
Complex Business Site (three-column layout)
- container shell
- mainbar shell (holds top data)
- majorbar shell (holds side data)
- majorfeature shell (holds main data)
- colophon shell (holds bottom data)
Enhancing Nomenclature Benefits
The way to get the most out of using this nomenclature is to create a few templates to satisfy the bulk of your design needs and choose from one of those each time you start a new site. One option is to create simple, moderate and complex templates. Another option would be to create a few different templates for each level of complexity, based on different artistic or layout variations. Take it a step further and create the matching templates for any include, css or other supporting files. No matter what template options you choose, you can easily modify them to suit any minor changes needed with each new site.
Dealing With Divs
Web developers know how important it is to keep div tags nested properly. A simple and quick method for ensuring this is always maintained is to use a comment following each closing div. The comment simply states and names the div it is closing. This method has proven remarkably easy and a valuable timesaver. See the following example:
Example Code Depicting Closing DIV Comment
<div id="metahbar">.
.
.
</div ><!-- closes metahbar -->
Numbered Name Alternatives
Div attributes may use numbers for their values rather than words/letters thus far discussed. A numbering system could be applied with 1 being the highest or most prominent level so that larger numbers describe increasingly granular content. While this may at first appear to be easier to implement than the subjective nomenclature described above, one should consider the loss of information inherent in such a system before using numbers. The nomenclature described above includes a rich, informative system of naming that, once learned, is more intuitive. If one uses numbers, it is recommended that a data table be created to assign word/letter descriptors for each number and make this available to all present and future designers or maintainers. In addition, imagine the difficulty in maintaining a site where classes are numbers. If numbers are used, it is recommended that they only be used with ids and not with classes. Preferably, numbers would only be used in shells if desired, and not in sections.
Nomenclature Checklist
- limit use of LOPs
- label each closing div with a comment
Further Considerations
It should be noted that this FPLAN has only been implemented on small to medium sites with pages numbering up to 100 and with only moderate complexity. Although it showed great promise for these cases, before recommending FPLAN to enterprise users, proper testing would first need to be carried out and analyzed on large and very complex sites. In the end, it may be determined that the FPLAN is useful only for smaller, simpler sites. Or, it may be that the FPLAN may be modified or enhanced to increase its richness and complexity so that it is sufficient to handle any website.
Specific Names
- logo
- nameplate
- menu
- sidebar (as in an aside)
- copyright
- breadcrumbs
- intro
- preamble
- subtitle
- title
- blurb
- preview
- tagline
- teaser
- pullquote
- fineprint
- skip
- colophon
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.