Dec 22 2016

The never ending march of progress! It’s been a bit over five years since I tried build my last site (which ended up shelved until now). Looking just at the little part of web tech I used, things have really moved on.

Last time I was doing this, Internet Explorer was still causing incompatibility issues. Now, with the release of Edge and IE 11 being mostly standards compliant, most of those concerns (for html/css) have gone away. And when something is causing a problem, even Internet Explorer has dev tools and an inspector! After using Firebug for many years, the in-built dev tools have just made it redundant.

I’ve also found some great resources which I either didn’t exist in 2010, or I just never knew about them. First is Can I use which really helps determine if a css feature you just found is universally accepted, a single-browser novelty, or hot-new-thing noone has implemented. The second is MDN, an invaluable reference and guide to html, css, and js. It’s by Mozilla, but it appears to be a good reference across browsers.

(If you’re a cool kid, and use ddg, you can quickly search both, in your address bar, by doing either !caniuse css-thing or !mdn webthing)

When I built the first version of pddds, the way things were, I didn’t get a chance to really use some of the modern web things. Partly because were was still patchy support, partly because I just didn’t have the time. This version has been different; from the outset I’ve been focusing on


Jekyll wasn’t one of the new things, I had used it on the first version, but with the amount it seems to have changed since 2011, it feels like a very different tool.

When I used it last, it was still a novel ruby project. Now it’s really matured into a solid framework. Looking through the contributions it looks like this all started happening in 2013 when parkr took over the project. It seems more streamlined, you can go from install to a blog in no time. Things that I had previously thought of building plugins to do now seem possible just using the vanilla tools, and that’s not to say it’s bloated. Running through the docs

Instead of spending time setting up jekyll, I’ve been able to get right to building the website.


I don’t remember if sass was shipped with jekyll previously; I remember reading about it, but it seemed like a hassle to set up with uncertain benefits. It also seemed like a toss up between sass and less.

Well that all changed. Sass is shipped with jekyll, sass appears to be the better choice over less, and I’m sold on it just by the tools for managing colours.

Previously I’d used jekyll to define reusable colours, which was ok, but was really just a hack. Now, using sass, I can do it in a css-like way:

$purple: #8D205A;


$linkVistedCol:darken($linkCol, 20%);
a {
    color: $linkCol;
    &:visited { color: $linkVistedCol; }
    &:hover {
        color: $linkHoverCol;

And then there are the mixins, which let you define reusable blocks or functions. For example, for the shadowed line I have:

@mixin border-shadow($highlight, $shadow) {
    border-#{$highlight}: 1px solid $highlightCol;
    border-#{$shadow}: 1px solid $shadowCol;

Which you can then include, setting which border is the highlight and which is the shadow:

hr {
    border: 0;
    height: 0;
    @include border-shadow(bottom, top);

There is more in there, but that’s all I’ve really needed so far.


Web fonts (where you load the font from the server), as I remember them, were some combination of flash and javascript hacks. Things are pretty different now, although it still requires some javascript superglue to load the fonts.

I found a nice, clean, open source font; Fira by Mozilla. I use for all the headers on the site.

Now, the problem. Browsers support web fonts as part of the Css, but there are some issues. The main being “FOIT” (Flash of Invisible Text). The browser won’t render your text until the font is loaded, so you really need two fonts, and you need to switch between them once the font has loaded. This is where I use Font Face Observer to smooth over the cracks.

It’s a bit rough, but this is how it looks in the html:

<script type="text/javascript" src="/js/fontfaceobserver.js"></script>
<script type="text/javascript">
let font800 = new FontFaceObserver('Fira Sans', { weight: 800 });
let font700 = new FontFaceObserver('Fira Sans', { weight: 700 });
let font500 = new FontFaceObserver('Fira Sans', { weight: 500 });

Promise.all([font800.load(), font700.load(), font500.load()])
    .then( function(){
        document.documentElement.className += " fonts-loaded";

Now, if you don’t run with javascript it won’t work (which makes me sad as a NoScript user) but the fallback font is not that different.

The main body just uses “traditional” fonts; specifying the already installed font to use. Nothing new with this, except now there are reliable modern system fonts. It’s good enough for Medium, why not me?

body {
        "Segoe UI",
        "Helvetica Neue",

I think it looks nice.

Responsive Layout

Leaving the best till last, I built the site “responsive first” or whatever therm term is. Once I had the infrastructure down, and I’d played around with the fonts, I started looking at how to build the site for mobile, tablet and desktop.

I went into this area completely blind and, like many of the new web tech I’ve learnt, was pleasantly surprised at how easy it was. There were a couple of articles about using css flex, but I was still mostly in the dark. The key was the MDN article “Using CSS flexible boxes” and specifically the “Holy Grail Layout example”, which had a clear clean example of how to use flex with media queries (also completely new to me) to get what I wanted.

With only a tiny bit of fighting with IE 11, the site worked on mobile and desktop!

From there I could start growing the website design.

Next time, the development process

- Peter