== How my new responsive design here works

Encouraged by the commentators (and their suggestions) on [[my
earlier entry about responsive design here ResponsiveDesignNeed]],
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 http://plasmasturm.org/]]'s suggestion,
the core styling is done with '_display: table..._' settings on
_<div>_s. The div tree looks like this (roughly):

.pn prewrap on
>  <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
http://caniuse.com/css-table]] 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.)