Comp to Code from the Content Out

A no-nonsense approach
for building out contemporary web comps
without compromising on quality.

Phase 2. Semantic Markup

The second major phase of the process is to create clean, simple, and semantic markup that corresponds to the content-out analysis you conducted of your comp in the first phase.

We start with block-level content markup, and move out from there to add purposeful groupings that are informed both by structural hierarchy and logical grouping that will come in handy for our layout work with CSS later.

A. Create Content Markup

In keeping with the "content-out" ideal, we start by creating only content markup. The analysis you completed in the first phase should serve as a tremendous aid as we now begin to create markup. You should already have determined your headings and the order in which the content should be coded.

Determine the structural content markup.

We start first with the structural content elements. Consider whether each element should be marked as a…

These elements are usually obvious and self-explanatory. Simply look at each element of content on the page and consider what it is. This is the heart of thinking about content from a semantics perspective.

We also need to be careful to enter our elements in the appropriate logical order. To ensure this happens, consider the following process:

  1. Typically a page will contain a header, main content area, and a footer, and it is logical to enter them in that order most of the time. So start by entering items that make up the header first, then move on to those that form the main content area, and then enter the footer contents last of all.
  2. For the contents inside each of these larger sections you likely conducted some analysis regarding groups of content—layout unites—and the order in which they should be coded. So carefully code each unit of content from these sections in the order you determined, regardless of the order in which they're presented.

Add relevant inline detailing

With the overall structural content markup in place we can hone in inside each block to add finesse as needed with inline elements such as <b>, <i>, <strong>, <em>, <cite>, <abbr>, and many others. However, we should note the semantic nuances that distinguish each one's best use from another's. Consider Jeremy Keith's explanation of how the <b>, <i>, <strong>, and <em> tags are now distinguished:

"The <b> element used to mean, ‘render this in bold.' Now it is used for some text ‘to be stylistically offset from the normal prose without conveying any extra importance.' If the text has any extra importance, then the <strong> element would be more appropriate…

"Similarly, the <i> element no longer means ‘italicize.' It means the text is ‘in an alternate voice or mood.' Again, the element doesn't imply any importance or emphasis. For emphasis, use the <em> element." (p. 18)

Hyperlinks should also be added in order to set up the desired interactivity between pages of the site and other pages on the Web.

B. Add groupings

Once again, the analysis we completed in Phase 1 has a significant implication for how we now step back and group the structural content elements in place so far. First, we start with layout units inside the outermost container units. Here we can make use of the following organizers:

In order to assist as we read our own code, as others read it in the future, and as we will need to select these groups with CSS later, it also behooves us to add short but semantically accurate labels to each group using class attributes.

In some of our container units we might have identified compound units that contain micro-layouts. These deserve careful consideration for additional markup.

In either case, a simple class attribute should also be added on the element or organizer so that we can later select and position it. While we don't want to get carried away adding organizers, an appropriate amount of organization both logically and structural groups related elements and provides succinct containers for positioning those units in the grid. So only add organizers where either or both of these situations applies and avoid adding groups you can't easily rationalize as logical groups.

The end result of this phase should be simple, neat markup that is logically ordered and grouped, and that uses the most appropriate semantic elements for each chunk of content.

Case Studies

Read the case study introductions »

Corner Bakery

Based on our analysis from phase 1 we have a solid game plan for how to create simple, semantic markup for each page of the prototype site.

Overall, we'll have a persistent masthead and footer that straddle a main content area on each page.

<header>
    <h1><a href="index.html"><img src="images/logo.png" alt="The Corner Bakery" /></a></h1>
    <nav>
        <ul>
            <li><a href="index.html">home</a></li>
            <li><a href="menu.html">menu</a></li>
            <li><a href="order.html">orders</a></li>
        </ul>
    </nav>
</header>
...
<footer>
    <p>Copyright &copy;2016 by The Corner Baker. All rights reserved.<br />
       Designed by Jennifer Gammie and Phil Schanely.</p>
</footer>

The site brand will be marked as an <h1> and the navigation as a list inside of a <nav>. We'll use a class of "active" on the corresponding navigation item to mark the current page. The footer contains a single paragraph.

The home page's main content area contains four units of text content—each labeled by a <h2>—and a fifth unit that is just a banner image. We'll be free to code them in the order users prioritized them: "Come visit", "Menu", "Orders", and "About Us" with the banner image placed last of all. The "Come visit" unit is the only unit that does not contain just paragraphs under its <h2>, but rather, a definition list where each label is a term and data forms a definition.

<main class="page-home grid-home">
    <div class="hrs">
        <h2>Come visit!</h2>
        <dl class="grid-info">
            <dt>Hours:</dt>
            <dd>
                <abbr class="day">Thu</abbr>&ndash;<abbr class="day">Sat</abbr>, 
                6:30<abbr class="daytime">AM</abbr>&ndash;2<abbr class="daytime">PM</abbr>
            </dd>
            <dt>Phone #:</dt> 
            <dd>(937) 776-3088</dd>
            <dt>Location:</dt> 
            <dd>71 North Main Street<br/>
                Cedarville, OH</dd>
        </dl>
    </div>
    <div class="menu">
        <h2><a href="menu.html">Menu</a></h2>
        <p>Dozens of pastries...</p>
        ...
    </div>
    <div class="orders">
        <h2><a href="order.html">Orders</a></h2>
        <p>Despite having fulfilling ...</p>
        ...
    </div>
    <div class="about">
        <h2>About Us</h2>
        <p>Corner Street Bakery ...</p>
        ...
    </div>
    <img class="banner" src="images/muffins-and-cookies.jpg" />
</main>

The main menu page's content area simply contains a list of product categories. Each item contains an image and a label that we'll mark with a <b>—no emphasis is needed, so we're going with this less nuanced inline tag. These will be wrapped by a hyperlink that points to the corresponding menu category page.

<main class="page-menu-main">
    <ul class="-categories">
        <li>
            <a href="menu-category.html"> 
                <b>Muffins &amp; Scones</b>
                <img src="images/products/muffins.png" alt="Cinnamon muffins">
            </a>
        </li>
        ...
    </ul>
    <div class="allergies">
        <p><strong>Have a food allergy or need to know what each of the ingredients are?</strong> 
           Just ask us! We keep all the ingredient listings on hand for your benefit.</p>    
    </div>
</main>

Each menu category page has a <h2> following by a few paragraphs, a list of sample products, and a hyperlink to place an order. Each sample product item has an image and a label marked with a <b>.

<main class="page-menu-category">
    <div class="intro">
       <h2>Muffins &amp; Scones</h2>
       <p>We offer a wide selection of muffins and scones in our bakery. 
          Check out all the different flavors and combinations.</p>
       <p>Don't see something you think sounds good? Let us know and we'll see if 
          we can make a custom batch just for you!</p>
    </div>
    <ul class="categories">
        <li>
            <b>Blueberry muffin</b>
            <img src="images/products/muffins/blueberry.png" />
        </li>
        ...
    </ul>
    <p class="order">
        <a href="order.html">Place an order &raquo;</a>    
    </p>
</main>

Possibly the most intricate, the order page starts with a <h2> and a few paragraphs followed by the order form. The form will be composed of a list of fields and a submit button. The each item in the list will contain a label and the necessary field widgets.

<main class="page-order">
    <div class="intro">
        <h2>Place an order</h2>
        <p>We leave our order form intentionally open so that you can feel free 
           to request both items you've seen on our menu as well as request custom orders.</p>
        <p><strong>Please allow 48 hours for us to fulfill orders.</strong></p>
    </div>
    <form class="grid-order-form">
        <ul>
            <li class="input">
                <label for="name">Name</label>
                <input type="text" id="name" name="name" />
            </li>
            <li class="input">
                <label for="email">Email address</label>
                <input type="email" id="email" name="email" />
            </li>
            <li class="input">
                <label for="phone">Phone number</label>
                <input type="tel" id="phone" name="phone" />
            </li>
            <li class="input">
                <label for="date">Date needed</label>
                <input type="date" id="date" name="date" />
            </li>
            <li class="radios">
                <span class="label">Delivery or pickup</span> 
                <label for="delivery">
                    <input type="radio" id="delivery" name="order_type" />
                    Delivery
                </label>
                <label for="pickup">
                    <input type="radio" id="pickup" name="order_type" />
                    Pickup
                </label>
            </li>
            <li class="textarea">
                <label for="details">Order details</label>
                <textarea id="details" name="details">Tell us...</textarea>
            </li>
        </ul>
        <p class="grid-item input">
            <input type="submit" name="submit_order" value="Place order &raquo;" />
        </p>
    </form>
</main>

The resulting prototype site establishes a minimal clean base upon which we can add the necessary styles to bring the design to life.

View the project to this point »

Act On It

With thorough semantic, grouping, and grid analysis complete from Phase 1 we can move on to create the actual markup for our site. As suggested earlier, we'll use the following four main components:

We'll also place an <aside> at the very end to contain our modal window, though it will be hidden by default. This will contain a <div> element that will hold the modal content. While the application could make use of the modal for other components down the road, for now the component it contains is a <form> that holds the basic task editing fields and the set of additional options. The basic editing fields will be organized into a <ul> with an <li> around each field set. Each field set will use a <label> for accessibility followed by the most appropriate input element given its data type (see Snippet 17).

<aside id="modal" class="modal">
  <div class="modal-content">
    <form class="task-editor" action="#task/save/{{id}}/{{parent.id}}">
      <ul class="basic-options task-type-{{typeClass}}">
        <li class="content">
          <label>Task details:</label>
          <textarea name="content">{{content}}</textarea>
        </li>
        <li class="date-due">
          <label>Due date:</label>
          <input name="due-date" type="text" value="{{date due-date}}" />
        </li>
        <li class="status">
          <label>Status:</label>
          {{#if complete}}
          <input type="checkbox" value="1" checked />
          {{else}}
          <input type="checkbox" value="1" />
          {{/if}}
        </li>    
      </ul>
      <div class="other-options">
        <div class="types">
          <p class="label">Type:</p>
          <ul class="options">
            <li class="task-type-norm on"><input type="radio" name="type" /> Normal</li>
            <li class="task-type-urg"><input type="radio" name="type" /> Urgent</li>
            <li class="task-type-back"><input type="radio" name="type" /> Backburner</li>
          </ul>    
        </div>
        <button class="save-task" type="submit">Save</button>
        <button class="delete-task">Delete task</button>
      </div>
    </form>
  </div>
</aside>

The result of all this markup is a functional—if understated—version of the application. With a just a little JavaScript we can also begin to simulate some functionality and we're ready to add our styles.

View the project to this point »

Folio

With analysis complete we can proceed to create the markup we planned. First we'll consider our main four components:

With some other minor variations all the pages are assembled from these components with minor variations for each different set of content. We also added a paragraph to the end of every page that provides quick links to the student and faculty starting pages for sake of the prototype.

View the project to this point »