HTML5 Zone is brought to you in partnership with:

I spend my spare time combining the luxury life of having no kids and a wonderful girlfriend with the agonizing pressure of blogging under my Onderhond monicker. As a front-end developer I am raised and nurtured at Internet Architects, a Belgian company investing a lot of time and resources in making the web a better place Niels is a DZone MVB and is not an employee of DZone and has posted 109 posts at DZone. You can read more from them at their website. View Full User Profile

Writing HTML with your Eyes Closed

11.13.2012
| 2713 views |
  • submit to reddit

In between attempts to fully wrap my head around the far-stretching implications of responsive design, I like to hone my html skills. Leaving all practical worries behind, it's actually nice to dig into something that's fairly straight-forward, looking for ways to improve what we already (think we) know. From time to time this even leads to interesting and surprising observations, shedding new light onto things we thought we understood.

HTML Based on Design

I think one of the most important hurdles in the job of any html developer is reading the input he gets without getting caught in the visualization of things. I write html based on wireframes and design, but both types of input present the same difficulties and problems: they are already visuals representations of the content, taking into account dimensions, available real estate and page layout, mutating the content into something that may look different, but is essentially the same as something else. When it comes to html (in other words, semantics and structure) these visual differences are of little consequence.

Of course a reality exists where we have to make sure that the html we write can support the css to accomplish the proposed designs, but far too often we forget the basics and simply convert what we see in front of us to html code without giving the content a second thought.

Just take a moment to consider the following datepicker component (1). It's a pretty simple list of dates that can either be used as a filter or pager on a list of content types (depending on the implementation). I'm pretty sure that most, if not all people would resort to using a list element here, possibly bickering about whether to use a heading for the month and maybe starting another discussion on the difference between ol/ul. And I couldn't say they were wrong, but ...

There is More

A bit further down the line I came across a responsive variant of that same datepicker component (2). Suddenly it started to look like a more traditional datepicker, table-style. I bet that if people saw this variation first, they would've opted to use a table element instead of a list element. Sure there is room to whine about whether to use captions or theads for the month and whether to include the back link into the table, but basically using a table makes plenty of sense here.

The thing is that they are both the same component, so why would there be two possible implementations? When you look at css feasibility, the list is probably a bit easier to implement (especially for older browsers), but it's perfectly possible to use either html implementation and style both variations, so that's not helping us along either. And didn't we always say that css is just for styling?

The Richest of them All

The thing about date lists is that they are essentially tabular data. Even when you present them as a flat list (which isn't wrong because they represent a flat continuation in time) they still have a 2-dimensional connection, namely weeks and weekdays. This is important because it could allow people to use this connection to easier navigate through the data.

In other words, when you use a list you can only advance one day at a time, but when you use a table you can advance by only focusing on each Friday without having to skip through all the other days. Or you could skip a week instead of cycling through its seven days. A pretty useful addition when it comes to filtering by date (maybe you always have Fridays off and you don't care about the other days). So even though both html setups are valid, the table implementation gives us more context to describe the data, allowing for better functionality. Case closed: use a table (even when there is no responsive variation).

Conclusion

The irony of this post is of course that responsive design actually helps you to focus on the content rather than the visualization of this content. Because each component can be visualized in a number of ways, responsive design helps you to see through these visualizations, forcing you to focus on the content itself.

It does hint at the fact that we don't really spend enough time thinking about marking up our content, instead focusing on visualizations and drawing our html inspiration from that. Sometimes it would be better if we could html with our eyes closed, foregoing all visual input and focusing just on the content and the proper way to structure it. I'm sure you'd be surprised how weird our html may look from that perspective.




Published at DZone with permission of Niels Matthijs, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)