Skip to content


Everyone who knows me a bit better, should also be aware that I’ve always had a strong interest in food and everything related. After getting mad about my growing collection of notes, I decided to put these in order with the help of a Kirby-driven website. It was supposed to be a protected website, just acting as some kind of personal notebook for me. For the sake of forcing myself to keep things simple, I decided to edit everything directly on an Uberspace using only nano through SSH as an editor. And everything was just fine!

But somewhere around mid 2018, I thought about making things public. At the same time, I was also seeking for an opportunity at the time, which I could use for growing my drawing skills. Avo is a humanoid raven character, which I had already ideas about, and I wanted to give im a chance and put im into action. And so the name Avo’s Kitchen was born. I decided to write everything in my native language German, because it felt a lot more natural to me, when writing about cooking. Especially since I’m doing this for the first time in my live for a broader audience.

A lot of things happened in the meantime, some of them stopped me from working on the project for several months in a row, but in the end I finally wanted to put this thing online, though sadly with way fewer recipes, than I had planned for in the first place. The main reason for that is, that I’m lagging behind in taking decent photographs of many otherwise ready-to-publish recipes. I’m still working on my studio setup and on collecting some props, but this takes time, because this is more or less still a side-project. And many other important things take precedence over spending hours in an unheated photo studio during the wintermonths, cooking and photographing food.

But it’s still really relieving to put this thing out there and being able to publish things on the blog, which has – thanks to a great collaboration with Sebastian Greger – sophisticated and privacy-friendly comments and webmentions functionality. And yes, Avo’s Kitchen also features a monospaced font for body text! 🤘

Please head over here into the Kitchen:

Visit Avo’s Kitchen

Every now and then, every dynamic website needs a little overhaul. And in late 2020, it was about time for this site. Though I’m still pretty happy with the design, the backend needed a bit of love. The whole thing was still stuck on Kirby 2, whereas Kirby 3 has almost been out for 2 years and the old version has almost reached the end of its life.

I hesitated for quite some time, though I knew that I would finally have to give up a lot for going down the inevitable path at some point. But there where some things that kept me from finding the motivation for doing this update.

For instance, I had written the ImageSet plugin, wich provided fancy placeholders allover the site and also Kirby Typography, which enhanced typography a lot by providing fine-grained control over hyphenation and so on. TL;DR: The site had gathered a lot of technical debt over the years and also my portfolio was very outdated. And if I know one thing for sure: Content is still king and one should spend more time on that, than messing around with code.

Speaking of code, the CSS codebase of this current design revision has been growing for a bit more than 5 years now, so it has collected a lot of dust. It also looks kind of messy after all these little changes, and I still got a strong desire to start from scratch. At least, I’m a frontend developer and thus always afraid that somebody else with the same profession could have a look into my source code, which would be embarrassing. But you know what? Content is still far more important and the frontend code of this website has been working pretty fine so far. So I’m keeping it, until I will probably retire the whole site design in a couple of years.

Instead, I updated only the necessary backend part and spent more time on updating the portfolio, tweaked a few things like image sizes and adding some drop shadows behind images (to separate them better from their background). I also added a comment funktion to blog posts, because I always felt that it was lacking.

Stay healthy!

When I started a personal blog project about two years ago (still in progress to as of today), I was thinking about ways about how to handle user feedback from the very beginning. Solutions like Disqus where out-of-question from the very beginning, since I am always trying my best to play fair with my visitors – and their data. In the end, a self-hosted solution promised to be the best thing I could have to accomplish my privacy-goals.

But which one to pick? I tested a lot of different things, but I did not feel comfortable with any of these. Mostly, because they are written in programming languages that I don’t speak and require an additional database to back-up. In the end, most of these solutions would just be another black box in my stack. I even thought about just letting people submit comments by sending me an email, like LOW-TECH MAGAZINE does it. Although people keep telling me, that blog comments are mostly dead, I found quite the opposite to be true – at least for some topics.

After I could not find any viable solution, I got in contact with Sebastian Greger last year, as he was developing an interesting solution for Kirby, which also included support for receiving webmentions – in addition to comments. But because life is made of more than writing code for fun, our joined efforts did not take off until somewhere around April 2020. What I really liked from the beginning was Sebastian’s ethical approach to software design and development. While my role was mostly about coding, we had numerous discussions about privacy, ethics and the IndieWeb movement in general. He also wrote a very extensive blog post about his process of developing the commentions-plugin.

I’m very happy with the result, not because the code or architecture is the most elegent piece of code I’ve ever seen (although I think that it’s not too bad), but because of the philosophy that has been a strong guideline throughout the project. Okay, this is software, so it will probably never be finished. ;-) But for now, we have reached RC 1.0.0 and it should work fine enough to give it a try!

Commentions-Plugin on GitHub

After adding a print stylesheet, I tried browsing my upcoming cooking website using both VoiceOver and the text-based browser lynx. If you thought, different implementations of Flexbox and Grid bugs or optimizing for IE 11 are frustrating, try out browser features, that are less in the spotlight, but have a high impact on the accessibility of your site.

Wanna print that?

Before you start making fun of me, because I added a print stylesheet to a website in 2019, let me please explain why I did it at all. You might think, the time where corporate bosses where smoking cigars in their offices while their secretary printed out every email for them are mostly over. And I really hope, you are right with that assumption. But there are some exceptions, where people use to print websites quite often: Invoices, cooking recipes, event tickets, technical manuals or gift vouchers — to name just a few. As I am currently working on a cooking website, having a good print stylesheet is still worth it in 2019 without any doubt. It’s probably more important for most of your users, than using some fancy markup such as or Microformats to make the recipes machine-readable and thus importable into a digital recipe manager.

Writing a relatively simple print stylesheet took me the better time of two whole days, because the state of print support in browsers is almost as bad, as it was about 10 years ago. Okay okay, we don’t have to make our pages print nicely in IE 6 any longer, but besides that, things still work differently from what we are used to, when using modern CSS. Do you use flexbox for implementing a sticky footer even on short pages, where the screen becomes much taller than your content? Congratulations, Firefox (v66) will only print the first page and nothing beyond it. Grid is also inconsistent across different browsers, so you can neither use that for defining your layout. Both Flexbox and Grid are fine for smaller sections, though. But you gonna have to use <table>s , floats and absolute positioning again, if you want to do just a bit more than having a centered text block on your printed page. Oh, and don’t even think of using mask-image or your masked elements will not get printed at all. The latter one is obviously a bug, but I’m sure almost no one is aware of that behaviour.

The only positive aspect of the current situation — namely, that browsers vendors don’t care enough about printing websites — is, that you can safely rely on older articles and tutorials, that have been published a decade ago and most of the tips given there are still valid for the latest and greatest browsers. I can also recommend reading Designing For Print With CSS, which was published in 2018 by Smashing Magazine and is a good starting point to get into the topic. But as always, try to test with as many devices and browsers possible, if you’re expecting a decent result.

Link: Learn more about screen readers SINGLE RIGHT-POINTING ANGLE QUOTATION MARK

Screen readers are a different topic though. While not every website needs to be printable, we should try our best to make websites accessible. Bonus: if you’re using aria-* attributes a lot, it can save your HTML from classitis, because every browser beyond IE 6 allows you to hook into these attributes for managing things such as states, plus displaying and hiding of content, without the need of using additional class names as styling hooks. As aria-attributes are not project-specific, you don’t have to remember different naming conventions for states (e.g., .btn.isActive, .btn--is-active etc.) over and over again.

So I fired up VoiceOver on my MacBook to read throught the page and ended up with many awful-sounding text like in the headline above. But Fabian, haven’t you thought of that before? Yes I did! I though that using aria-hidden, aria-label and other properties would make my page just sound fine in any screen reader, but aparently I was kind of naïve. After googling about these issues for a while, it turned out that support for aria-attributes is much worse and inconsistent, than I could ever imagine. I stumbled across four years old unresolved a11y bugs in Blink, Gecko and WebKit and couldn’t stop to bang my head against the wall after that. How in the world could an average developer be able to deal with this? Seemingly, the most prioritized goals set by browser vendors are not found in the field of accessibility. But hey, we got WebUSB (at least in Chrome)!

But what really makes me mad about the situation is, that we are leaving people out, because we don’t seem to care enough. And in comparison to making a sticky footer and test it across all relevant browsers, testing different screen readers doesn’t come for free. I’m using macOS, so VoiceOver was already installed on my computer, but some competing products have to be bought separately. And most developers will never/are not able to spend hundreds or even thousands of Euros for testing e.g. in JAWS, which seems to be a popular choice. I cannot blame anyone who does not want to spend the price of a decent notebook computer for a software, they just use for testing their websites. The only thing that will help here, is to have diverse teams, including visually-impaired or blind members, who use screen readers on a daily basis. But to be honest: that’s not realistic for every (small) team or freelance developer. Nevertheless, we should never treat people with disabilities as an edge-case.


Okay, we’re getting ridicoulous here (who uses text-based browsers in 2019?). But I once read the tip to use a text-based browser such as lynx or w3m to test accessibility. Why? Because a text-based browser sees only text, which is similar to a search engine and — more important in this context — a screen reader. Okay, let’s go: Special chars broken? No problem — set document encoing to UTF-8 (and don’t forget to save settings to disk). Ahh, here comes the real trouble: Lynx has awfully bad support for HTML5, which results in links not being selectable, once you place a block element like a <div>, <h2> or <figure> within them. Also, don’t expect handy attributes like hidden to work in lynx or any other text-based browser. But besides that, you can still get some insights into how you pages will be read by a screen reader and without any JavaScript. I hope, these browsers will finally catch up and get basic HTML5 support one day. You might wonder, why I even care? Because I want the web to be accessible for everyone as many people as possible. Text-based browsers are especially great when being logged into a terminal, when browsing from a remote location without a broadband connection or after disaster, when your connection speed feels like it’s 1998. You might say: »But these are edge-cases …«. You will keep call them edge-cases only as long as long as you’ve never found yourself in such a situation. There’s a reason, why CNN Lite exists. It’s for the sake of giving people access to news, when they need it the most.


In the end, we need better standards and more consistent implementations between browsers! The device landscape has become pretty diverse over the last years and that’s a great thing. But as a Firefox user on desktop with an iPhone SE on-the-go, I am already experiencing the struggles of designers and developers of keeping up with that first-hand. There have been several times, when a mobile website was not optimized for my smartphone, because everyone assumes that smartphones have bigger screens nowadays. This often leads to overlapping elements, unclickable buttons (nice if you cannot close that damn cookie banner to access the content). When I’m one the bus, I am seeing a lot of people using exactly the same phone as I do. I wonder, if they are as much frustrated as I am. When other designers ask me what canvas size to use in Sketch for the mobile layout, I always tell them to use the iPhone 5/SE screen size, because its relatively small. On the desktop-side of things, I don’t want to count how many times I had to switch my browser, because some jerk did only test a website in Chrome, but not in Firefox (or Safari or Edge). We can do better and we need to do better, if we want the web to become a better place for everyone — sometimes at the cost of our developer experience. Testing websites in many browser across different screen sizes is annoying as f*ck, but we owe it to anyone using our products. But we also need browser vendors, the W3C, screen reader vendors and anyone I possibly forgot to mention to work better together. Responsive design is already hard enough without all the inconsistencies that we have to deal with on so many layers. If we want to give everyone a voice on the web, that can be heard (or read) by anyone else, the plattform has to be capable of letting everyone create accessible websites and content without calling licenses for a ton of proprietary software their own.

PS: Don’t forget to test your websites in older browsers, even if it sucks to do that. Sustainability also means, that you should not force people into upgrading their devices, just because you’re lazy. Look around you, there’s a ton of people using old Android and iOS devices (the latter ones often running on iOS 9 or 10. iOS 9 means no support for CSS grid.). They may not have the money to buy a new phone or tablet, but maybe they also just don’t care, as long as their current device does its purpose just good enough. That doesn’t mean, that every CMS backend or intranet tool has to be compatible with an 8-years old iPad, but try at least to keep the frontend of public websites and online communities accessible to people, even if it does not look as fancy in their browser. Progressive enhancement and graceful degradation are your strategies of choice.

Video summary: We were supposed to build a better world. Design and technology were supposed to point the way towards utopia. Instead, we designed a nightmare. Find out why this was our fault and what you can do to help fix it.

I started learning how to code websites around 2000 – that’s almost 20 years ago now. Back then, I was only 13 years old and pretty excited about the future of the web and all the marvellous opportunities that digital technology promised to open for humanity. But in 2018, the web and the whole digital tech industry has lost a lot of its shine for me.

When I first attended to the Beyond Tellerrand conference last year, I felt a different vibe than this year. Although all the scandalous behavior of secret services and tech oligarchs in terms of surveillance and abusement of power was already well-known and has been discussed for some years now, the overall mood seemed to be much more positive and uncritial than now. I remember some discussions about Tesla’s latest car models, iPhones and stuff. And that’s okay of course, the latest technology has an important impact on our work at least. But this year, I got the impression that technology was discussed in a much more critial manner and I am really welcoming that. Some announcements about new tech during the last years already started to alienate me, because they often lacked any critical reflection on the topic or product by our community. But as the web industry matures and everyone can see the devastating effects of e.g. social media services being exploited by fascists we really need to talk about ethics — better sooner than too late! Although it might feel annoying sometimes; we must realize that being unpolitical about our work is not an option any more (has it ever been?). The web is not an isolated echo chamber and everything we build has an influence on the life of real people.

Mike Monteiro’s great talk reminds us that we cannot affort reducing ourselves to being mere service providers for building an apocalyptic future any longer. We are human beings at first, not designers, developers or engineers. We are more than just two hands with a bank account! And we do have a choice who and what we want to work for.

Loading ...