How we talk about CSS

Rachel Andrew has been working on new material for upcoming talks and she has been thinking about how CSS has been perceived in the web developer community in the past, and how we should perhaps modify our thinking about it in the future, given how far it has come.

CSS has been seen as this fragile language that we stumble around, trying things out and seeing what works. In particular for layout, rather than using the system as specified, we have so often exploited things about the language in order to achieve far more complex layouts than it was ever designed for. We had to, or resign ourselves to very simple looking web pages.

Back in 1998, when I started working with CSS, I found it to be mostly hacks and me trying to beat browsers into submission (I’m mostly looking at you, Internet Explorer). Now we have modern layout frameworks like Flexbox and CSS Grid, in addition to – as Rachel points out – many other technologies in CSS that might not be as well known. They are, however, very important.

No available space? That’s ok. Nothing is going to break. We often don’t know how much content we have, so CSS gives us sizing based on min and max content sizes, allowing items to grow and shrink into their containing boxes. […]

These features are part of the Box Alignment, CSS Intrinsic and Extrinsic Sizing, Writing Modes, and Logical Properties and Values specifications. These specifications tie together the individual layout methods into one system, with various methods to create the type of layout we need to see.

While there’s still much that is left to be desired, the technology has come such long way in just a few years. My day to day work has shifted significantly, from trying to make browsers jump through hoops while using CSS in ways it was probably never intended for, to actually letting me work more creatively.

One of the challenges over the years has been to communicate the importance of the frontend designer role. CSS is often seen as a “semi-language”, lacking features (interestingly such features that programmers often find useful), and would best be replaced with something else. This might be why we ended up with things like CSS-in-JS, convoluted preprocessor languages and insanities like CSS modules.

There is frequently talk about how developers whose main area of expertise is CSS feel that their skills are underrated. I do not think we help our cause by talking about CSS as this whacky, quirky language. CSS is unlike anything else, because it exists to serve an environment that is unlike anything else.

I agree wholeheartedly with this. But I also think that not appreciating how powerful CSS is, and instead turning to convoluted tooling to solve non-existing problems, is not helping either. I fear that when developers refuse to learn about the core strengths of CSS and instead utilise tools that are based on misunderstandings of how CSS is fundamentally working, that becomes a problem. The work that people like Rachel are doing is very important and I’d hate to see that be undermined. I suppose time will tell.

Getting JSON Feed in Jekyll

With regard to the previous post, here’s how I cooked up a Jekyll template for JSON Feed:

layout: null
  "version" : "",
  "title" : "{{ site.title }}",
  "home_page_url" : "{{ site.url }}",
  "feed_url" : "{{ "/feed.json" | prepend: site.baseurl | prepend: site.url }}",
  "author" : {
    "url" : "",
    "name" : "Fredrik Frodlund"
  "icon" : "{{ "/apple-touch-icon.png" | prepend: site.baseurl | prepend: site.url }}",
  "favicon" : "{{ "/favicon-32x32.png" | prepend: site.baseurl | prepend: site.url }}",
  "items" : [
  {% for post in site.posts limit:10 %}
      "title" : {{ post.title | jsonify }},
      "date_published" : "{{ | date_to_rfc822 }}",
      "id" : "{{ post.url | prepend: site.baseurl | prepend: site.url }}",
      "url" : "{{ post.url | prepend: site.baseurl | prepend: site.url }}",
      {% if post.external-link %}
      "external_url" : "{{ post.external-link }}",
      {% endif %}
      "author" : {
        "name" : "Fredrik Frodlund"
      "content_html": {{ post.content | jsonify }}
    }{% if forloop.last == false %},{% endif %}
  {% endfor %}

It’s a pretty quick and dirty port of my feed.xml template, but it seems to work. You can get the above code snippet directly on Github as well, but the syntax highlighter doesn’t like the YAML front matter and Liquid template tags too much, so it looks a bit ugly.

Update (2017-05-19): I’ve updated the code snippet a bit with more Jekyll tags for a more dynamic solution (like site.url and so on). Liquid template offers a great filter called jsonify that I’m using wherever applicable.


Brent Simmons and Manton Reece:

We — Manton Reece and Brent Simmons — have noticed that JSON has become the developers’ choice for APIs, and that developers will often go out of their way to avoid XML. JSON is simpler to read and write, and it’s less prone to bugs.

So we developed JSON Feed, a format similar to RSS and Atom but in JSON. It reflects the lessons learned from our years of work reading and publishing feeds.

My inital reaction to this was “But, why?” Then I read the spec, which is really nicely written for us humans, and I realized that JSON really is very prominent in many tech stacks these days. So, why the hell not?

Just for fun, I decided to spend ten minutes to try and implement a JSON Feed of my own for (might be full of bugs). Looking around the web now, a lot of people seem excited about this new spec, so why not jump on the bandwagon early this time?

That whole “blog” thing

In the beginning of March, I blurted this out in pure frustration on Twitter:

Then, a few weeks later, a gentleman named Paul Lloyd tweeted:

Great minds think alike, yes? 😉 Jeremy Keith shared our view as well. I think this is great for many reasons. For my own part, I created this blog (or journal as I so “hipstery” chose to call it) just to have something fun to tinker with all the time. Plus, I really wanted to get in on this whole static site generator craze everyone was talking about. As a side bonus I got to learn and refresh a whole slew of skills, like setting up and securing a server on Digital Ocean, making build scripts that trigger when I push to Git and more. It’s plenty of fun and it allows me to play with things that I don’t always necessarily get to do at work.

There’s more to it, though. Someone once said that owning your content is a pretty good thing. I’m sad to say that I can’t remember who said it, but it’s a good thing nevertheless. I honestly can’t understand why some great authors chose to publish on Medium, but to each his own, I guess. Reading stuff on Medium is fine, I suppose. Still, their highlighting feature is really weird and distracting.

In any case, my initial tweet on the matter was borne out of frustration. I was frustrated that people that had great and interesting things to say chose to chop it up in 140 character bits and streamed it intermixed with other people more or less useful thoughts. Threading on Twitter is horribly broken at times and if you instead chose to publish your thoughts on something more user friendly than a Twitter thread (and hey, you can always tweet about that post afterwards), then I salute and thank you!

Keep posting great stuff, I will keep reading it and share it with others.

No more prefixing

As I was tinkering with the code for this site, as one does on a Sunday afternoon, I came to realise that I hadn’t done some proper, old-school browser testing in Internet Explorer for a while. I had been doing a lot of refactoring in my gulpfile.js and exchanged some packages for others, most notably the package for minifying my CSS. I had been using gulp-cssnano for quite a while without giving it any thought (I can’t even remember which package I had use prior to that one).

Opening the site up in Internet Explorer 9 on Windows 7 revealed that a few things like font declarations didn’t work at all and after some debugging it turned out that cssnano was indeed the culprit. I didn’t delve too deeply into the cause of the issue, but instead ended up switching to gulp-clean-css, since it did the same thing without breaking IE compatibility. Good enough!

While debugging in IE, something else did catch my eye, though. Man, there sure is a lot of prefixed properties in here! Most of them was for flexbox, which I’m only using on a few places like the footer and the main layout to get a sticky footer on pages with less content. Dropping these would mean that IE 10, to name one, would not get the same slick layout (well, slick-ish, you know…) as modern browsers. And you know what? That’s just fine. The upside was that I got to trim away a few packages in my node_modules folder, not to mention that I got to delete a few extra lines in my gulpfile.js. That felt really good!

I did some checking and since I use display: inline-block; on elements that normally would be flex-items in supporting browsers to at least get them to appear next to each other, things looked pretty ok. Nothing looked too broken and all the content was fully accessible.

So what am I getting at with all this rambling, then? Well, most vendor prefixes are on their way out the door and to my knowledge, new prefixes are not coming in anymore. If we just apply some progressive enhancement thinking to our CSS as well, we can cut down on complexity in our tool stacks (and you know that’s normally not a thing these days!), plus we’re also cutting down on the amount of code our users are downloading.

Almost all major browsers are evergreen today and feature support is rapidly progressing across the board. Vendor prefixes was an unfortunate hiccup along the way, that got picked up by developers and misused. It’s time we left that stuff behind us.