Sunday 24th June 2012: 5.19pm. I got back from my PGCert exams about ten days ago, rested for a day, then launched into my Pure Maths coursework which I posted off on Thursday. I then spent a day writing up my summer todo list before we emigrate to Canada which is as follows:
- Sign up to swimming pool and substantially improve fitness before emigration.
- Solve nedprod diary archival problem once and for all, and finally shrink that enormous front page!
- Enable long overdue mobile view for nedprod.
- Enable long overdue print view for nedprod.
- Pay 2011 corporation tax for my company and catch up on its accounts.
- Submit 2011 Irish and UK tax returns (yes, I must pay tax in both countries!)
- Close off outstanding bills to my company, hopefully getting those owing money to pay up, and begin making the company dormant.
- Write up reference implementations of stuff being submitted to POSIX and ISO and submit them.
- Do annual summer release of my libraries to propagate past year's bug fixes and fix bitrot.
- Finish BEXML and BEurtle.
- Finish reading The C++ Standard Library: A Tutorial and Reference (2nd Edition).
As you can tell by the strikethroughs, I've made
a good start. I haven't actually swum - not once -
in nearly twenty years, so the fitness regaining is
going to be embarassing for the first two weeks or
so as I flail around haplessly, but I signed myself
and Megan up for two months' membership, so at least
I'll provide her with no doubt much side splitting
amusement
.
As you may have noticed by this page being much shorter, I have finally solved the diary post archival problem once and for all and while I was at it I solved the lack of permalinks to posts too. Up until now, since 1998, I archived by copying and pasting each post from the front page into a page per month in the archive folder, then manually hand linking them into a sequence and adding them into the index page. This was so time consuming and boring I always kept putting it off, leading to as much as 250Kb of text on the front page which is plain silly. The new system uses a bit of PHP to autogenerate a page per post and another bit to autogenerate the index, and to archive I now simply have to copy and paste into a single archive file and leave the PHP figure it all out. Outstanding!
The last two completed items are that I finally got round to implementing CSS media views for nedprod, specifically for mobile/handhelds and for print. This required manually find and inserting a magic header insert into every HTML file on nedprod using varying regular expressions, and it took me the entire of Saturday to complete as something like six different versions of FrontPage/Expression Web have touched nedprod over the years, and they were all different. The new magic header insert lets me specify common <head> contents for all pages, so I was finally able to mark all pages as being authored by me to Google and to supply @media handheld and print stylesheets for all nedprod HTML.
Now, I have to admit it is embarassing how it has taken this long to add this to nedprod - particularly the print CSS which is so basic: hide navigational and promotional elements, hide clutter, print URLs after links. The new mobile view is more interesting though: I have been checking that nedprod renders okay on mobile devices since the days of Windows Mobile but I was happy if it looked identical to the desktop view. Over time, as I have browsed nedprod from my own mobile because it's handy as a memory aid, I've begun to prefer if the page were vertically flowed for small screens. With the work done during the last few days, any time the page becomes narrower than 720px it will autoenable the vertical flow - in fact, you can try it now with your desktop browser and see for yourself. Believe it or not, this automatic switch doesn't use Javascript - it uses the new W3C CSS3 media queries extension which any recent browser will (mostly, and not always bug free) support.
Basically, this media queries extension lets you set conditions on CSS blocks, so "if device screen is less than X apply this CSS" and so on. In fact, here is the CSS I wrote for nedprod:
@media handheld, only screen and (max-width: 720px),
only screen and (max-device-width: 720px) {
table#autolanguagetranslation {
display: none;
}
table#autolanguagetranslation + p {
display: none;
}
table.bodytext > tbody > tr > td {
display: block;
}
table.navbar {
position:relative;
margin-left:auto;
margin-right:auto;
width: auto;
}
table.navbar + p, table.navbar + p + p {
display: none;
}
td.navbardivider {
width:100% !important;
}
* { max-width: 720px; }
}
@media only screen and (max-width: 640px),
only screen and (max-device-width: 640px) {
* { max-width: 640px; }
}
@media only screen and (max-width: 480px),
only screen and (max-device-width: 480px) {
* { max-width: 480px; }
}
@media only screen and (max-width: 320px),
only screen and (max-device-width: 320px) {
* { max-width: 320px; }
}
Note how I additionally test for screen widths less than 640px (iPhone 4), 480px (most older smartphones) and 320px (feature phones) and override the earlier max-width setting on * i.e. all elements. This max-width setting is basically a clamp on the maximum width of any element to the screen width, thus ensuring that any single element on the page will be shrunk to fit onto the screen without panning (if that element can be sufficiently shrunk of course). If the element can't be shrunk e.g. a <pre> section, then panning is available for that element alone. A lot of "how to do mobile stylesheet" guides recommend shrinking all images by 25%, but that buggers small images. This max-width approach constrains any image which is too big to fit, but leaves smaller images alone.
So, perhaps worth waiting for CSS3 media queries after all! The only final thing is to declare your HTML as mobile aware by adding this to your <head>:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=2.0, user-scalable=yes" />
And voilà your HTML is mobile aware. I note that
all is not perfect on mobile web browsers though.
Desktop Chrome and Opera both render the vertical
flow perfectly, albeit both forgetting to adjust for
the fact there is a vertical scroll bar there and
hence chopping off a bit of contents on the edges. My Samsung Galaxy Nexus (Android 4.0.4)
seems to start off thinking it is a 480px wide
device, not 720px, and renders the text accordingly
(probably for compatibility with older phones) but
decides about half way through the rendering to
suddenly shift to a 640px page width, not 720px
(perhaps for compatibility with the iPhone 4 this
time?). Weird, I know. But it gets weirder: when it
shifts to 640px, it doesn't bother redoing layout
for inline positioned items such as almost all the
text, so only block items are relaid out to have the
correct width and be correctly positioned. Therefore
almost all the text is offset to the left with a
large empty space on the right which looks
inconsistent. Megan's Samsung
Galaxy S (Android 2.3.6) is both better and worse
because it only observes the first screen setting it
sees which is 720px and this it does render
perfectly. However,
inexplicably it disables your ability to zoom out and thus forces
you to pan everywhere using its little 480px screen
on a 720px canvas
which is very irritating. Buggy browsers: what can
one do? I have hope for the future though: Opera
Mobile gets it right at default zooms of 100%, 150%,
and 200%. Interestingly, the default default zoom in
a new install is
225% at which, of course, it completely borks the page
.
Anyway, it's now past 8pm so I'd better get moving as I have the final copy of the index of Economists and the Powerful to submit. So, have a great, being happy summer!