This website

This year I have redesigned my website from the ground up with a new focus in mind.

There are a couple of things I find interesting in web development: page transitions, animations, 3D designs which I overtly implemented to the previous version of this website. It brought an extra oomph emotion-wow icon

Combining all those pieces regardless of their purpose can be detrimental to the user experience. That’s especially the case when you don’t provide ways disable it. Even the most commonly used patterns (e.g: Dark mode) can harm the experience.

Focusing on accessibility

My focus definitely shifted from when I first built my website. I want this iteration to provide a simple introduction of who I am, some personal projects, writings and past working experiences. No clutter or fancy patterns. In its ideal form this website should follow a couple of rules.

This website should:

In a nutshell, I want future visitors of this website to explore it without feeling excluded by the choices I am making now.

Production process

Built with Eleventy, Netlify, and Github.


At the time of writting, I use a mix of serif and monospace typefaces available in most operating systems by default. I decided against using custom fonts. System fonts are good enough, reliable and reduce the loading time.


I use CSS. The architecture I adopted is derived from CUBE CSS and provide a nice way to organize styles. Using Nunjucks all files are then merged into a single one and minified.

There are no class names or id used for styling1. It’s a deliberate choice to enforce a clean and more semantic HTML architecture. This approach comes with maintainability pitfalls2 which does not apply with the small scope of this website.


  1. Uses semantic HTML whenever possible
  2. Ensuring accessible color contrasts
  3. Enforcing alternative descriptions to non descriptive visuals
  4. Minify HTML/CSS and avoid using any Javascript
  5. Generate appropriately-sized images in next-gen formats (AVIF)
  6. Uses SVG sprites to reduce network requests


  1. A few classes or ids might appear now and then before I hunt them down into oblivion. However, if their usage is motivated by a tangible benefit for the user they might be spared. ↩︎

  2. By not using classes and ids I overtly rely on nesting to target my elements. This in turn increase the specificity of my declarations which can be an issue in projects with bigger scope (which is not the case here so we are good) ↩︎