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.