The CSS isn’t easy comic by Julia Evans really encapsulates my feeling about CSS:

CSS may seem easy, but layout is a really difficult problem. Modern CSS has evolved to the point where it can very eloquently solve this problem – and it’s getting better all the time.

For those who want a deeper look at the intricacies which are involved in website layout, I recommend this in-depth look at how page layout is implemented in browsers from the Web Browser Engineering book.

When web development began, CSS didn’t provide any mechanisms for implementing layout. This is why web developers ended up misusing tables and floats to do layout. Over the years, we’ve gotten Flexbox and CSS Grid – changes that were always backwards compatible and drastically improved what we as developers can do.

CSS Containment

The CSS Containment spec has also been added to modern browsers. With CSS containment, we can give the browser more contextual information about our webpage:

• contain: layout - tells the browser that everything inside the element does not affect anything else on the page
• contain: size - tells the browser that the size of the children cannot affect the size of the element itself
• contain: paint - tells the browser that all of the visible content will be printed inside of the element’s box – anything outside of the box will be clipped

Container Queries

Because of the progress made with CSS containment, we now have the tools to implement container queries in a way that doesn’t totally kill performance. Here is the Container Queries spec proposed by Miriam Suzanne. An implementation of this spec is now available behind a flag in the Canary Release of the Chome browser.

These excellent tutorials give a good overview of what we can currently do with container queries, as well as providing some rationale for why we need them and examples of how to use them:

• CSS Container Queries is a write up on MDN by Rachel Andrew
• Container Queries are actually coming by Andy Bell
• Say Hello to CSS Container Queries by Ahmad Shadeed

TL;DR

We will be able to activate CSS containment for a specific area in our markup:

main {
  contain: layout inline-size;
}

And then we can declaratively write CSS which will only activate when our component has enough space.

.component { /* Base CSS for component */ }

@container (min-width: 25rem) {
  .component {
    /* Styles when the component has more space */
  }
}

An important key to this puzzle is progressive enhancement. We can create a minimal viable experience for all modern browsers, and then add container queries as an optional feature – older browsers will ignore them because they don’t understand them yet, but if our minimal viable experience is good enough, users won’t even realize that they don’t have the optimal experience

Other Links

If you are interested in this topic, consider checking out my other resources:

• Responsible Web Apps: My site which discusses how to create websites which are responsive and accessible out-of-the-box
• Case Podcast with Rachel Andrew: I had the privilege of interviewing Rachel Andrew and discussed – among other things – how much we all want container queries
• INNOQ Podcast: Intrinsic Design (German): A podcast where I talk about responsive design and its successor: intrinsic design
• INNOQ Podcast: Responsible Web Apps (German): A podcast where I talk about responsible web applications (covering a lot of content from the responsibleweb.app website)

I believe this was the first virtual conference that I’ve attended, and I thought that the organization was very well done. It was relaxing also to have the conference start at noon, so that I could get a few things done before focusing on the conference for the rest of the day. The talks were superb, and it try out SpacialChat and get a bit of the “conference” feeling of being able to chat with different people in the same room, even though the conference was virtual. And since the conference was virtual, without a lot of noise and visual stimuli, I found that I was a lot less wiped out at the end of the day than I would normally be.

This conference was also a new first for me personally: It was my first time rerecording a talk and then watching the recording live with everyone else AND my first time doing a keynote. My colleagues Eberhard Wolff, Andreas Maier, and I each held a short 15 minute talk as a part of a joint keynote.

In my part of the keynote I talked a lot about responsive and accessible design (or “responsible design” as I have dubbed it), and referenced my new microsite on the topic.

Since the talk was prerecorded, I was also able to sketchnote my own talk (another first)! Here is my sketchnote:

The next talk that I watched was incredibly fun to sketchnote. It was a Meta-Sketchnote, since the topic of the talk was sketchnoting in the IT. Lisa Moritz’s talk was very interactive and taught me a few symbols that I hadn’t used before. She’s currently writing a book on the topic and also has started a website displaying her amazing sketchnotes.

As part of a challenge from Lisa, I also sketched out a new symbol for a screenreader:

I find tech conferences to be a great place to listen to new ideas and hear about technologies that I’m not completely comfortable with, or that I haven’t spent the time to learn about yet. Service meshes are one of those topics that I haven’t had a lot of time to research, so I found this talk from Hanna Prinz and Jörg Müller to be just what I needed: I learned which options are currently available, and I learned which criteria I should use to evaluate the different options if I ever need to make that decision. More information is available on the Service Mesh Comparison microsite.

The next talk was also one that I decided to go to specifically because it is a bit outside of what I currently am doing in my day-to-day work. Larysa Visengeriyeva gave an overview of machine learning engineering, including the ten practices that build off of each other. More information is available on the Machine Learning Operations microsite.

My last talk of the day was some live-coding with Idris from Jan Stępień. The sketchnote itself isn’t very interesting (it’s difficult to sketchnote a talk when live-coding is involved), but the talk was very entertaining.

I did not sketchnote the keynote from Dylan Beattie, since I was more in the mood for relaxing on the couch, so my last talk of the day was from Stefan Tilkov, talking about how to create a software consultancy that people enjoy working for. I was interested in hearing what he had to say, especially because I really do enjoy working for INNOQ, and I have to say that I agree that all of the points that he made do indeed make it a pleasant place to work.

All in all, it was an enjoyable conference. The talks should eventually come out on the INNOQ YouTube Channel (although most of them (including mine) will be in German).

For my new spacing scale, I wanted to try out Modular Scale. The website provides a calculator to choose different bases and ratios to come up with a spacing scale.

I intentionally chose 1.125rem (18px) for my font size because I believe that having a larger font size than average (the browser default is 1rem or 16px) improves the readability of the site. I wanted to use this value for my modular scale as well, so I set that as my base and tried out a few different ratios to see what values they would produce. After a few attempts, I settled on using the golden section for my ratio. The full scale can be seen here.

I was already using spacing variables in order to define the different spacings on my site. I like using variables with T-Shirt size labels so that I have a limited selection of spacing values that I can use. Using the new values that I generated from my modular scale, my spacing variables (which I define using CSS properties) now are defined as follows:

:root {
  --space-xxs: 0.266rem;
  --space-xs: 0.43rem;
  --space-sm: 0.695rem;
  --space-md: 1.125rem;
  --space-lg: 1.82rem;
  --space-xl: 2.945rem;
  --space-xxl: 4.765rem;
}

Since I was already using spacing variables, modifying the CSS properties meant that all of my whitespace was automatically using the new scale.

I also wanted to be intentional about choosing font-sizes for my design which also correspond to the same scale. This is the mistake which I made with the previous design which made it look… not quite as harmonious as I would desire.

My new font sizes are as follows:

:root {
  --font-size-sm: 0.695rem; // For small text, tags, etc.
  --font-size-md: 1.125rem; // Base font size
  --font-size-lg: 1.82rem;  // For headings
  --font-size-xl: 2.945rem; // For h1 tag
}

I really like the effect on large viewports with the really big headings, but I also found that on mobile the text was a bit too large for the viewport.

To modify this, I created variable font sizes which add vw units to a base size. For instance, for the --font-size-xl Variable that I want to use for my h1 tags, I can write the following CSS:

:root {
  --font-size-xl-grow: min(var(--font-size-lg) + 2vw,
                           var(--font-size-xl));
}

Here the var(--font-size-lg) + 2vw calculation means that my font size will start out at my base --font-size-lg and add two vw units to that value. Since 2vw is smaller on mobile than on a desktop or tablet with a wider viewport, the resulting text is smaller on mobile and fits better within the viewport.

I wrapped this calculation in a CSS min function with my previous value var(--font-size-xl). This provides a clamp on the value, so that as soon as var(--font-size-lg) + 2vw is larger than var(--font-size-xl), the --font-size-xl will be used.

The min function is pretty widely supported, but I did add an extra rule in my CSS with a hardcoded value for browsers that don’t support it yet.

h1 {
  font-size: 2.945rem; /* Fallback for older browsers */
  font-size: var(--font-size-xl-grow);
}

I made a similar calculation for --font-size-md-grow and --font-size-lg-grow which I want to use for h2 and h3 tags as well.

The final variable spacings are as follows:

:root {
  --font-size-md-grow: min(var(--font-size-md) + 1vw,
                           var(--font-size-lg));
  --font-size-lg-grow: min(var(--font-size-md) + 2vw,
                           var(--font-size-xl));
  --font-size-xl-grow: min(var(--font-size-lg) + 2vw,
                           var(--font-size-xl));
}

I think this strikes a pretty nice balance in having a variable font size, but one which still is based on the same spacing scale as the other values in the design. Feel free to take a look at my about page which I use as my personal design playground to see the effect.

Instead of trying to design a static layout for one viewport and then force my content into that layout, I start by writing semantic HTML and then add a layer of CSS as a suggestion for my content so that the browser can decide what the best way to render the page.

Consider the sidebar layout which splits up into a sidebar and main content area based on the amount of space that is available.

The content which is placed in the main content area will actually have less space in the two column layout on certain viewports. When I place content (like a table) into this area, I want the table to have the ideal layout regardless of how wide my device or browser window currently is.

Consider the following table:

The width of a column is determined based on the child element with the largest content. However, when the content of a column is more important than the header and the header is the cell with the largest width, the column will take up more space than necessary, potentially squeezing the content of other columns and taking up valuable real estate.

What I want is to make the content in my table headers adjust to the amount of space available, and if there is not enough space, to show an abbreviation of the heading instead of the complete text. But if there is enough space, I want to be able to show the full column name.

Ideally, we would have content breakpoints in CSS and could do this.

Unfortunately, we do not have content breakpoints.

Because of this, I have looked into how we could do this using CSS and was inspired by the holy albatross pattern by Heydon Pickering as to how to switch content based on the width of the parent container.

My markup for this is as follows:

<span class="squishable"
      aria-label="Position"
      data-short="Pos" />

By using the aria-label attribute, the full unabbreviated text will be available to a screen reader.

I then set the content of the ::before and ::after pseudo-elements in my HTML

.squishable::before {
  content: attr(data-short);
}
.squishable::after {
  content: attr(aria-label);
}

By default, both of the texts are now visible, but what I want is to blend in one or the other based on the width that is available in the column.

To do this, I define a content breakpoint for my span as a css property

.squishable {
  --squish-at: 1.5rem;
}

When the parent container is smaller than my --squish-at value, I want to show the .squishable::before element. Otherwise, I want to show the .squishable::after element.

The trick here is to use the calc function to derive the width of the container (as I said before, this is inspired by the holy albatross pattern) and to set the max-width property.

To set the max-width property, we need our pseudo-elements to have block spacing and we also want to hide any overflow (e.g when max-width is 0 we do not want to see anything).

.squishable {
  white-space: nowrap;
}
.squishable::before,
.squishable::after {
  display: inline-block;
  overflow: hidden;
}

Now comes the magic!

When do we want to show our abbreviation? Here we can set the max-width of the ::before pseudo-element.

.squishable::before {
  max-width: calc((var(--squish-at) - 100%) * 999);
}

This works because the calculation var(--squish-at) - 100% is only positive when the parent container is smaller than var(--squish-at). We then multiply it by the 999 magic number so that it is a really big positive number and since the width of our abbreviation is smaller than this large max-width that we have set, the element will definitely be visible.

The other side of the equation is that when the parent container is larger than our var(--squish-at), the calculation var(--squish-at) - 100% will be a negative value. Because the browser converts this negative max-width to 0, this means that if the parent container is larger than var(--squish-at), the abbreviation will not be visible.

We now do the same for the ::after pseudo-element, except that now we use 100% - var(--squish-at) because this is the value that is positive when the parent element is wider than our content breakpoint.

.squishable::after {
  max-width: calc((100% - var(--squish-at)) * 999);
}

And we add just a few styles for the table to make it more responsive and make it possible for the columns headers to shrink.

.squishable-table {
  width: 100%;
}
.squishable-table th {
  max-width: 1.5rem;
}

Because I am using CSS properties, I can set the content breakpoint for my column based on the content that is in it. One easy way to estimate a breakpoint is by using the ch unit and setting it to the number of characters in the aria-label attribute. This isn’t always a good breakpoint, because the ch unit is based on the width of the 0 character, but it’s a good starting off point.

<span class="squishable"
      aria-label="THN"
      data-short="No." /
      style="--squish-at: 25ch;">

The main point is that I can set it independently and based on the content that I am putting inside of the element.

Now the width of the table we had before can be determined based on the content of the table cells and not on the width of the table header.

Here’s another table that you can play around with if you are in a browser and can change the width of the viewport. And here is the Codepen of the implementation.

I had the privilege again this year to introduce some of the talks for one of the tracks, so I also got to enjoy the company of the other organizers of the conference. The whole day was a bit crazy, but I did manage to sketchnote the talks I listened to, so here they are!

The first talk of the day was about teaching Clojure by Michael Sperbsen. I liked the point that the things that make Clojure great for expert users (e.g. simplicity) are actually beside the point when it comes to teaching programming to someone who is a real beginner.

The next talk was from Dave Liepmann, Matt Huebert, and Jack Rusher who introduced Maria, which is an interactive coding environment for Clojure. It was created for beginners in mind, but it it also pretty cool for people who have some experience with Clojure. When the conference was over, I went back to the hotel and played around with it and can confirm that the idea is pretty great. You can to go to https://maria.cloud and play around with it, and if you want to save your snippet, you can connect your GitHub account and save it as a gist.

In the next talk, Alexandrer Mann shared his experience with solving problems with logging in Clojure at CircleCI. I didn’t know that there were so many different loggers used within a single Clojure project!

In the next talk, my colleague Jan Stępień talked about structuring Clojure applications. Since every Clojure application needs to decide on an architecture, I think Jan’s suggestions make a lot of sense!

The next talk I listened to was by Kenneth Kalmer about re-frame and building single page apps using ClojureScript. I don’t actually build SPAs (feels too much like rebuilding a browser to me), but I think Kenneth did a good job of introducing re-frame and explaining how to use it. If I ever want to build an SPA, I’ll definitely give re-frame a look!

The next talk by Dom Kiva-Meyer about GraphQL was definitely amusing, since it compared GraphQL to a Japanese toilet (and really stuck by the metaphor throughout the presentation). I listened to the talk to try to understand the hype behind GraphQL (even though I am not currently using it). I think I did get an overview of the topic, but I was a bit bothered with the REST bashing that took place in the talk (REST was compared to an outhouse in the overarching metaphor). This is because I love REST (I recognize my biases), but I also didn’t recognize the listed problems with REST in my current projects. This makes me wonder what kind of REST everybody else is using. Of course, I believe the background of the talk was also the assumption that everybody is building SPAs (which I am not doing), and I can see where GraphQL could be very useful for someone building an SPA.

I really enjoyed the next talk by Lisa Passing about exploring interactive art in Clojure. It was really fun to listen to and watch, and I liked the examples of the bubbly art that you can create. Also, I learned something about probability functions and how they can be used to create ‘randomness’ that seems organic to our eyes.

The next talk was about functional calisthenics by Jorge Gueorguiev Garcia. I think the rules that he presented to practice functional programming are very interesting, although I think the one about one argument functions probably makes more sense in the context of a functional programming language like Haskell, where currying is more commonly used. Still, I think it would be interesting to try to program a kata using the rules that he listed.

The :clojureD started winding down with the comedic defjoke by Ray McDermott. Then we had the lightning talks. I definitely want to try out the Omnia REPL which was presented by Robert Avram. Saskia Lindner showed a neat tool for debugging re-frame. Juan Facorro made an argument for why we should try out Clojure on the Erlang VM. And Carolyn Stansky gave a great lightning talk about self-care in tech which I absolutely loved, because I have been trying to be more deliberate with taking care of my health.

All in all a great conference!!

The first talk of the day at the BobKonf was about by Leif Andersen, who spoke about writing DSLs in Racket in order to be able to edit video. I enjoyed the matching parentheses and each introduction of yet another DSL.

The next talk was by Stefan Andjelkovic about testing monadic programs using Quick Check and state machine based models. I thought the example was interesting and was reminded a lot about my university days doing formal methods (he even mentioned Event-B, which is the specification language I worked with for my Master’s thesis!).

I really like the next sketchnote that I was able to make. Michael Wiedeking gave a talk about data structures and explained how to create immutable linked lists, trees, arrays, and queues without sacrificing too much performance. Structural sharing isn’t new for me, but I liked the reminder and I really liked his explanation of how to create ‘Arrays’ (I think these are similar to Clojure’s Vectors) and queues.

The next talk was given by Maxim Minin about Fix Engines written in Erlang. I learned a little bit about what FIX (financial information eXchange protocol) is and the technology that is used in the stock market.

I don’t know too much about hardware, so some parts of the talk about GRiSP bare metal functional programming by Nadezda Zryanina went completely over my head. It was really cool to see live coding and the demo of the cute little robot. And it’s pretty cool that you can recompile the program and send it directly to the robot without having to hook it back up to the computer.

The next talk by Nikita Volkov was about New Hasql, which is a native Haskell Postgres driver that is faster than C. I thought it was really interesting to see how functional programming can be used in order to implement something like a database driver. Also, even though I don’t have a firm grasp on category theory (it seems to slip into my brain and then right back out), I think I understand a little more after this talks, so I will count that as a win!

The next talk was by Oskar Wickström and was about using finite state machines in programs to ensure that a program is correctly executed. This talk also reminded me of my time doing formal methods (I still like finite state machines!) and I thought the ideas behind the talk were very interesting. Also (as with the previous talk), I think I might have learned at least a little bit about category theory.

The final talk of the day was by Hannes Mehnert, and I thought it was really interesting to see formal methods used in the context of modelling network protocols. I’m glad that someone is taking the time to do it, since the whole internet depends on them working!

Since the BOB Konf has too tracks, my sketchnotes and comments are only on half of the conference. Luckily, the videos for the conference are already online (that was fast!), so if you are interested, you can check them out here.

Here are my sketchnotes from the event. I experimented with different colors and styles on the different days. I really like the bees from day one.

Day 1

Day 2

Here are my notes:

After the talk, I absolutely had to try out working with core.async channels and transducers because I didn’t know that worked!

(defn c (chan 1 (map inc)))

Whenever you put an element in a channel, the transformation in the transducer will be applied to the element before it is retrieved from the channel!

As a bonus, Mario Mainz helped me by giving me a few more tips about how to use spacemacs. I didn’t actually close it immediately!

I love open space. There is some effort involved in organizing an open space event, but the amount of value that all participants can gain from the event far exceeds the amount of effort it takes to put everything together.

I am also continually surprised by how well the open space method works.

At the beginning, we set up the marketplace. Traditionally, this consists of an empty agenda and a circle of Post-ITs and markers in the middle with a ring of chairs around the Post-Its.

Then the moderator opens the open space, telling the story of open space and how the open space event will run:

principles

1. It begins when it begins
2. It is over when it is over
3. What happens is the only thing that could happen
4. Those who come to a session are the right people

The Law of Two Feet

• As soon as you can no longer contribute something to a session or can no longer learn anything from a new session, you should leave and go somewhere else where you can contribute or learn more.

Christian got this picture of me doing the open space moderation

What always astonishes me about open space events is how well it works. In almost no time at all, our agenda was very full with amazing topics.

Keep reading if you want to see my sketchnotes from the different sessions or the flip chart pages from my sketchnote session.

Sketchnotes from the sessions

I feel like I took away quite a lot from the day. I joined some interesting discussion groups about software design bias and hype driven development, and got a short intro to Test Containers and JUnit 5. I also stopped into the Clojure session briefly just to say hi.

The topic session that I found most interesting was about Trunk Based Development. It was simply very interesting to discuss how the development process is usually different for everybody. Pretty much everybody in the room had an option about the “right way” to develop, even though we all were using Git. We all are still probably convinced that our way is best, but it was definitely eye-opening to discuss that with others. I now also know what trunk-based development is, and even though I will not be doing it myself in the forseeable future, I now also know that some people do use it successfully.

Here are my sketchnotes:

My Sketchnote Section

I also held a session about sketchnoting during the conference.

Here is a picture of me holding the session (photo cred: Benedikt Ritter (source))

In my session, I covered the why and how of making sketchnotes. Then I talked about the elements that can be used in sketchnotes (arrows, etc.) and how to use color meaningfully. Afterwards, we had some further discussion and Mattias Rottländer added to my session by teaching everybody how to draw the docker whale.

Here are my flip charts (in German) from my session:

All in all, it was a great day!

Here are my sketchnotes: