I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

A day in the life

Thursday was an unusual day. I thought I’d describe it, so that you know what one of my unusual-but-not-ultra-weird days looks like.

When I woke up my aim was to continue writing my viewport chapter. After coffee and minor administrative chores I re-read what I’d written on Wednesday and made a few edits — more to get in the writing mood than for anything else.

Then I switched to my outline and saw that the major upcoming topics were resolution and media queries. Both badly needed research, and since the major tool for handling resolution is media queries I decided it was time to work on them. I wrote a test suite a year ago but had never yet run a full 40-browser test.

So there. No writing but testing today. Not great, but OK.

I went through my test suite and tested a few browsers for width media queries — the so-called pre-testing to get me in the mood and spot wildly off results. Then I noticed a link to a test for the em and rem units. I idly clicked on it and played with it, until I noticed I ran an equality test for the width media query in ems and window.innerWidth/16. These were supposed to be equal, and browsers enthusiastically agreed.

W? T? F? Why?

One minor tweetstorm later I recalled that yes, people do set media queries in ems (it’s even very popular), and that in media queries, as opposed to all other contexts, ems are not relative to the current font size but to the root font size. default root font size is 16px, so there. I decided to nod wisely and leave it at that.

So an em is really a rem in media queries. Hey, I should test rems, too. They make more sense than ems. Add entry in compatibility table.

One of the last replies was from someone who said something about ems and viewports, and I sent back my usual “Which viewport?” reply. There are three on mobile, and one has to keep them apart or risk insanity. No reply. Of course not.

Still, it set me thinking. What about the viewport? Does the media query width in ems stay window.innerWidth/16 in all circumstances? I’d written my test suite with width=device, so all browsers used their ideal viewport. What about when they don’t?

A few minutes later I had discovered that in Safari iOS7 iPad the equivalency stopped at an 800px-wide viewport. Not 768 (ideal) or 980 (default layout), as you’d expect, but 800. Weird. I wasn’t sure what was going on, though I suspect that the iOS font weirdness plays a major part. iOS does fishy things with font sizes, but rather subtly. Since I still haven’t found a way to reliably read out the real font size in JavaScript, I was sorely tempted to leave it at that.

OK, one more test. Chrome. A browser I trust. Hey, something weird here, not on the Nexus 7, but on the Galaxy Note ...

A few tests convinced me that Chrome has a viewport bug exactly in the page I wanted to test. Caused by my script. The layout viewport is too wide, and the zoom level all wrong. Damn. OK, then on the Sony Xperia? Same result.

OK, so never mind the bloody bugs with tbe bloody ems in the bloody width media queries with a large bloody layout viewport. Let’s ignore then. Maybe they’ll go away by themselves. Nobody seems to combine the two, in any case.

Thoroughly annoyed, I called for a break. Some light shopping. Milk, some meat, bread. Oh, and a phone. The local store has a cheap LG Android 4, I have some money, and an LG is an excellent phone if you want to be annoyed at the world in general. Besides, I deserve some consumer electronics right now. So there.

Back home. Start up phone, check for updates. Android 4.1.2, Android WebKit. Create new mobile phone test array with the LG L5 in it. Nothing special.

Wait. Let’s install a brand-new Chrome and see if that bug is still active. Maybe it’s something with the other phones. OK, log into Google account, search for Chrome in Google Play... Here we are. Update.

Waitaminute. Update? Not install? Is Chrome already on this phone? Yup. Chrome 18, to be exact.

W? T? F? Really, though, this time. What? The? Fuck? Much majorer What The Fuck than the previous What The Fuck.

Chrome 18 is pre-installed. Update. Chrome 30 is now installed. Factory reset. Do not log in to Google account. Chrome 18 is pre-installed.

Break time. Wait ... what about other modern Androids? Galaxy S4, which has Chrome 18 as its default browser. Yup, there’s another one, but I might have put it there myself. Factory reset. Chrome 26 pre-installed. Next to Chrome 18. Galaxy S3? Exactly the same. Chrome 26 is installed after a factory reset.

So Google is quietly distributing Chromes on phones that have other default browsers. Wow. Makes sense, from their perspective, but still wow.

Write blogpost. Tweet about it. Get confirmation: some package deal with Gmail and Maps. Now that I think of it I have read something about it. Wish the Chrome team would distribute such information. Update blog post.

What the hell was I doing, anyway? What was I supposed to be doing today? Hey, tweet: IE11 final for Windows 7. Cool. Must test it. Some day. Not now. Waitaminute, will my modern.ie installs update themselves? Ask on Twitter. Update Windows. Wait for fucking ages. Get a version number that doesn’t tell me anything.

What the hell was I doing, anyway? What was I supposed to be doing today?

Number of words written for viewport chapter

Zero

Number of media query tests in browsers

Technically not zero, but they were pre-tests and I didn’t make any notes. So effectively zero.

Number of weird things discovered that have no connnection to the things I should be working on

Shitloads

Day done. Hungry. Tired.