BlogmyQuery – BMQ

When it comes to online marketing one of the most used forms is Email marketing. The purpose behind email marketing is often to get a message across, whether this be to promote an offer, serve targeted advertisements or initiate deals. Email marketing is a great way to improve your brand image as well as knowledge of your services.

Often many designers make simple mistakes when creating an email, provided here are 10 tips to create better email designs.

Plain Text Version

This is without a doubt one of the most important things to remember when designing an email, always create a TEXT version of the email. Not all email clients handle HTML too well, some may not render email messages crafted in HTML. Furthermore including a plain text version makes your email more readable on mobile devices.

Keep everything within 500-700px wide

The width of the email should be 500-700px and centered. This is just as important as the tip above, if not even more important. There is nothing worse than receiving an email where you need to scroll from side to side in order to read the whole message. Why? Simply we are creatures of habit, we don’t take the time to read every word in a text we scan it. Since our eyes tend to focus on whats straight ahead of us, the stuff on the sides will get blacked out and ignored by our brains.

Allow Easy Unsubscribing

There is no if/but/maybe about this, it is absolutely essential that your readers can unsubscribe from your email, don’t try to be smart about this by hiding the unsubscribe mail in some obscure place within the email. Unsubscribing should be a painless process that virtually anyone viewing the email should be able to figure out. Remember if the recipient doesn’t want your email they are not going to read it anyways. You might be sending 1,000 emails, but if only 50 are being read then your system is not very effective.

Plan for no images

While you might have just downloaded the perfect image from Shutterstock, please remember that many email clients block images in messages unless the user decides to see them, pretty much that means that often your beautiful images will never get seen. Another problem is if your message is embedded in an image, then the same rule applies most readers will never see your message because your images are blocked.

Test it on-the-go

Just like you would test a website before launching it you should really test an email before sending it out to your final audience, remember that not only should you test these on the most popular clients such as Yahoo, Gmail, Outlook and others but also test to see how it looks on a smartphone or mobile device, If you don’t own a device then grab a friend who has one ask them if you can test your mail on their device!

View in Browser

There should be no reason why you would not allow people to view your email as a Web page. Face it, there are just some people who prefer to look at things in a browser, furthermore not all email clients render HTML as you expected and therefore making it possible for your readers to view your mail in a browser makes everyone happy.

Relevant Subject line

I cannot even begin to state the importance of this, if your subject line screams “I am spam from spam company don’t bother reading” well then guess what your reader isn’t going to read it, furthermore if your subject line is “READ ME I AM FULL OF BS” all in capital letters then they will also move on, or how about the “Make $1,000 in a jiffy!!!!!!!!!!” if nothing else then all the exclamation marks will deter anyone from reading this email, and besides spam filters will most likely mean your readers will never even see these emails.

Call To Action

So you have the best/newest/fastest something and you want to add a CTA, or Call To Action in your email, then make sure it is clear exactly what this action is, if you want your reader to do something then don’t just add a ‘click here’ button instead add something like “click here to…” tell them what will happen when they click here.

Don’t use video

Yes over the past few years there seems to be a video for everything, with sites such as YouTube getting more and more popular there should be no reason why you would include an actual video in your email. If your reader is using a slow internet connection then it will take them forever to load your email. Furthermore more and more email clients are filtering out emails with large file sizes, in other words if you add a video you run the risk of ending up in the Spam folder.

Make it clear who’s sending the message

Lets face it, if you don’t know the sender of an email you are more likely to just hit the delete button. Just like in real life people are suspicious of strangers and the same goes for email. In other words make sure your sender ID states exactly who you are, furthermore make sure your logo is visible at the top of your email.

The post 10 Tips to Remember When Designing For Email appeared first on Design Reviver.

Remember those vintage types you came across the other day? And the day before? That’s trending at the moment in what looks like the revival of a retro-20s-60s style in graphic design. Some might even say it goes up to the 80s. How time passes… Take the vintage letterpress, one of the most popular types in the vintage collection. It has conquered both the print and the web design.

What? How do you know it’s vintage? The same way you know a dress is from your mother’s closet because it smells of lavender and it looks like a hit of the 60s party scene.

This is an interesting and somehow counter-intuitive trend to observe in a world where the demand of VCP-510 professionals, cloud computing and 640-802 study guides are on the rise, but a fascinating phenomenon nevertheless.

Strong, yet sensitive. Rugged, yet refined. Reminiscent of western print and advertisement, book covers and posters, recreating the flavor of the 20s, 40s up until the cheerful typography style of the 50s and the 60s. It looks old, but it feels fresh. Its nostalgic feel can stir feelings and awake memories and has the undeniable potential to appeal to a wider audience. Even some of the names have the whiff of the good old days: Victoriana, Avant Garde, Coffee Tin, Ecolier…

With globalization in fullswing though, it’s very hard to geographically delineate the popularity of the vintage style in graphic design, but it does tend to be a common presence in western cultures. To see what we’re talking about, but mainly just to feast your eyes, you should check the NYC Type project, a collection of types and typefaces found in New York City. Try to spot the vintage ones. You’ll see how the vintage style feels quite at home here. Wonder why…

title image copyright of screenrant

The post Vintage Is the New Modern appeared first on Design Reviver.

The buzzword “CSS4� came out of nowhere, just as we were getting used to the fact that CSS3 is here and will stick around for some time. Browser vendors are working hard to implement the latest features, and front-end developers are creating more and more tools to be able to work with the style sheets more effectively. But now, on hearing about CSS4, you might ask, “Hey, what about CSS3? Is it over already?�

We’ve been working hard to spread the goodness of CSS3, and now it’s obsolete? In fact, nothing’s wrong. It’s just natural evolution — a process that will help CSS as a whole — because “Level 3â€� and “Level 4â€� just follow the naming convention of the various documents of the specification.

Why Level 4? What About CSS3?

“Level 4� is just the number of the W3C document. Have you heard about the new “Filter Effects, Level 1� specification? Where should it go? To CSS3? CSS4? Hey, maybe CSS1 because it’s Level 1? Doesn’t matter, because CSS is just CSS. Selectors are the first document to reach the fourth level of the specification, and it’s still a draft, a work in progress. Each document is on its own when it comes to the specification number; the documents are developed independently of each other.

This is a big advantage, because finished parts of the document can be closed and set as recommendations — like Selectors Level 3. Finishing a document quickly and moving problematic parts to the next level helps to push the Web forward because it implements the specification one chunk at a time.

The buzzword “CSS3� will share the same fate as “HTML5�: we’re not talking about a specification number, but about the language as a whole. HTML5 is basically just the next version of the markup language, which adds support for new elements. But when you talk about it, you can bring up anything you want, from the audio API to Web sockets to geolocation (which isn’t even in the HTML5 specification).

The same goes for CSS3: it’s the shiny bit of magic that we do with CSS when building cutting-edge demos. You don’t have to know what part of the specification border-radius or box-shadow belongs to, as long as you know how to properly use it. Same goes for selectors; they’re just another version of the “Selectorsâ€� specification.

What Are Selectors?

The specification explains selectors as patterns that match against elements in a tree. Most of the selectors from the Level 4 specification are pseudo-classes. Selectors have been with us since the beginning of CSS, but now they are at the fourth level and have gotten a lot of cool new additions. Let’s jump into the action and see what’s interesting. I won’t describe the entire document — only the new additions in Level 4.

Logical Combinators: :matches, :not

Let’s start with logical pseudo-classes. The first, :matches, some of you might already know from Mozilla’s :-moz-any(), which was implemented a long time ago in Firefox 4. Thanks to this selector, we can group and match items in our CSS document. Why is it so useful? Well, the most basic use I can think of is to gather multiple definitions of anchor states into one. So, instead of this…

ul.menu li a:link,
ul.menu li a:hover,
ul.menu li a:visited,
ul.menu li a:focus {
   color: red;
}

… we can just do this:

ul.menu li a:matches(:link, :hover, :visited, :focus) {
   color: red;
}

Simple, right? Although this example might look silly, it shows the power of the :matches pseudo-class, and it can be used in more complicated situations:

article:matches(.active, .visible, p#important) {
   background: red;
}

The second logical combinator we’ll look at was introduced in the CSS3 specification, but it became even more powerful in Level 4. I’m talking about :not, the simple negation pseudo-class, which now can take a list of selectors as parameters:

p:not(.active, .visible) {
   color: red;
}

The code above will apply red to all paragraphs to which the active or visible class are not assigned in the markup.

Location Pseudo-Classes: :any-link, :local-link

Thanks to the location pseudo-classes, we will have more control over the styling of links. First, :any-link (a temporary name that could change) gathers definitions of a:link and a:visited into one, so you don’t have to write them both:

a:link,
a:visited {
   color: red;
}

Now, it won’t matter whether a link has been visited or not. It will be styled the same either way:

a:any-link {
   color: red;
}

Our second pseudo-class, :local-link, is way more interesting. You could, for example, give a different style to the links that target your home page, leaving all others untouched:

nav :local-link {
   text-decoration: none;
}

Thanks to this line of CSS, links pointing to the current page will not have the text-decoration style, so they’ll look different than the others in the menu or breadcrumb.

Let’s see another example:

:not(:local-link(0)) {
   color: red;
}

This style will apply red to all external links. (You could add, say, an icon or background image to them if you’d like.)

As you can see in this last example, :local-link can be used with a parameter. The number in the parentheses determines the level of the URL path that will be checked and matched against every given link. Sounds a little complicated, but an example should clarify:

nav :local-link(0) {
   color: red;
}
nav :local-link(1) {
   color: green;
}
nav :local-link(2) {
   color: blue;
}
nav :local-link(3) {
   color: yellow;
}
nav :local-link(4) {
   color: gray;
}

Suppose the current address is http://end3r.com/2012/10/20/some-title/, and you have these links in the breadcrumb:

1. Home
   http://end3r.com/
2. 2012
   http://end3r.com/2012/
3. October 2012
   http://end3r.com/2012/10/
4. 20 October 2012
   http://end3r.com/2012/10/20/
5. Article
   http://end3r.com/2012/10/20/some-title/

The first link will be red, the second green, the third blue, then yellow, then gray.

Time-Dimensional Pseudo-Classes: :past, :current, :future

This pseudo-classes is very handy for users of screen readers. With only one line of CSS, the word being spoken can be given a different style (think karaoke-style):

p:current {
   background: yellow;
}

This will highlight the word being spoken in yellow.

The second use case is styling subtitles for the WebVTT video format, changing their color and other properties. The :past and :future pseudo-classes refer, respectively, to elements that have been selected and ones that will be selected.

UI State Pseudo-Class: :indeterminate

While the UI elements of online forms can be given many interesting pseudo-classes, such as :enabled, :disabled or :checked, one is quite new: :indeterminate. As you may know, checkboxes and radio buttons have two states, either checked or unchecked. Either state can be enabled using the :checked pseudo-class (and :not(:checked) for unchecked). But what if you want to style inputs that haven’t been used? They’re neither checked nor unchecked, so their state is indeterminate. Easy, right? We can give nice styles to these inputs that haven’t been used yet or for which a default state hasn’t been set:

input.checkbox:indeterminate {
   background: #ccc;
}

Similarly, a progress bar could be given an indeterminate state when its percentage of completion is unknown:

progress:indeterminate {
   background: #ccc;
}

In this situation, we can target the default state and style it to indicate to the user that the time left to load a resource can’t be determined.

Tree-Structural Pseudo-Classes: :nth-match, :nth-last-match

Tree-structural pseudo-classes are also new and interesting in the Selectors Level 4 specification. With the help of :nth-match, you can now achieve more than ever. Curious how it works? Well, if you take the :nth-child pseudo-class, which selects an item, and combine it with the power of :matches, you’ve got the answer.

Suppose you have a list of links, some of which have the class active, and you want to select only the even-numbered items from the active links. We could use :nth-child(even) to select all of the even-numbered children in the list, but that’s not what we want, because then we wouldn’t be accounting for the active class. Nor is :matches(.active) sufficient, because then we’d be targeting all elements with the class active. This is where :nth-match comes in:

li a:nth-match(even of .active) {
   color: red;
}

Thanks to this one line, we can finally select only the even-numbered items from among those that have the active class.

This is just a simple example. We can achieve a lot more using the complex syntax An+B, like so:

p:nth-match(2n+1 of .active, .visible, #important) {
   color: red;
}

This combination of selectors we want to match here is more complicated. The :nth-last-match works exactly the same as :nth-match but starts matching from the end of the DOM structure.

Grid-Structural Pseudo-Classes: :column, :nth-column, :nth-last-column

Let’s apply some pseudo-classes to tabular data. We all know that tables are bad for layouts but good for data that warrants it. An HTML table is row-oriented (<tr>), so columns are missing out. Creating a column-based table is possible, but then you’d be missing rows because you can’t have both at the same time, and row-based tables are more popular. Being able to use CSS to style the columns in a table that is row-based and created in the DOM would be useful when you want to, say, alternate background colors. Of course, we could use additional classes or markup; but with a little help from Selectors Level 4, we can do it with grid-structural pseudo-classes.

:column(.total) {
   background: red;
}

:nth-column(even) {
   background: blue;
}

This will set red as the background color of every cell in the .total column, and blue for every even-numbered column in the table.

Now we can select columns just like rows, and even get crazy with something like :nth-column(3n+2). Just remember that columns are styled based on their order in the DOM structure, not how they are displayed on the page. Of course, a table isn’t the only thing that benefits from grid-structural pseudo-classes: column-based layouts are on the way.

Parent Selector!

This is the long-awaited Swiss Army knife, the holy grail of CSS. It is the most discussed aspect of the Selectors Level 4 specification, and it gives you a lot more power with CSS. Thanks to the parent selector (also referred to as the subject of the selector), you can easily style elements other than the default last ones in a selectors list. This can be super-useful when styling generated menus, and you avoid having to add classes for styling purposes only.

Let’s see it in action with the most basic example. Suppose we have a menu, a simple list of links. We want to be able to style it, but the PHP on the server is generating the menu, so we can’t change it. The problem arises when we want to style the li element based on the active class added to the anchor; we can style a using a.active {}, but we can’t get to the li element. The easiest thing to do would be to add the active class to the list element, not to the link itself — like so: ul li.active a — so that we can style both the list and the anchor if needed. The problem is that the menu is generated by a script over which we don’t have control, so we end up with ul li a.active.

In the normal structure of a CSS document, we always refer to the last item in the selectors list. In ul li a.active, that would be the link with the active class; in article p span, it would be the span; and so on. Thanks to the parent selector, we can change the subject of the used selector. This gives us incredible power and flexibility when styling:

ul li! a.active {
   color: red;
}

Now we can style the li element according to whether the active class has been added to the link. When we add the parent selector, we are saying that we want to style the li element instead of a.active.

We can also manipulate the background color of the whole page just by adding a simple link somewhere in the document:

body! header a.styleSwitcher:hover {
   background: red;
}

This applies a red background to the body of the document whenever the user hovers over an anchor with the styleSwitcher class. To do this without the parent selector, you’d have to add custom classes in JavaScript. It’s not impossible, but the native one line in the CSS is definitely the best solution for this.

Note: The first draft of the specification document (dated 29 September 2011) targets the parent selector with a dollar sign before the given selector ($li). The latest draft (22 June 2012) uses new syntax in which the subject of the selector is indicated by an exclamation mark after the given selector (li!). Of course, this could change (it’s just a draft), so don’t forget about it. What matters is that the parent selector will be implemented sooner or later, and the exact syntax is just a matter of preference. It doesn’t matter to me what it looks like, as long as it works properly in the browser.

To see the parent selector in action, check out the cssParentSelector jQuery plugin.

Summary

As you can see, the new additions to the Selectors specification look very interesting. I can’t wait to use them in my projects. The only problem is that we will have to wait for them to be implemented in browsers — although you can test some in the browser with the help of a JavaScript library.

State of the Document

Level 4 of the Selectors document is not yet an official recommendation — just an evolving draft (as demonstrated by the parent selector, which has changed a couple of times and is still in flux). You can’t rely on the document because it will certainly change in future. But there’s an advantage to this: you can take part in the discussion and suggest ideas. Everyone with an interesting point of view can add something that will eventually be made part of the official specification.

Implementation and Browser Support

Some think it’s hard to implement something that’s still a work in progress. Yes, that’s partially true; browser vendors start to think about implementation only when the documentation has gone from messy to solid. But even though we can’t use the goodness of Selectors Level 4 today, we can use something like Sel, one of a few engines that have already implemented some of the features. Thanks to shims and polyfills, we can start experimenting with features that will be available in our favorite browsers in the coming months and even years.

Other Level 4 Specifications

There are already other Level 4 documents:

• CSS4 Media Queries
• CSS4 Background
• CSS4 Images
• CSS4 Text

All of them are still in development, so we will have to wait a bit for the next official W3C Working Draft. Of course, you can get involved right away and influence the decisions that will be made.

Resources

The first and most interesting place to visit, of course, is the official W3C documentation for Selectors Level 4. Just remember that it’s still in development. You can also check out a couple of interesting articles in the wild, like the one by David Storey, a W3C Working Group member.

Shape the Future

Help with the document, suggest ideas, comment on other people’s ideas — now is the best time to be a part of the future. Who knows? Maybe in a few years from now, you’ll be in the Working Group and will be responsible for an awesome breakthrough CSS feature that will be used by millions of Web developers every day? It’s an incredible opportunity: to be at the bleeding edge of a standard or, better still, to take part in the creative process as one of the main contributors!

(al)

© Andrzej Mazur for Smashing Magazine, 2013.

The popularity of mobile has skyrocketed over the past few years. We’ve seen six generations of iPhones, five iPad models, hundreds of Android phones and thousands of different devices being manufactured. Design and development have gone all the way from static and desktop-centric to responsive and device-aware. And it has been a very exciting journey.

The field is relatively young — we are all learning (usually by mistakes). Because of that, we are also struggling with generalizations and even stereotypes. Let’s have a look at common myths associated with the mobile universe.

Myth: Mobile Is Well-Defined

It has become widely accepted that “mobility” refers to handheld devices, which you can easily use on the go, for Web browsing or anything else. Following that thought, we could easily make an assumption that even a remote control or MP3 player could potentially be a mobile device. But are they?

Barbara Ballard, author of Designing the Mobile User Experience, does a great job explaining the idea behind mobile:

“Fundamentally, ‘mobile’ refers to the user, and not the device or the application.”

Mobility is strictly connected to the user and situation they’re currently in, not to the piece of hardware they’re using. This easily leads us to the conclusion that what really matters is the context, not the device. Some mobile industry luminaries have stated that the idea of context has been overblown. Indeed, it can easily lead to many unfortunate decisions and false assumptions which can drastically affect the end product.

As Jeremy Keith, author of HTML5 for Web Designers and mobile specialist, has said:

“We have once again created a consensual hallucination. Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.”

By defining mobile as a set of circumstances, a setting, we are in danger of making some sweeping generalizations. We analyze, we study reports and use cases, but mobile interactions are far less trivial than we think.

As studies show (PDF), over 70% of Americans use their phones while in the bathroom. In some countries, the percentage of people with Internet access that is solely provided by mobile exceeds 50%. According to ComScore’s Mobile Metrix, Facebook’s mobile app accounts for 80% of their traffic. These facts prove that assuming short attention spans and oversimplifying interfaces are not solutions to addressing the problem space.

People tend to use their phones or tablets at home while sitting on the sofa or in a cafe. What’s even more important is that they’re willing to perform complicated tasks and actually spend money. Rather than guessing what the user is trying to achieve on a mobile device, we should assume they want to do everything and try to better understand the constraints of each device. We should be concerned about the content that we’re trying to serve while bearing in mind the context is continuously changing.

As developers, we need to ditch our desktop-centric thinking which taught us to prototype for a certain set of conditions, and aim towards more flexible content. Instead of focusing on a single platform, we should create reusable copy and assets, which will serve as a base for multiple scenarios.

Myth: Mobile Is iOS

We have already established that we cannot take network speed, screen dimensions, operating system or browser for granted. The mobile market is hugely diversified. Yet it’s still sometimes identified with iOS devices only.

Apple products are high profile. Their brand is hyper-consistent and instantly recognizable. But iOS represents less than half of the mobile market. And favoring iOS (or any one platform in general) might lead to poor user impressions.

Within the US, Google owns roughly 53% of the smartphone market. That basically amounts to a huge number of wildly different Android devices.

Let’s have a look at market share:

Both Android and iOS are growing while other platforms are slowly loosing more and more users.

These numbers mean that we have thousands of resolutions ranging from the first phone with Internet access, Nokia Communicator (640 × 200 pixels), up to Samsung Galaxy S3 (1280 × 720 pixels). While some of the models are discontinued, it still gives us a greater picture of the market’s diversity.

When talking about screen size, it would be a crime not to mention pixel density. The real boom with higher-density screens started when Apple introduced retina display along with iPhone 4. But what does it mean for us? It’s one more factor we need to take into account. Because we are dealing with more pixels per inch than usual, we need to supply higher resolution graphics or else rely on SVG, which isn’t always a solution we can use.

We not only need to consider the diversity of original equipment manufacturers (OEMs), operating systems and screens but also the multitude of browsers. Some of the most well known and widely used are:

• Opera Mobile,
• Opera Mini,
• Safari,
• Chrome,
• Dolphin,
• Internet Explorer Mobile,
• Blackberry,
• WebOS browser.

Some of these are default browsers, provided by vendors, and some are user-installable. This is only a small fraction of available browsers, though. Taking this even further, all of the aforementioned browsers have a rendering engine, and while they are usually built upon WebKit, the distributions vary which introduces us, developers, to a whole new range of cross-browser issues.

That leaves us with a few factors to consider: type of device, such as smartphone, tablet, personal digital assistant (PDA), etc.; resolution; orientation; pixel density; and the browser with its rendering engine. All these limitations define how the implementation process will look. It would be a crime to assume device uniformity.

Myth: Mobile Means Less

Imagine you’re reading the delivery menu for your favorite American restaurant, and you want to order a steak. To your utter shock and dismay, you find that it’s not on the menu. You’ve had steak before when visiting the restaurant in person, so you wonder why you’re not seeing it on the delivery menu.

Someone in charge decided that Americans have poor eating habits, and if they are not willing to come to the restaurant in person for the full experience, then they are likely to be sitting at home on a couch in front of the television, and are not fit to have the meal. You enter into absolute food rage and never return to the restaurant again.

When you think about this situation, you should quickly notice that it’s not that different from daily decisions developers and designers make.

Having too many features may be just as harmful as cutting them down, as you can see when viewing The New York Times website on mobile.

You decide what set of features and interactions are necessary for a perfect user experience. It’s especially important on mobile, when you try to cut features to make the interaction as easy and seamless as possible, basically making assumptions and decisions for your users. Nothing is more frustrating than being deprived of the ability to make your own choices.

It’s critical to put the users’ needs first. If mobile gets less features by default, customers can potentially be left without the means to engage with your actual product. People perform all kinds of actions while using a wide range of devices. 25% of mobile users engage in online shopping through their phones and tablets. Would you ever think that every three minutes (within the UK) a vehicle is purchased using the eBay mobile app (PDF)? Tiffany & Co. also noted a significant rise in sales and traffic after launching their mobile app — would you think that people buy diamonds on mobile?

The main focus should go to delivering great experiences within the feature set you’re offering on desktop, not limiting them. While some features appear as unnecessary, you cannot assume that they aren’t without proper testing and real interaction. As Aral Balkan points out:

“If you’re not involved in building what you’re designing, you’re not designing, you’re assuming; you’re drawing pretty pictures.”

Myth: Mobile-Specific Content Is Mandatory

Stephen Hay once tweeted:

“There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.”

Mobile isn’t an independent creature — it’s an experience we’re creating. We could not possibly accommodate all devices that are currently available. The ideal situation would be to have one, uniform experience of the brand, served according to device.

It all comes down to the most crucial part of Web design — content. Being perfectly aware of goals that you’re trying to achieve and leveraging content strategy is essential for creating cross-universe compatible experiences. While we try to tailor, cut and paste content that we think is essential on mobile, again we are trapping ourselves in false assumptions of users’ context (by choosing what’s the most appropriate piece of information they are potentially looking for) and finally ending up making mobile less compelling and bereft of features.

That’s why we should consider designing content out rather than canvas in. Being focused on content from the very beginning will help keep you from being trapped within visual limitations that come with the wide variety of available devices, and make the copy usable regardless of the platform it is being served on.

Myth: Mobile Means Apps

There are few approaches for serving optimized content for mobile. Having an app is one of them — not necessarily the best, though. An app is just a container for the content we are trying to serve. While some apps bring us delightful experiences (such as Solar or Instagram), we can’t rush ourselves and create an app for every website or product we are working on. Especially if we are planning to give the app a subset of desktop features.

“See, your product isn’t really a product at all. Your product is something called content. It’s a service.”

An app is considered a product by many. As Josh Clark outlines above, the essence of the product is and always will be the content and service or set of functionalities you are giving to your customers. Currently, both App Store and Google Play are each offering over 700,000 apps for download. Are all of them being used? Probably not. Are they all providing the content or features the user would like to see? For sure, no.

Responsive design has been adopted by well known brands such as Tiffany & Co.

Since having an app isn’t always the way to go — what is? A good alternative is responsive design. It has been a really hyped topic over the past few months, and not without reason. It certainly can be easier to use media queries than to write a native iOS app or play around with PhoneGap. It also gives the impression of cohesion and creates a seamless experience. Development-wise, it prevents you from creating a couple different apps (for different platforms) and code bases.

Instead of creating an app to make the “New & Noteworthy” section within the App Store, and therefore limiting yourself to the container you’ve chosen, try to think about a strategy which will reduce the amount of redundancy in your work and that will serve all users. Before jumping on the bandwagon of apps, be sure that you have good content strategy thought out.

Conclusion

These are exciting yet overwhelming times for Web development. We are forced to rethink the purpose of websites or apps we are creating. We have no ability to predict what will happen next, what constraints and abilities the next devices will bring. What is important these days are back-end systems which provide all the data we are trying to display — it’s not only presentation layer we need to care about, which still somehow remains the most important factor. We are observing robust growth and increasing interest in APIs, which along with content are drivers of layout change.

It all comes down to both knowing the needs of your audience and revolving around content. We tend to acknowledge the constraints of platforms and design strictly for given requirements. Let’s make sure that the data is accessible anywhere, anytime, on any device.

Further Reading

• Designing the Mobile User Experience by Barbara Ballard
  The basics of mobile design.
• Content Strategy for Mobile by Karen McGrane
  A guide on how to prepare cross-platform content.
• Mobile First by Luke Wroblewski
  A comprehensive guide for mobile development strategies.
• On Mobile Context by Jason Grigsby
  Thoughts on mobile context and useful resources on this topic.
• Building Mobile-Optimized Websites, Google Developers
  Tips on developing for mobile.
• This Is Responsive by Brad Frost
  An open source collection of responsive patterns and modules.

(cp)

© Karolina Szczur for Smashing Magazine, 2013.

Whatever you call them — blocks, boxes, areas, regions — we’ve been dividing our Web pages into visible sections for well over a decade. The problem is, we’ve never had the right tools to do so. While our interfaces look all the world like grids, the underlying structure has been cobbled together from numbered headings and unsemantic helper elements; an unbridled stream of content at odds with its own box-like appearance.

Because we can make our <div>s look but not behave like sections, the experience for assistive technology (AT) users and data-mining software is quite different from the experience enjoyed by those gifted with sight.

Now that HTML5 has finally made sectioning elements available, many of us greet them with great reluctance. Why? Partly, because we’re a community which is deceptively resistant to change, but also because of some perceived discrepancies regarding advice in the specification. In truth, the advice is sound and the algorithm for sectioning is actually easier to use than previous implementations. Some dev’s are just very married to their old workflow, and they think you should be too. There’s no good reason why.

Make no mistake: Sectioning elements help you improve document structure, and they’re in the spec’ to stay. Once and for all, I will be exploring the problems these elements solve, the opportunities they offer and their important but misunderstood contribution to the semantic Web. If you’re unfamiliar with the concept of the “semantic Web,â€� this video is a great introduction.

Making Websites

My introduction to Web design was via a university course module called something like “2.1: Dreamweaver,� and I recall my first website well. I remember my deliberately garish choice of Web-safe colors. I remember it looking right only in Netscape Navigator. Most of all, I remember hours of frustration from tugging at the perimeter of a visual layout tool named “table.� I had no idea at the time that this layout tool represented a type of annotation called an HTML tag. Furthermore, no one told me that this annotation invited my patchwork of primary colors and compressed JPEGs to be computed as a sort of demented Excel spreadsheet. In other words, I had no idea I was doing it wrong.

*Bites tongue*

The fundamental failure of most graphic, product, architectural, and even urban design is its insistence on serving the God of Looking-Good rather than the God of Being-Good.

Macromedia’s Dreamweaver didn’t make the creation of valid documents impossible, but it was one of a number of emerging GUI editors that pandered to our desire for visual expression more than it encouraged informational clarity. Dreamweaver, and other editors classified under the misnomer “WYSIWYG,� helped transform a standardized information system into a home for graphic design and enabled a legion of insufferable Nathan Barleys to flypost the World Wide Web with their vapid eye candy. I was one of many.

Web Standards

By the time I made my first website, the Web standards movement, promoting compliance, uniformity and inclusion, was burgeoning. I just wasn’t aware of it until much later. I didn’t have to be: Agency-based Web design was still mainly graphic design with a reluctant programming department clumsily bolted on. If you’re doubtful of the grip that this culture has had on the World Wide Web, look no further than the fact it took until 2010 (2010!) for us to concede that Web browsers are not really made of paper.

When I finally became familiar with Web standards and the practice of “doing things right,â€� it was as someone who still worked primarily as a visual designer. Inevitably, my first forays into standards-based design revolved around mastering “CSS layout,â€� the practice of visually arranging content without relying on the semantically incorrect <table> element. We’ve held up <div>-based layout as a mark of quality for a number of years now. You might even say that it has become a time-honored rite of passage for graphic designers who are moving into “properâ€� HTML coding.

As I shall demonstrate, the <div> is the ultimate Graphic Design tool. By affecting only appearance, it licenses poor document structure and overengineered interfaces; all without making your document technically invalid. As such, it sanctions the worst kind of hacks.

The Problem With <div>

Every day, thousands of Web developers invoke the almighty <div> to divide, partition and ring-fence their Web pages’ content. We use the <div> to police content, to prevent disparate chunks of information from collapsing into each other. In truth, the <div> has no such power.

Consider the following example:

In this basic layout, I have included a body of text and an adjacent “sidebar.â€� To make it absolutely clear to the reader that the sidebar is tangential and does not belong to the main content, I’ve drawn a fat line around it using the border property. For those of you screaming, “That sidebar heading should be an <h3>!â€�, I’ll get to that shortly. All of my design decisions (the adjacent position, the border and the reduced font size) are facilitated by CSS alone. So, when I take the CSS away, I get this:

Not only is switching off CSS the quickest way to make a Web page responsive, but it’s a great way to see how HTML4 documents (which lack sectioning elements) are actually computed. In this case, our so-called “sidebar� is revealed to be just another raft of information in the linear flow of the document.

Why Is This So?

The reason for this is that the <div> is, and always has been, a flow content element. No matter how thick the <div>’s borders or how dark its background color, it does not stand apart in the structure of the document. Neither, therefore, does its content. With the CSS removed, the faux sidebar’s heading of “Resourcesâ€� now seems less a distinct component of the page and more a part of the main content. To a parser or screen reader, it would have seemed this way all along.

For reasons of clarity, let’s look at a further example using a snippet of HTML:

 
	<div class="parent">
	<h2>Heading</h2>
	<p>Some content...</p>
		<div class="child">
			<h2>Another heading</h2>
			<p>Some other content...</p>
		</div>
	</div> 

I’ve done something slightly different here by entering the two <div>s into a parent-child relationship: The div.child tag belongs to div.parent. We can certainly make it look that way with CSS, anyway. However, <div>s, to quote the specification, “have no special meaning.â€� Not only do they not mean anything semantically, but they have no impact on the computable structure of the page (sometimes called the “document outlineâ€�). The <div>s we’ve used may as well be invisible; so, to get a meaningful map of the structure we’ve created, we should remove them completely. That leaves just four elements and reveals the parent-child relationship to be an illusion:

 
	<h2>Heading</h2>
	<p>Some content...</p>
	<h2>Another heading</h2>
	<p>Some other content...</p> 

As HTML coders interested in sound structure, we should be interested that the above reduction — which omits all meaningless elements — is what we’ve actually made, and it’s not what we set out to do: By not really belonging to “parent,â€� “childâ€� has a different contextual status in the document than intended.

Heading Levels Don’t Really Help

It’s popular to believe that replacing the second <h2> with an <h3> would solve our problem. If we did so, we’d get the following, more dynamic outline:

• A Heading (h2)
  • Another Heading (h3)

This solution certainly seems more purposeful, but is it the right decision? Should the second heading be a subheading within the same topic (an <h3>) or be the introduction of an entirely new topic (an <h2>, as we had in the first place)? Headings alone can only show where a piece of content starts, not where it ends, which makes it difficult to tell what belongs to what. We have to simulate belonging by choosing the correct heading level for the context. Just think about that for a second: We’re defining the content’s structural status by labeling it retroactively. It’s just begging to go wrong.

Lets have a look at the homepage of accessibility experts The Paciello Group. Naturally, it’s a highly accessible and pretty well organized site, but could the structure be improved with HTML5 sections? You’ll notice their use of a <div> to collectively wrap the three <h2>s, Software Developers, Website Owners and Mike Paciello. Since the <div> doesn’t computably contain these three blocks, the last <h2> and the following <h3> are allowed to pair off in this relationship:

• Mike Paciello (h2)
  • Contact Us Now (h3)

Wait … so, “Contact Us Nowâ€� is a subtopic belonging to the larger theme of “Mike Pacielloâ€�. Can that be right? It certainly doesn’t look this way in the visual layout. It’s worth noting at this point that the <div> which fails to thematically group those three <h2> blocks has a class of class="region". Ironically, if this <div> had been a <section>, some screen readers would consider it a “region”. If a <section> had been used in place of the <div>, the observed relationship would not have emerged: The “region” would be self-contained. The class of “region”, however, is not taken into consideration in any meaningful way and does not affect the structure.

Okay, so that’s a weird one, but the situation only gets more confusing when we start to include items for which headings aren’t really even appropriate. Take this further example:

In my HTML4 page, I have an <h1> to introduce the document, an <h2> for the main content and an <h3> to mark the start of my “sidebarâ€� (which is just a wishy-washy <div>, as in previous examples). The page follows long-standing convention by having an untitled div#footer resting at the foot of the document for copyright information and other such necessary evils. (It has to be a <div> in HTML4, because the <footer> tag doesn’t exist yet.) The question is, to which heading does the footer belong?

Whose Footer Is This?

Most of us, based on appearances, would agree that the footer must belong to the document. That is what we’ve learned to expect. To the unsighted, it is a different story: Because there is no new introductory heading between the sidebar <h3> and the footer content, it could be extrapolated that these two components are as one (see image below left). By the same token, one could also argue that we’ve included the “sidebarâ€� as a mere “breakâ€� from the flow of the main content, before returning to that flow at the advent of the footer (see image below right). This would make the <h2> the footer’s heading.

The only decent chance we have of understanding the intended structure of the page is by inferring it from a reading of the content. Remembering that the whole point of a “markup language� is to make the structure of information easier to follow, I may as well have chucked the HTML and written my Web page on the back of a napkin.

Some accessibility gurus would suggest that you use a remedial <h2> to head the #footer and bring it back in line, marking up the end of the sidebar like so:

• h1 (page)
  • h2 (main)
    • h3 (sidebar)
  • h2 (footer)

This kind of works as a hack, but it’s not really sound. Do you really want to make a big announcement of the footer — an announcement as big and bold as the one used to summon the main content, not to mention bolder than the sidebar? No. If our Web page were a film, the footer wouldn’t be the titles — it would be the credits. In HTML5, the <footer> element “contains information about its section.â€� This is semantically superior: We don’t use footers to introduce topics; we use them to conclude them. Accordingly, footers — unlike their parent sections in HTML5 — do not require headings.

Just because the nesting level of headings is correct doesn’t necessarily make a page easy to read.

The closest thing we have to a “systemâ€� for structuring documents properly in HTML4 is numbered headings. Not only does this lead to ambiguity, as explained, but in practice we don’t really even use headings to define structure. We use <div>s to define structure and throw in some apologetic headings for accessibility’s sake. To make matters even worse, advice regarding the deployment of numbered headings isn’t even clear on whether we should use them in order (h1-h6) or not.

The loose coupling between headings and <div>s is inadequate. Now, with the introduction of sectioning elements, we still use boxes, of sorts, but boxes that actually say something on their own. We are making a move from merely implying sections (by labeling them) to letting them define themselves. Simultaneously, sighted readers and unsighted parsers can experience content that one has effortlessly divided into clear, manageable portions.

The HTML4 spec is very imprecise on what is a section and how its scope is defined. Automatic generation of outlines is important, especially for assistive technology, that are likely to adapt the way they present information to the users according to the structure of the document. HTML5 removes the need for <div> elements from the outlining algorithm by introducing a new element, <section>, the HTML Section Element.

Sectioning

Aware of our desire for legitimate elements to create computable sections, HTML5 offers <section>, <article>, <aside> and <nav>. Like some sort of obnoxious holiday rep’, I’ll introduce the topic of practical sectioning using these elements with a quick quiz. Study the following diagram. How many sections do you count?

Multiple-choice answers:

1. 1
2. 2
3. 3
4. 4

The correct answer is (a), 2. We have included just one of HTML5’s new sectioning elements in the form of an <aside>. Because <footer>s and <header>s are not sectioning elements, what does that leave us with? The <body> tag is the outermost element, making the document itself a kind of section (a supersection, to be precise). So, there you have it: We’ve been using “sectioningâ€� since HTML 1.0, just not with any subsections to speak of.

Some of you may have missed the clue earlier in this article and thought that <header> and <footer> were sectioning elements. Don’t fret; it’s not your fault. Whenever developers like myself try to explain HTML5 page structure, they usually brandish a diagram like the one I used above. In these diagrams, the boxes marked “header,â€� “asideâ€� and “footerâ€� exist in the same visual paradigm and occupy a similar area. They seem alike, you might say. The other culprit for this endemic confusion is the way the specification is written. Believe it or not, the document structure of some pages in the specification that refer to document structure is structurally unclear! This sort of thing sometimes happens when a standard is constantly evolving. The navigation tree for “4.4 Sectionsâ€� found in this draft is laid out like so:

• 4.4 Sections
  • 4.4.1 body
  • 4.4.2 nav
  • 4.4.3 article
  • 4.4.4 aside
  • 4.4.5 h1, h2, h3, h4, h5 and h6
  • 4.4.6 hgroup
  • 4.4.7 header
  • 4.4.8 footer
  • 4.4.9 address

You’d be forgiven for thinking that anything in this list qualifies as a sectioning element, absurd as some of them (<address>?) may sound. It’s only when you navigate to 4.4 Sections > 4.4.8 Footer that you’re told that “the footer element is not sectioning content; it doesn’t introduce a new section.â€� Thanks!

Despite these ambiguities in the spec’ itself, as well as in the surrounding publicity for HTML5, sectioning in practice just works. The following three axioms are probably all you’ll need to understand the algorithm:

1. <body> is the first section;
2. <article>, <section>, <nav> and <aside> make subsections;
3. Subsections may contain more sections (subsections)

Aside from a few trifling details, that’s it. In a little while I’ll cover the completely unnecessary worry that is had over headings combined with sections. For now, let’s take another look at that example from before about footer ownership. This time, I’ll make a few HTML5 substitutions:

Note the lack of illustrated headings. Wherever a section is opened, it assumes responsibility for nesting: The heading type is unimportant. More on this soon …

The outline for this example looks like this:

• Document
  • Article
    • Aside

Now that we’ve implemented sections, the boundaries are clear. Our document contains an article, which, in turn, contains an aside. There are three sections, each belonging to the last, and the depth of each section is reflected in the outline. Importantly, because sectioning elements wrap their contents, we know perfectly well where they end, as well as where they begin. And yes — screen readers like JAWS actually announce the end of sections like these! We know what content belongs to what, which makes deducing the purpose of the footer much easier. Because it exists outside the bounds of both the <article> and its <aside>, it must be the document’s footer. Here’s the same diagram again, with subsections faded out:

The power of sectioning lies in its ability to prescribe clearly defined boundaries, resulting in a more modular document hierarchy. The footer unequivocally belongs within the immediate scope of the highest-level section, giving assistive technologies and indexing parsers a good idea of its scope, which helps to make sense of the page’s overall structure.

Headings And Accessibility

When Sir Tim Berners-Lee conceived the <section> element all the way back in 1991, he envisioned the obsolescence of ranked heading levels. The thrust of the idea was that headings should act as mere labels for blocks of content, and the nature (i.e. the importance, scope, etc.) of the content would be calculated automatically based on the content’s standing in the document.

I would in fact prefer, instead of <h1>, <h2> etc for headings [those come from the AAP DTD] to have a nestable <section>..</section> element, and a generic <h>..</h> which at any level within the sections would produce the required level of heading.

Why is this preferable? Determining heading level systemically, based on nesting level, is much more dependable because it removes a layer of decision-making: By “producingâ€� the required heading level automatically, we no longer have to decide separately which numbered heading we should include. It effectively prevents us from choosing the wrong heading level, which would be bad for parsable structure. A subsection must be subject to its parent section. Because this relationship between sections determines “level,â€� numbered headings are made redundant — hence, the proposed <h>.

A lot of fuss over nothing

Now, this is the supposedly tricky part; the part that causes all the consternation and gnashing of teeth. This is the part that caused Luke Stevens to write this diatribe, and prompted Roger Johansson into a state of uncharacteristic apoplexy, asking, “are you confused too?�. Ready?

In the WHATWG specification (in the same place where <footer>s were ostensibly classified as sectioning elements!), we are “strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section’s nesting level.â€� On first appearance, this seems contrary. Surely only one of these courses of action can possibly be right? What do you do? I’m thinking maybe the first option. Or the second. Who am I?

It certainly confused me, so I spoke with HTML Editor, Ian Hickson. He explained the outline to me in detail and I’m convinced it is perfectly robust. I’m going to do my best to explain it to you here.

Okay. As it turns out, we didn’t get the generic <h> element. This wouldn’t be backwards compatible because older browsers wouldn’t recognise it. However, headings that introduce sections are — regardless of their numbered level — treated as a generic <h>. Quite correctly, it is the section itself that takes responsibility for nesting in these situations — not the heading — and whenever you introduce a new section, you introduce a new nesting level without fail. What does this mean in practice? It means that we can introduce and benefit from the structural clarification offered by sections without abandoning heading levels. Take the following example:

<h4>Page heading</h4>
<p>Introductory paragraph...</p>
<section>
    <h3>Section heading</h3>
    <p>some content...</p>
    <h2>Subheading</h2>
    <p>content following subheading...</p>
    <section>
        <h1>Sub-subheading</h1>
        <p>content two levels deep...</p>
    </section>
</section>
<h5>Another heading</h5>
<p>Continued content...</p>

Our heading levels are all over the place. This is not recommended by the specification, but it helps demonstrate just how robust the HTML5 outlining algorithm really is. If we replace all the headings that open sections with a generic (“wildcard”, if you prefer) <h>, things become clearer:

<h>Page heading</h>
<p>Introductory paragraph...</p>
<section>
    <h>Section heading</h>
    <p>some content...</p>
    <h2>Subheading</h2>
    <p>content following subheading...</p>
    <section>
        <h>Sub-subheading</h>
        <p>content two levels deep...</p>
    </section>
</section>
<h5>Another heading</h5>
<p>Continued content...</p>

It’s important to note that the only errors revealed in the computed outline are ones relating to badly ordered numbered headings within the same section. In the original example, you’ll see that I’ve followed an <h3> with an <h2>. Because they are in the wrong order, the outline interprets them as being on the same level. Had I encapsulated the <h2> in <section>, this error would have been suppressed.

Well, how about that? If you’re not convinced, go ahead and paste my example into the test outliner and play around. It works just fine. In fact, it’s really difficult to break.

If you think there is a benefit to screen reader users, you may wish to adhere to the second of the two clauses from the specification and incorporate numbered headings that reflect nesting level. As demonstrated, this will have no effect on the outline, but since heading level (“Heading Level 2 – The Importance Of Sectionsâ€�) is announced, it gives a clearer impression of structure to those who can’t see boxes inside boxes.

The assertation that heading levels are perpetually indispensable to screen reader users comes under pressure when you consider advancements being made by screen reader vendors. Screen readers like JAWS mark the territory of sections more clearly than headings, by announcing the beginnings and ends of sections and the thematic regions they represent (“Article End!â€�). From this perspective, using more than one <h1>s in your document might sometimes be applicable. You’ll come up against some accessibility experts who are keen on their “there can only be one [h1]!â€� mantra, but research shows that even in HTML4 or XHTML, this is not necessarily case.

The approach you choose is yours to make; just employ some common sense and consistency. Bear in mind, though, that not all screen readers are able to announce the bounds of sectioned content. In these cases, there are measures you can take …

ARIA Enhancement

Transition to an HTML5 document structure is made smoother by incorporating some ARIA landmark roles, which are both relatively well supported and somewhat analogous to the section-based navigation we should expect later. ARIA offers many more accessibility-specific features than baseline HTML5 could ever withstand; so, including “bolt-on� ARIA enhancements is certainly polite. However, regarding ARIA roles as a substitute for semantic HTML would be a grave misconception.

Landmark roles, such as role="navigation" and role="banner", address accessibility only — not data mining — and each may be used only once per document. They are essentially shortcuts to parts of the page. HTML elements are more like building blocks, which are used in a repeated and modular fashion. So, while you can assist accessibility by placing role=�banner� into the <header> element closest to the document’s root, this does not preclude you from using <header> to introduce other sections:

Are Sections The New <div>s?

This is a common misconception.

If it wasn’t clear already, it should be clear to you now that <div>s are semantically inert elements — elements that don’t really do or say anything. If this is clear, then it should also be clear that, when building a structured document, relying heavily on “an element of last resortâ€� makes for a very poor foundation.

If the new <section> element, for example, was just <div> with a new name, adopting it would be a straightforward matter of search and replace. It wouldn’t exactly be progress, though. The truth is, <div> still has a rightful place in the spec’; we’ve just given its organizational responsibilities to a team of elements that are better qualified. Sorry, <div>, old mate. What do we use <div>s for, then? Precisely what they were good at from the beginning: as a tool for “stylistic applications… when extant meaningful elements have exhausted their purpose.â€�

For instance, you shouldn’t employ sections as box-model controlling measures like this…

	<section class="outer">
		<section class="inner">
			<h1>Section title</h1>
		</section>
	</section>

… because there’s nothing that the outer section does that the inner section doesn’t. We’ve created two sections for one piece of content. A quick run through our outliner throws the “Untitled Sectionâ€� warning:

• [Untitled Section]
  • Section title

The brilliance of <div> in this context is that it refuses to affect the outline, which is why we can use it without fear of reprisal. This…

	<section>
		<div>
			<h1&gtSection title</h1>
		</div>
	</section> 

… averts disaster and results in this unsullied, if simplistic, outline:

• Section title

Sections And Semantics

A lot of developers have trouble with the word “semantic.â€� You might even say that they don’t know what the word means, which (if you are familiar with the term) makes an interesting paradox. For instance, when Jeffrey Zeldman advocates for the “semanticâ€� application of the id attribute, he’s kind of missing the point. The main purpose of semantic HTML is for the automated extraction of meaning from content. Applying a private, non-standard id to a <div> would not improve the semantics of the element one iota: Visitors can’t see it and parsers will ignore it. So much for the semantic Web!

Sections are often characterized as the “semanticâ€� equivalent of <div>. This is a half-truth at best, and I apologize for throwing the term “semanticâ€� around so much — it’s become a bit of a shorthand. Some HTML elements are inherently semantic in that they prescribe specific meaning to their contents. The <address> element is a good example: When a parser reaches <address>, it knows that the contents should probably be interpreted as contact information. What it chooses to do with this knowledge is another matter, but it’s plausible that a screen reader could provide a shortcut to the address or a search engine could use it to refine its results pages.

Sectioning elements are not so much semantic as syntactic. All <section> tells us is that it is a part of a whole. However, the syntactic contribution of sectioning elements to document structure is not unimportant. Consider the following sentence: If sections you don’t websites your are use obsolete. A lot of recognizable words are in there, but the lack of sensible syntax makes the sentence difficult to unpick. So it is with sectioning: You are not creating meaning so much as assembling it. Meaning isn’t always about the “thing”; it’s sometimes about what that thing’s role is amongst other things.

Microdata

Efficient, syntactically sound data structures are worthless if they are semantically lacking. Fortunately, HTML5 has both angles covered and provides a mechanism for attaching semantic meta data, called “microdata,� to our structured content. Using microdata, and by consulting schema.org, you can define a page’s content as anything from a scholarly article to an exercise regimen. Unlike classes and IDs, this is information that can actually be interpreted usefully.

This microdata was found by Google and displayed in its “Structured Data Dashboard� for the WordPress theme Typical.

Conclusion

HTML isn’t just an SDK or a Graphic Designer’s palette. It is a metalanguage, a language that tells you special information about information. Sometimes we — or, more precisely, the parsers we employ — benefit from added information about the subject, timing, origin or popularity of content. This is what APIs such as microdata and RDFa are for. Other times, the context, hierarchy, relative importance and codependence of the information are what need to be determined. This is where appropriate syntax, facilitated by sectioning elements, can be employed.

Some people will tell you not to bother with sectioning. They say that it’s hard work or that it doesn’t make sense. This is hokum. Sure, if you’re lazy, don’t bother with sectioning, but don’t pretend you’re doing it on principle. Using sections demonstrably enhances HTML structure without breaking accessibility. We’ve covered this.

Still, there will always be people who will attack this aspect of the specification. Perhaps we’ll enjoy some of these objections in the comments:

1. They will point to bad implementations by specific vendors:
   “These are bugs and bugs get fixed!”
2. They will cite the actions of large websites who don’t use sectioning elements:
   “Just because large sites haven’t implemented sections doesn’t mean they wouldn’t like to. Since when does big mean ‘right’ anyway?”
3. They will flood you with examples of developers implementing sections badly:
   “Some developers do stupid things and their misuse of HTML doesn’t stop at sections. I include myself here, by the way.”
4. They will present you with anecdotal evidence about user behavior within specific groups:
   “It is expensive and impractical to address problems on a case-by-case basis. Fragmentation and complexity would also be inevitable: a loss for the majority, not a specific minority, of users.”

I don’t think anyone would advocate making badly structured Web documents any more than they’d suggest building a house by stuffing a bag full of bricks and throwing it into a ravine. The case has been made and the specification bears it out: Sections aren’t just good for document structure — they finally make proper structure attainable. Some browsers and screen readers have some catching up to do, that’s for sure, but the situation is improving rapidly. Any kind of change is a little turbulent, but this kind is worth it.

(al)

© Heydon Pickering for Smashing Magazine, 2013.