zui HTML5/CSS3 boilerplate: structure
Where the HTML5 BoilerPlate and Normalize.css projects leave off zui boilerplate defines a specific markup structure for optimal semantics (i.e. well formed documents easily parsed by humans and bots alike and accessible regardless of useragent such as desktop browser, mobile device, screen readers, and perhaps most important bots like googlebot).
The theory in this markup is to rarely change the base markup and selector scheme from project to project by implementing a structure capable of rendering 99% of all potential presentation design/layouts by only modifying the base CSS. This internet development strategy is heavily inspired by the idea behind the CSS Zen Garden in order to maximize consistency, speed up development, and ensure stable progressive/responsive techniques are implemented without risk and minimal hassle. Ideally one could move from project to project and never wonder where a resource was located or what/how it is named.
Overview
- All base elements are assigned ID or CLASS because they are faster selectors and help with specificity.
- All base IDs and CLASSes are named by their semantic role not by location or appearance. Where more specificity is required an extra class is assigned but the base id/class always remains.
- Rich HTML5 semantic tags are used appropriately (e.g. header, hgroup, footer, nav, section) and headings start over at h1 in any given section.
- Non-semantic containers (i.e. wrappers) useful for more complex designs are baked in.
Base structure (selectors only)
html
head
body
#doc
#hd
#hd_hd
#pg
#pg_pg
#mn
#mn_hd
#mn_entry
.article
.article_hd
.article_entry
.article_ft
#mn_ft
#sb
#sb_sb
#sb_hd
.sb_aside
.sb_aside_hd
.sb_aside_entry | .nav_list
.sb_aside_ft
#ft
#ft_ft
#ft_hgroup
#ft_nav_a
#ft_legal
| Legend | |
|---|---|
| #doc | DOCUMENT Represents the entire body Allows/simplifies styling not possible directly on the body tag |
| #hd | Document HEADER Contains the masthead/branding/primary navigation of the entire page |
| #hd_hd | Non-semantic Allows/simplifies styling not possible otherwise This “foo_foo” convention is used anytime an element requires a wrapper. |
| #pg | Virtual body for PAGE surrounded by branding Partially-semantic Contains the MAIN/SIDEBAR(s) content Allows/simplifies styling not possible otherwise. |
| #pg_pg | Non-semantic |
| #mn | MAIN content/message of page The real reason anyone is at this url If all other content were stripped from the page (like RSS or mobile presentations) #mn would stand on it’s own. |
| #mn_mn | Non-semantic |
| #mn_hd | Optional HEADER for main content Represents heading/nav/etc… where more than one “article” is used. Omitted where only one “article” exists |
| #mn_entry | Main ENTRY that may or may not require it’s own header/footer Always present whether there is one or a hundred “articles”. Semantically indicates that we are ABOUT to show content but we don’t know how many sections of content (i.e. can contain a single article or a long list of article entries like a blog index). |
| .article | Actual ARTICLE CONTENT Contains the article header/entry/footer Typically an “article” tag but could also be “section” if an interactive form/app is the so-called article, or “nav” if the content is an index list of other content. Indeed on #mn_entry could contain a series of mixed html5 semantic tags without screwing up the css presetnation because the ID/Classes don’t care what tag they are applied to making the css much more flexible because we inherently know the difference between nav.article, article.article, section.article as necessary because we have been explicit with our semantics. |
| .article_hd | ARTICLE HEADER/ING Heading of Article At least an h1 typically byline and other meta |
| .article_entry | Finally some content Always a “section” tag |
| .article_ft | ARTICLE FOOTER Close of Article Meta, bio, and nav related to article |
| #mn_ft | Optional FOOTER for main content Represents meta/nav/etc… where more than one “article” is used. Omitted where only one “article” exists |
| #sb | SIDEBAR Where more than one sidebar is used: #sb (always primary), #sb_foo, #sb_bar (whatever as long it starts with #sb_) |
| #sb_sb | Non-semantic Where more than one sidebar is used: #sb_foo_sb_foo |
| #sb_hd | Optional SIDEBAR HEADER While optional, it is possible to include a header that is “visuallyhidden” which only appears to screen readers and bots thus improving accessibility and SEO. Where more than one sidebar is present: #sb_foo_hd |
| .sb_aside | Any ancillary SIDEBAR content Typically an “aside” tag but could also be a “nav” Contains it’s own header/entry/footer as necessary. |
| .sb_aside_hd | Optional ASIDE HEADER Note visuallyhidden technique for accessibility and SEO |
| .sb_aside_entry | Sometimes Non-semantic Semantically unnecessary except in rare circumstances but the styling of sidebar is greatly simplified and enhanced. Note that this is often replaced by ul.nav_list because sidebar asides are often navigation as opposed to ads or supplemental content. |
| .sb_aside_ft | Optional ASIDE FOOTER |
| #ft | Document Footer Contains the end of document content for the entire page |
| #ft_ft | Non-semantic |
| #ft_hgroup | Branding and FOOTER HEADING Semantically groups the footer content |
| #ft_nav_a | FOOTER NAVIGATION Same concept as #hd_nav_a but semantically treated as secondary navigation |
| #ft_legal | FOOTER CREDITS/POLICY As simple as a copyright line or could be it’s own section with minor links for privacy and terms |
Base Structure (showing semantic tags)
html
head
body
div#doc
header#hd
div#hd_hd
hgroup#hd_hgroup
h1#hd_brand
h2#hd_brand_tag
time.doc_pubdate
nav#hd_nav_a
h1.visuallyhidden
ul.nav_list
div#pg
div#pg_pg
section#mn
div#mn_mn
header#mn_hd
h1
div#mn_entry
article.article
header.article_hd
h1
section.article_entry
h1...
footer.article_ft
footer#mn_ft
section#sb
div#sb_sb
header#sb_hd
h1.visuallyhidden
aside.sb_aside
header.sb_aside_hd
div.sb_aside_entry
footer.sb_aside_ft
nav.sb_aside
header.sb_aside_hd
ul.nav_list
footer.sb_aside_ft
footer#ft
div#ft_ft
hgroup#ft_hgroup
h1#ft_brand
h2#ft_brand_tag
nav#ft_nav_a
h1.visuallyhidden
ul.nav_list
div#ft_legal
This structure provides optimal HTML5 semantics that benefits accessibility, SEO, and future applications of standards compliant richly semantic formats and microformats. But in the short term it provides a rapid development boilerplate markup capable of producing nearly any layout with presentations for nearly any platform. Placed on top of the good work of the folk of the HTML5 BoilerPlate and Normalize.css projects you have an optimized cross-useragent workhorse.
Of course these are just my opinions. But if the media has taught me anything it is to say what you think really loud as if it were gospel. zui HTML5/CSS3 boilerplate structure is the only way to markup and style your projects. Ha.
Learn more and see a demo in the zui html/CSS section of this site (and no, this site has not been fully updated to this version of zui markup, but that is sort of the point, it’s about moving forward building on a base, not redoing everything ;)
One Response to zui HTML5/CSS3 boilerplate: structure
[...] the zui HTML5 base markup as our structure we implement almost exactly the HTML5 BoilerPlate project taking advantage of a multitude of great [...]