Wandering Thoughts archives

How my new responsive design here works

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.)

I need some responsive website design around here

For reasons that involve increasing usage and lowering costs, work got an iPad Mini and I wound up as its holder (it may shock you to know that we didn't really have any tablets around before this). One of the things I've done with it is look at websites, including Wandering Thoughts. In a way this is unfortunate, because now I really want to redesign Wandering Thoughts to be responsive. What I really mean by 'responsive' here is that I want the sidebar to go away on small screen devices.

(Well, the sidebar should go down to the bottom. I don't want it to go away entirely.)

The iPad Mini is small enough that screen real estate is at a premium on websites. If you use it in vertical mode, you don't have room for anything apart from the content text; if you use it in horizontal mode, well, you sort of have room for a sidebar but not really, and anyways you'd rather read vertically because that's more text and it's is laid out in a more readable way because it's narrower (in my view). I can only imagine how much worse this is on a smaller device, like a phone. This is the sidebar issue made quite concrete for me.

The problem is that I don't know the best way to do this without completely tearing the site design apart, or if it's even achievable very easily without Javascript (and I refuse to make Javascript a required thing here). Someday CSS grid layout will make this easy, whenever it's supported by most browsers (and perhaps finalized), but that day is not today. I suspect that I can't do this at all easily in regular CSS unless I start forcing column widths, but I haven't looked recently. And I'd rather not force column widths because then I'd have to read up on design to figure out how wide readable columns are, instead of my current approach of punting on it (since browser width determines column width and in theory people can make their browsers narrower or wider).

The radical approach would be a complete redesign of the look of Wandering Thoughts that permanently demoted what is currently the sidebar down to the bottom of the page even on regular browsers with lots of screen real estate. Many blogs today have taken this simplified approach but I'm not sure I like it (and I'm not sure I like the lower visibility of some things in the sidebar, like my Twitter). Still, it would solve the problem.

Ultimately design is a hard problem and CSS's current awkwardness doesn't make it any easier. This probably means the current Wandering Thoughts layout is going to stay as is, since that approach takes the least effort even if it makes me wince a bit when I look at the site on the iPad Mini.

The web is social, and thus minor features can matter a lot

For a very long time, DWiki (the software behind this blog) had a very primitive comment system. One of the ways that it was primitive is that it didn't have any explicit user-visible field for your name. When you made a comment here it showed up with your IP address at the time and it was up to you to explicitly sign the comment in some way if you wanted to. I always knew that this was rather low-rent, but it took me years to get around to fixing it. One of the reasons that I didn't get around to it very fast was that I didn't see it as a very important change; after all, it was just being a bit more explicit about comment author identification.

I was wrong. After I made the change last August, my perception of the entire character of the comments section here changed. The easiest way to put it is that suddenly I was reading and interacting with people, people with names (and sometimes websites). Part of this is that people actually filled in their names where before many hadn't gone to the extra work of signing their messages, but another part of it is that once I had people's names I changed how comments were displayed to show the name instead of the IP address. And the two together worked a magic transformation from bland IP addresses to named people.

The first lesson I draw from this is something that I already knew in theory, namely that the web is a social place. Interacting with people is a powerful thing and we like it. The more we see our interactions on the web that way, the better, which means that features that encourage that feeling are probably a good idea (even if they're small and simple ones, as here).

The second lesson is the power of small changes (or at least what you think of as small changes). My current guess or theory about this is that ultimately the illusion of personhood on the web is made out of smoke and mirrors; it's at least partially a trick we all play on ourselves when we imbue some codepoints on a screen with personhood and so on. As a trick, little nudges can go a long way (and probably little glitches can ruin the illusion). We're predisposed to see things on the web (and anywhere) as people, so all it needs is a push to do it and that push can be a small one.

(This goes with the general idea that people are social that I wrote about a long time ago.)

(I doubt that this is a novel observation. I just feel like writing it down due to my own striking experience with the DWiki comment change. Such a relatively small change, such a big shift.)