How my new responsive design here works

June 25, 2014

Encouraged by the commentators (and their suggestions) on my earlier entry about responsive design here, I sat down and banged out some CSS and revised my markup. Since I went through a bunch of iterations (many of them not working) to get my current results, I want to write down everything before I forget how it all works and why I needed to do things the way I have.

Following Aristotle Pagaltzis's suggestion, the core styling is done with 'display: table...' settings on <div>s. The div tree looks like this (roughly):

<div class="wtblog">
   <div class="maintext">
      ... left column contents ...
   </div>
   <div class="sidebar">
      ... sidebar contents ...
   </div>
</div>

In the normal CSS rules, wtblog is set to display: table while the other two are set to display: table-cell with their widths set to 76% and 24% respectively. This creates an implicit table row and stacks them up side by side with most of the space given to the main content. The table-* display styles seem well supported on anything I really care about (IE 7 users are out of luck, though). This is basically exactly the structure I used to create via actual <table>, <tr>, and <td> elements. The initial rewrite to this form was pretty much easy and painless.

My first CSS attempt to transform this into a minimized version with the sidebar below the main content was too clever. In my media qualifier rules I reset each column to 'display: table-row' in order to get them to stack on top of each other, which worked but had the problem that display: table-row entities can't have borders and I wanted to set a top border on the sidebar. This caused me to go through several iterations of inventing extra <div>s so that I would have something to make into a display: table-cell <div> inside the table-row <div>.

After a while I came to my senses and realized the straightforward, obvious solution: plain 'display: block' <div>s already stack on top of each other. So now the minimized version resets all three <div>s to be 'display: block; width: auto;' (in addition to tinkering with margins, borders, and various other things). This just works.

I did go through some amount of pain finding a @media query that would work on the iPad Mini, not just in a desktop browser when it was narrowed. After some fiddling I made it work by checking against max-device-width as well as plain max-width (which is what the browsers are happy with). I also have a really iPad Mini specific rule to increase the font sizes some as well; I aimed for something that would make my content look much like the 'readability' view you can get in the iPad browser.

While I was fiddling around with my CSS I also set up a maximum width so that people with giant browsers on giant screens don't get text that sprawls all over the place. The maximum width is probably still too wide for good readability, but I don't know what the right maximum width is considered to be (casual web searches did not help answer this question).

Because I'm lazy and not crazy I specified almost all of my limits and sizes in ems so I didn't have to care about font sizes. In fact I think this works best; someone who has really increased their font size because they find it more readable doesn't magically want to read fewer words in a line than normal. Unfortunately not everything has sensible default font sizes, especially the iPad Mini.

(In writing this entry I've discovered that CSS has added all sorts of exciting new sizing units since I last looked at it quite a lot of years ago. Possibly I will use some of them in my CSS at some point, once I understand things like rem and vw better.)

The whole experience has been a lot less painful than I expected it to be. Dealing with the iPad Mini's peculiarities was annoying and involved a lot of experimentation with things that didn't work, but apart from that things went pretty smoothly. I ran into one CSS quirk but it's documented, more or less, and I think it existed even in the <table> version of my layout.

(The quirk is that almost all of the ways you might think of to move the first line of one table cell down relative to the first line of the other table cell don't work. They either don't do anything or they move both columns down at once. The solution is to explicitly set 'vertical-align: top;' in the table cell you want to offset; then things like padding will start working.)

Written on 25 June 2014.
« Python 3 has already succeeded in the long run
A retrospective on our Solaris ZFS-based NFS fileservers (part 1) »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 25 01:09:16 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.