Simply Jonathan

Archive for 2016

CSS Shorthand Syntax Considered an Anti-Pattern 

I tend to go for the background shorthand, and certainly the font one, but in general, implicitly setting values is something one should avoid, in CSS as in most other programming languages.

Big Tablets Are Coming 

Permanent location of 'Big Tablets Are Coming'

Evan Miller on an in his opinion obviously imminent future with big tablets as the form factor of choice for professionals, primarily focussing on the shortcomings of mouse pointers:

The mouse pointer was designed for a 9″ screen, not a 29″ one.

It’s an intriguing argument, especially the serious considerations of styli (cue “They blow it” quote from Steve Jobs). I think there could be something here. (Even if I have historically been swayed by Apple’s arguments about the tiring of arms, the angle at which you can use a Surface Studio should help with that.)


Change, shit
I guess change is good for any of us

– Tupac Shakur

Yesterday, I returned from NIPS 2016. It’s the world’s preeminent machine learning conference.

What was I doing there? To be fair, it was probably not the conference I would have picked, but it was a very interesting conference to attend (the first of its kind I’ve ever been to, to boot). The reason I was there was because on 1 November I started a new job, working for Danish startup Sportcaster. This also means that after almost four years, I have left PDC, where I started working when Ovivo was acquired. (I realise I’ve been horrible at updating the blog with this information, but better late than never, I suppose.)

Working for PDC has been a great experience. I’ve felt welcome in all my years there, even though I got into the company by untraditional means, and even though – as I have joked many times over the years – I would never have been able to land a job there by sending a regular application. (The company values educational credentials very highly, so my B.A. in English and Communication & Rhetoric is basically useless as an engineer.) I would encourage anyone wanting to work with Microsoft technologies or, especially, Prolog in Copenhagen to take a look PDC’s way, it’s a great place to work.

For me, however, Sportcaster presented the complete package: The company’s goal is making a product aimed at filming grassroots association football, and I will be doing their web platform. This allows me to combine my interest (OK, let’s just call it ‘obsession’) with football as well as doing web development in Python. If someone had asked me what I wanted to do that would basically have been it.

My first month there has been excellent, and I look forward to spending a long time there, and I’ll try to make an effort updating this space with news of development.

A 4-bit Calculator made in cardboard and marble 

This is amazing.

One of my favourite books is Charles Petzold‘s Code. This seems like something straight of the early chapters, it’s fantastic.

Enhancing a comment form: From basic to custom error message to BackgroundSync 

Simple step-by-step instructions for how to take a plain old form and improving it with lots of added behaviour, provided the browser supports the features.

This should really serve as the go-to example for how to do progressive enhancement.

Why should I use Python 3? 

Permanent location of 'Why should I use Python 3?'

Eevee on a lot of the things that are great in Python 3, especially compared to Python 2.

I have been very slow to upgrade myself, but will make an effort to do so, at least for my personal projects, and certainly for new projects.

Jeremy Keith: <A> 

Permanent location of 'Jeremy Keith: <A>'

A beautiful speech by Jeremy about ‘A’ in web development: the obvious one, and some of the less so.


Tonight I’ve published Mediany, a small JavaScript library I’ve been working on. It’s released under the MIT License.

Mediany allows you to declare behaviour at different media query breakpoints. This allows you to e.g. have one thing happen when a button is clicked at one screen size, and something else (or something additional) happen when it is clicked at another screen size.

I built this to scratch my own itch. With responsive web design, it has become customary to transform the design based on the screen size of the user’s viewport – rearrange elements into columns, show things that were previously hidden, etc. (Media queries have a great many additional things to check for, but checking screen size – and width in particular – is the most common use case.)

As one transforms the design to fit larger sizes, I found that I also need to modify the behaviour. Clicking a button might require some set of changes at a small size, and something else entirely at a larger screen size. Mediany helps this process by declaring behaviour at specific media queries.

What’s in a name

I initially wanted to name the library responsive.js, because my research back then had indicated that was an unused name. As it turns out, it isn’t.

I still think responsive.js would be a great name for it. It is, in my estimation, the JavaScript library I’ve seen that comes closest to the principles of Responsive Web Design. There are a lot of libraries that will allow a mix of dynamic rendering (see aforementioned responsive.js project) and more complex break point handling. What I wanted was very simple: When a media query is true, perform this behaviour. I don’t want to handle the transition between two queries, and indeed I point people towards BreakJS for that functionality, I just want simple, declarative behaviour.

Developing a library

This is the first JavaScript library I’ve ever published. A lot of best practices were new to me (and I might indeed have missed many). I settled for a very conservative behaviour: there is no ES6-style encapsulation, only a simple bootstrapping function and one intended-for-public-consumption function: mediany.

It was also the development of Mediany that had my thinking so much about mustard. In the end, after a back and forth with Jeremy Keith, I settled for checking for features I reasonably expect aren’t present, but not all (Object.prototype.hasOwnProperty and Array.prototype.push not being feature-checked, although I technically could do it).

Mediany is available on npm, and I welcome any feedback.

Jean Grae – 2-32’s

I raise havoc, like giving Mobb Deep a booster chair

Knowing what mustard to cut

‘Cutting the mustard’ is the term the BBC News web developers use for what in other circles is called ‘feature detection’: Programmatically checking whether a given feature is available in the user’s browser.

The technique can be summarised succinctly as:

if (feature in element) {}

Where feature is the feature to check for (like ‘querySelector’) and element is the element you will be accessing said feature on (often window or document, though it can be any DOM element).

This is a crucial component of progressive enhancement, adding features to users whose browsers can support them, in a layered manner where said features are considered additions.

The problem I have encountered is of a philosophical nature: What features should one cut the mustard for?

If we take BBC’s opening statement (‘The browser is a hostile development environment’) to its extreme conclusion, a browser could theoretically support no JavaScript APIs. Thus, to cut the mustard, one would have to feature detect everything.

Now, this is probably overkill. Aside from the obvious fact that if the browser doesn’t support the controls if and in feature detection isn’t even possible, there are softer features to check for that are probably overkill. Object.prototype.hasOwnProperty() has been part of JavaScript since the beginning, and is implemented in all browsers known to MDN, so it can probably be assumed to be present.

But this still leaves the question: What features should one cut the mustard for? If we can assume some features are present, but not others, how do we determine which ones to check for? The only good rule of thumb I can think of is consulting implementation tables such as the ones on MDN and Can I use…, and drawing the line somewhere. And although better than outright user agent detection, it veers too close for my liking.

This might be me being too idealistic, but I am still unsure of the right approach.

This is Simply Jonathan, a blog written by Jonathan Holst. It's mostly about technical topics (and mainly the Web at that), but an occasional post on clothing, sports, and general personal life topics can be found.

Jonathan Holst is a programmer, language enthusiast, sports fan, and appreciator of good design, living in Copenhagen, Denmark, Europe. He is also someone pretentious enough to call himself the 'author' of a blog. And talk about himself in the third person.