2. Rows, Rows, Rows
The next part of our app we’re going to look at are the main rows that make up the
indexes of Spots and Stars. Once again, the HTML we’re going to use is fairly basic.
Here’s the structure for the list of Spots:
listing 7. spots.html (excerpt)
<ul id="spots-list" class="table-view table-action">
<li>
<a href="spot.html">
<h2>Planet Hollywood</h2>
<span class="relative-distance">233m away</span>
<span class="sightings">3</span>
</a>
</li>
<li class="even">
<a href="spot.html">
<h2>Myles’ House</h2>
<span class="relative-distance">506m away</span>
<span class="sightings">5</span>
</a>
</li>
</ul>
|
Some points worthy of note:
We’re using another unordered list as the base element for our list of
Spots.
This list has two classes that we’ll use to target all the lists that have the
same structure: <table-view> and <table-action>. We’re using <table-view> to refer to all such lists, and <table-action> to identify indexes that have a single direct action.
The block element (<h2>) inside our link
(<a>) is valid HTML5. In previous versions of HTML
and XHTML, block elements weren’t allowed in this context, but HTML5 has no issue with
it.
We’re identifying odd and even rows by an additional <even>
<class> on the even rows (the absence of the class
implies that the row is odd).
The additional metadata for each “Spot”—the distance from the user and the number
of sightings—are wrapped in <span> elements with
semantic classes to identify them.
To start on the style for this index, we’ll create some generic styles for all
the <table-view> elements. These will be used for the
indexes of “Spots,” “Stars,” and “Sightings”:
listing 8. stylesheets/screen.css (excerpt)
.table-view {
background: #7c0c18;
}
.table-view li {
border-top: 1px #8c2a34 solid;
border-bottom: 1px #640913 solid;
}
.table-view .even {
background: #830f1b;
}
|
At the design phase for this element, we mentioned that we need to keep performance in
mind for these elements in particular. We’re staying true to that here and keeping the
styles as simple as possible—relying on basic CSS like borders to create the illusion of
depth without heavy images. This brings us to the point shown in Figure 3; see how
the simple dark-to-light borders gives the impression that each row has a slight
bezel.
Now we can flesh out the elements inside each row:
listing 4. stylesheets/screen.css (excerpt)
.table-action li {
position: relative;
}
.table-action a {
color: #d6b69e;
display: block;
padding: 0.5em 0.785em 0.714em;
position: relative;
text-decoration: none;
text-shadow: rgba(0, 0, 0, 0.4) 0 -1px 1px;
}
.table-action h2 {
color: white;
font-size: 1.285em; /* 18px / 14px */
width: 82%;
}
.table-action .relative-distance {
font-weight: normal;
}
.table-action .sightings {
background: #6f0914;
border: 1px #841420 solid;
-webkit-border-radius: 0.143em;
-moz-border-radius: 0.143em;
border-radius: 0.143em;
color: #ebc466;
font-weight: bold;
position: absolute;
padding: 0.214em 0.429em;
right: 2.5em;
top: 50%;
margin-top: -1.1em;
}
|
This code is all stock-standard CSS, but there are some points worth noting:
Our list is really starting to take shape now, as Figure 4
shows.
This exact same code can be applied to our “Stars” list, as the underlying HTML is
almost identical:
listing 10. stars.html (excerpt)
<ul id="sightings-list" class="table-view table-action">
<li>
<a href="star.html">
<h2>Caterina Fake</h2>
<span class="sightings">5</span>
</a>
</li>
<li>
<a href="star.html">
<h2>Dan Cederholm</h2>
<span class="sightings">5</span>
</a>
</li>
</ul>
|
Without making any changes to our CSS files, the “Stars” index will now look like
Figure 5.
Writing modular and reusable CSS is as important as ever on mobile devices. The more
generic we can make our CSS, the smaller the stylesheet our users have to
download.
Tip:
Validation
Remember to validate! While even the browsers on mobile devices will do their best
to deal with malformed HTML, we can make their job (and ours) a whole lot easier by
ensuring that our HTML meets the W3C specifications. By ensuring our HTML is
well-formed, we increase our cross-platform compatibility and minimize rendering errors.
This is especially important going forward—testing against the current crop of browsers
is great, but what about the browser that’s released six months from now? A year from
now? Code that validates is the most reliable guarantee that future web platforms will
handle it as designed.
