Fabian Michael’s Blog https://fabianmichael.de/blog Kirby Mon, 06 May 2019 00:00:00 +0000 The latest updates from my blog Accessibility Blues https://fabianmichael.de/blog/accessibility-blues blog/accessibility-blues r 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 Schema​.org or Micro­formats 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 imple­menting a sticky footer even on short pages, where the screen becomes much taller than your content? Congra­tu­lations, Firefox (v66) will only print the first page and nothing beyond it. Grid is also incon­sistent 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.is-active, .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 incon­sistent, 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 acces­si­bility. 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. Never­theless, we should never treat people with disabi­lities as an edge-case.

lynx https://​fabian​michael​.de/en

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 acces­si­bility. 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 imple­men­tations 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 experi­encing 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 smart­phones 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 incon­sis­tencies 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. Sustaina­bility 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 commu­nities accessible to people, even if it does not look as fancy in their browser. Progressive enhan­cement and graceful degra­dation are your strategies of choice.

Video Recommendation: How to Build an Atomic Bomb https://fabianmichael.de/blog/how-to-build-an-atomic-bomb blog/how-to-build-an-atomic-bomb r 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 oppor­tu­nities 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 announ­cements 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 devas­tating 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 apoca­lyptic 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.

Campire Scene Print https://fabianmichael.de/blog/campire-scene-print blog/campire-scene-print r After a long break, I finally took the time to work on a new screen print. Though I have kept on drawing for the better part of the year, I haven’t done any printing (my inkjet does not count …). It almost felt like a shame to have brand-new screens and inks just catching dust in the corner without actually making good use of them. But now that the first test-run has been successfully completed, I’m looking forward for many more to come.

The workshop still needs a lot of love, because the primary focus of artge​rechtes​.de has been on producing organic/​fair-​trade fashion and thus the workshop is optimized for printing on clothes in high editions. Establishing the capabi­lities for handling paper still needs some more equipment to make the process somewhat more effective, but at least the foundation has been laid. My next project will be to improve the printing table.

If you’re interested in buying one of the print shown below, just send an E-Mail to hallo@​fabianmichael.​de or info@​artgerechtes.​de.

Another Year, Another Revision https://fabianmichael.de/blog/another-year-another-revision blog/another-year-another-revision r In my opinion, personal side projects are always a great way for trying out new things. However, the downside of that is always tht it takes a lot of time. As more of my work shifts towards design and conception, keeping up with the latest web techno­logies is often more than just a trivial side-task. Though I think that my CSS skills are quite good, JavaScript nowadays often feels a bit like rocket science to me. But that’s okay somehow in an industry, that constantly shifts towards more complex products and thus needs more specialists at some points. On the other hand, being a designer with some decent knowledge about web techno­logies is never a disad­vantage, especially not since the day we started to design responsive websites. But I guess the hardest thing to learn when working on personal projects, is how to cope with the non-existent deadline. I would say, the best result would be to end up with something between the minimal solution to accomplish your goal and that fancy result that tops everything comparable you had ever seen before. In the end, you should get something you can feel comfortable with and that suits your needs.

After finishing the overhaul of my website, I am happy to finally have a platform that fits my requi­rements better than ever before. When deciding to have a portfolio or a blog, there are a lot of things to consider. Eventually, everyone’s got his*her own way of writing or showcasing his*her work. Some people prefer colored, indivi­dually designed project pages, others prefer a rather plain gallery grid where they throw in a bunch of images and maybe videos. There is no right or wrong, it really depends on your content and in which way you want to prepare it for your portfolio or your blog. But finding that out can be another journey, which takes time and practice.

For projects pages, I kept the rather minima­listic approach of having two content areas, one that is primarily intended for putting images into it, but it could basically hold every type of content. The other one is the so-called Meta area, where projects infor­mation can be found. I also designed a new navigation, which allows me to add more menu items, if there is a need for that. The headline font Abril Fatface Bold Italic has been replaced by GT Sectra Bold Italic, because I started to feel that Abril Fatface – though it’s a beatutiful font – did not complement the archaic monospace theme of the site very well.

Talking about technology: I finally I got rid of jQuery in favor of vanilla JS. It was a lot of awful work, but I learned a lot and used the room to experiment on animations, transitions and special link underlines. I am very happy with a total of static resources of roughly 150 kB (includes font files, JS and CSS gzipped). I think speed is a core feature of each contem­porary website and should never be treated as a low-priority task in any project. I’m already excited about the new projects I will publish in the coming month and about the stuff I will write here.

The Void https://fabianmichael.de/blog/the-void blog/the-void r ]]> Marina T-Shirt https://fabianmichael.de/blog/marina-t-shirt blog/marina-t-shirt r Das Marburger Bekleidungs- und Siebdruck-Kollektiv Artge​rechtes​.de existiert seit knapp zehn Jahren und handelt ausschließlich mit fair und ökologisch gehan­delter Bekleidung. Gedruckt wird dabei komplett in Handarbeit in der eigenen Manufaktur. Ich freue mich, unserer erstes gemeinsam entstandenes T-Shirt präsen­tieren zu dürfen!

Das gute Stück mit dem Titel Marina kann absofort online bestellt oder direkt bei Artge​rechtes​.de im Laden gekauft werden.

T-Shirt kaufen

ImageKit for Kirby https://fabianmichael.de/blog/imagekit-for-kirby blog/imagekit-for-kirby r I’m proud to release the first public beta of my ImageKit plugin for Kirby today. Although the plugin may seem simple at first glance, this has been a long ride. It started about 2 years ago, when I was using WordPress for my private blog. Unhappy with the built-in thumbnail API, I decided to go for something better. After the work on my WordPress plugin was almost done, I switched to Kirby and decided to start from scratch. The plugin grew very quickly and became some kind of monster, including everything from a widget to an extensive image component with support for lazyloading.

After the large amount of API changes, that came with Kirby 2.3.0, I had to adapt a lot of my plugin’s code to keep it working. So I took only the best parts of it and decided to go for a more modular approach this time. Today, I released the first component – the asynchronous thumbs API – on GitHub. I also decided to make ImageKit a commercial plugin, so I will hopefully be able to provide better support for it. 

I’m excited to hear your feedback and hope you enjoy ImageKit!

Why I Switched from WordPress to Kirby https://fabianmichael.de/blog/from-wordpress-to-kirby blog/from-wordpress-to-kirby r I have to admit at this point, that I didn’t follow any proven method to get this project finished, it was rather created by playing with design and code. Usually, I tend to use Photoshop (yeah, I’m kinda old school sometimes) for web design, because I think that designing in the browser makes me see the design too much from the technical perspective, which limits my creativity. But in this case, It was completely clear that I wanted to have something that uses a monospace font and the least amount of decorative elements as possible. So designing with code seemed to be an acceptable option in this particular case.

Why I Had Choosen WordPress

Overcoming Limitations

Almost everyone has heard of WordPress and every web designer probably knows that it is a CMS software with a strong focus on blogging. I switched from REDAXO to WordPress the day I discovered the Advanced Custom Fields (ACF) plugin, because it allows the developer to create custom forms for different types of content. When I designed a my bachelor thesis using InDesign (2011), I was wondering all the time: »Why do most website layouts look so boring compared to print?« While there was and is no universal answer to this question, I think it is connected to the design of our technology. For example: The typical WordPress template only had a single content column at that time or used some ugly worka­rounds to create additional content areas like a header slideshow. But with ACF, WordPress becomes a very versatile system, that can surpass those limitations.

The Ugly Parts

Compared to other CMS software, the community of WordPress developers is rather large. In most cases, it’s easy find a solution for almost every question or problem you have when developing a website with WordPress. There are a ton of plugins, widgets, snippets and themes at your fingertips, but sadly, the quality of those resources varies a lot.

While I really like the admin panel’s interface design and how fast it is keeping up with by imple­menting tidbits like drag-and-drop upload of image files or support for High-DPI screens, there are — on the other hand — a lot of downsides about WordPress:

  1. Image Resizing: WordPress resizes images only on upload by default. This might have been a good-enough solution in the days of desktop-only websites. But nowadays in the age of responsive design, there is a need for a lot different-sized versions of every image. For example, this site has roughly 3 – 4 sizes for every image file plus a High-DPI-version for each of those.1 It is possible in WordPress to define additional image sizes, but if you do that, uploading an image easily takes 30 seconds or more, which makes editing a pain in the ass. Additionally, a lot of those resized images are never used and only eat space on your server. If you change one of those sizes or switch to a different theme, you need an additional plugin to recreate all resized images.
  2. i18n: There is no support for multi-language websites out of the box. This can be fixed by … guess what? Another plugin! I used WPML, which works somehow, but is neither pretty nor free. And it also adds a meta tag to your frontend code, telling its version to the client without asking.
    Though the admin panel of WordPress is available in a variety of languages, choosing anything else but English comes at the cost of a heavy performance drop.2
  3. Security: Due to the fact that WordPress is the most popular CMS software, it also attracts a lot of attackers. This forces you to update it very frequently. And also, WordPress includes its version by default in a meta–tag, which makes it even easier for some assholes bad guys/​girls, to hack your site.
  4. Bloat: Using WordPress always feels like using bloatware. In a recent release, it startet to include some JavaScript-Code on every page for Emoji-support. While this may be nice for some blogging-contexts, for most users this is certainly unnecessary. Also, almost every plugin you install loads another JavaScript and CSS file on every page. You can tweak those things here and there, but it does not feel right to include a lot of code into your functions.php3 to turn off features, instead of enabling them.
  5. Performance: Well, this results in the most awful thing about WordPress: its poor performance (especially when keeping in mind that is used by a lot of hobbyists who are on cheap hosting plans). Sure, there are a lot of caching plugins, whose settings pages often contain dozens of optionas and seem to be overly complicated. I know WordPress very good and I still don’t get how exactly most of those plugins work — if they work at all. For every page request, WordPress initializes a lot of stuff I never use, from widgets to comments. On shared hosting, the server’s response time often exceeds 500 ms.

Final thoughts on WordPress

While the preceding lines may sound like a rant, I don’t hate WordPress. When I was studying Design, I gave tutorials to other students and taught them how they can make their own portfolio with WordPress using custom themes. And while none of them had ponderable experience in programming, most of them were able to achieve good results in comparably short time.

I think, the problems listed and described above are resulting from the fact, that WordPress ist just made for a different group of users. Although, Automattic (the company behind WordPress) makes money with their hosted platform WordPress​.com. Obviously, the software follows their business needs, which may differ from my needs and my philosophy as a web designer/​developer doing client work.

Hello Kirby

Because of the reasons listed above, I had been searching for an alter­native to WordPress for some time already, when I finally stumbled upon Kirby. The philosophy behind the CMS could be described like the complete opposite of WordPress in many aspects. When setting up a project with it, one does realize very quickly: Kirby is not for everyone. To work effec­tively with the software, you need at least some basic programming skills in HTML, CSS, PHP and probably in JavaScript. While WordPress tries to provide as much as possible without touching any code, Kirby acts more like a boilerplate or framework, intended as a solid foundation for your website. There is no real default theme, just a simple demo site, which serves as a starting point.

Never­theless does it provide a nice and clean API, which looks similar to jQuery. Whenever you’re working on a typical website for a small company, this allows you to stay focussed on your design and your frontend code. Synchro­nizing with a staging server is also quite easy, because there is no database you need to take care of. Everything is just stored in a folder structure. In my daily routine, this became very handy, because editing can be much faster sometimes, if you open content files directly from the Finder (or, if you’re a command line hero, you can use nano or vim). For sure, there is also an admin panel, you can use!

Custom Fields for Custom Websites

Except for a page title, there is no mandatory field for any page in kirby. The fields for every template are described in so-called blueprints. That means, you can, for example define title, text, thumbnail for a portfolio page or title, text, publishing date and excerpt for a blog post. This allows great flexi­bility, although it is not so advanced like WordPress in conjunction with ACF. But in most cases, it will suit all your needs. There are also fields for repeating content, if you want to implement a slideshow or something else more advanced. My approach changed from striving for a layout builder to fit every use-case to customized templates for particular content pages.

When it comes to content-editing, Kirby is not too opinionated and allows you to choose between a bunch of different options. I bet most Kirby users prefer Kirbytext, an extension of Markdown with additional and completely custo­mizable tags, so-called Kirbytags. IMHO, the best writing experience is achieved when installing the Visual Markdown Editor plugin, which provides a decent interface for editing. But If you prefer, there is also a WYSIWYG editor available.

Exten­si­bility & Confi­gu­ration

Kirby supports multi-language websites out of the box, so there is no need for an additional plugin for this case. The included field types reach from a simple text inputs to select boxes, date-pickers and many more. There are also a lot of additional third-party fields available. All in all, there are far less plugins available, than for WordPress. As the current version (2.2) does not support custom admin pages yet, confi­gu­ration happens mostly within a confi­gu­ration file. Another handy feature at this point: You can have a global confi­gu­ration file and specialized ones for your test server and your production server, which are automa­tically loaded depending on your site’s domain name.

Performance & Caching

One of the most stunning »features« of Kirby is it’s amazing performance. A simple page only needs a couple of milli­seconds, a more complex page like this one is still delivered in under 200 ms on my local machine. If you turn on page cache, it becomes even faster, almost like serving static HTML pages. Within the last years, performance has been a big topic within the web designer/​developer community. How much can the »best« website be worth, if a slow CMS lets your users have to wait several seconds for a page to load?


I am a big fan of using tools, that empower people who publish content on their own webspace to keep make the web as decen­tralized as possible. If you visit the website of Kirby’s creator Bastian Allgeier and read his thoughts, you notice that he has a similar attitude towards the evolution of the WWW, as I have. While a self-hosted WordPress site fulfills the same demands, I prefer the structure of Kirby which doesn’t lock you in. Everything is stored trans­pa­rently, so you are able to move your content to another platform without too much hassle.

Writing frontend code for responsive websites is already complicated enough, so if you’re a typical web designer — with some decent knowledge about how to code — a CMS like Kirby allows you to stay focussed on the things that really matter to you (…and which are probably design and frontend code). The documen­tation is still in development and could be more complete, but as far as I know, the team behind Kirby is constantly working on this. I am very excited about the developments we are going to witness within the next months and years and which direction Kirby will go. For every upcoming project, where I think Kirby is suitable for, I’m going to suggest it to the client as Kirby is now my CMS of choice.

Last, but not least: Creating and editing websites with Kirby made web design and especially development an enjoyable task for me again. It always feels like I am in control of what I am creating. when you look at Kirby’s showcase, you see a lot of great websites. Most of them feel like developers and designers enjoyed the process of creating them as I did with this site.

  1. I serve retina-optimized versions of all images with a higher compression, than the "regular" version. On high-density screens, pixels are so small, artifacts are harder so recognize, so JPEGs can be saved at lower quality to save lots of kilobytes, resulting in faster websites — especially on mobile.
    Further reading:
    Daan Jobsis (2012): Retina revolution, Scott Jehl (2012): Compressive Images, Hugh Spiller (2012): Can bigger images be smaller? 

  2. WordPress uses gettext for trans­lation. That means, that the original language strings are included directly into the code. I compared the performance by changing the interface language: When set to German, page generation became much slower, while gettext took about 30% of total script execution time. 

  3. In every WordPress theme, there is a file called functions.php. This file usually contains a mix of theme-specific confi­gu­ration instructions combined with additional theme-specific template functions. 

Neue Visitenkarten https://fabianmichael.de/blog/neue-visitenkarten blog/neue-visitenkarten r

Seit dem Wochenende habe ich endlich neue Visiten­karten. Danke an Studio Akkord für den Druck!


Vorderseite Rückseite
Gmund Cotton New Grey, 300 g Gmund Colors 63 Matt, 100 g
Letterpress, 1-farbig Siebdruck, 1-farbig
Lesbare CSS-Klassen durch Trennzeichen https://fabianmichael.de/blog/lesbare-css-klassen blog/lesbare-css-klassen r Bei der Arbeit an Websites gibt es mehrere Möglich­keiten, den CSS-Code zu struk­tu­rieren. Während ein Ansatz darin besteht, möglichst nur eine Klasse pro Element zu verwenden und alles Weitere im Stylesheet zuzuordnen, besteht ein oft gebräuch­licher Ansatz darin, mehrere generische Klassen pro Element zu verwenden. In diesem Artikel geht es darum, wie der Ansatz mehrerer Klassen möglichst übersichtlich verwendet werden kann.

Warum mehrere Klassen pro Element?

Ein typisches Beispiel für eine Klasse pro Element in BEM-Namens­kon­vention:

<article class="article">
  <div class="article__content"></div>

Für einzelne Widgets mag das vollkommen ausreichen, sobald aber Frameworks wie Twitter Bootstrap zum Einsatz kommen, kann es oft komfor­tabler sein, deren Helfer­klassen zu verwenden, z.B. für das Raster­system. Ich persönlich finde den Code so übersicht­licher, als wenn alles nur im Stylesheet geregelt würde. Darüber hinaus lassen sich somit Wieder­ho­lungen im CSS-Code vermeiden. Mit dem Einsatz von Helfer­klassen werden class–Attribute aber schnell sehr lang und Klassen verschiedener Aufga­ben­be­reiche vermischen sich:

<article class="article row">
  <div class="article__content col col-md-6 col-xl-6"></div>

Ich brauche oft auch eine Klasse für HTML-Code, welcher von einem CMS wie WordPress oder Kirby über über einen WYSIWYG-Editor oder aus Markdown generiert wurde. Dieser ist meist sehr generisch und hat kaum Klassen. Von daher lässt es sich am meist am besten durch eine Klasse auf dem Container-Element und Kinds­e­lektoren stylen. Inzwischen nenne ich diese Container-Klasse meistens richtext. Ein Beispiel:

.richtext p  { margin-bottom: 1.5rem; }
.richtext h2 { font-size: 1.25em; […] }

Auf dieser Website kommt noch die Klasse hyphenate für Absätze hinzu, auf dessen Inhalt per JavaScript Silben­trennung angewendet werden soll. Die Klassenliste wird schnell sehr lang und unüber­sichtlich:

article__content richtext hyphenate col col-md-6 col-xl-6

Klassen mit Trenn­zeichen struk­tu­rieren

Abhilfe schaffen Trenn­zeichen zwischen den Klassennamen im HTML-Attribut. Klassen stellen laut Spezi­fi­kation eine durch Leerzeichen getrennte Liste dar. Die Integration zusätz­licher Zeichen stellt also für keinem Browser ein Problem dar, wie Harry Roberts in Grouping related classes in your markup zusam­menfasst. Ich habe mir folgendes Schema angewöhnt:

                    +--- Utility ----+
                    |                |
article__content  / hyphenate richtext [ col col-md-8 col-xl-6 ]
|              |                       |                       |
+- BEM / Name -+                       +-------- Grid ---------+
  • BEM / Name: Name des Elements, so wie eventuelle Modifier. Beispiele: article__content, article__content--feature etc.
  • Utility: Allgemeine Helfer­klassen, die durch das Framework vorgegeben werden. Beispiele: richtext (für Inhalte aus einem WYSIWYG- oder Markdown-Editor), text--small, no-select etc.
  • Grid: Layout­spe­zi­fische Klassen des Raster­systems.

Das folgende Beispiel zeigt, dass durch den Einsatz von Trenn­zeichen auch lange Klassen­listen sehr übersichtlich sein können:

<article class="page page--about [ container ]">
  <div class="article__body [ row ]">
    <div class="article__content / richtext hyphenate [ col col-md-8 col-xl-6 ]">


Ich habe den oben beschriebenen Ansatz konsequent bei der Umsetzung dieser Website angewendet und bin sehr zufrieden mit der gestei­gerten Lesbarkeit meines Codes. Nachteile gibt es aus meiner Sicht keine bedeu­tenden, solange zwischen Trenn­zeichen und den eigent­lichen Klassennamen immer mindestens ein Leerzeichen ist. Sollte der Code mit Anderen zusammen bearbeitet werden, sollte aber zumindest vorher im Team darüber geredet werden, weil diese Syntax für die meisten Entwickler*innen (noch) sehr ungewöhnlich aussehen dürfte.

Dieser Artikel ist lizenziert unter einer Creative Commons Namens­nennung – Weitergabe unter gleichen Bedin­gungen 4.0 Inter­na­tional Lizenz.