My gamedev side road journey as a frontend developer - week 1

Marciano Schildmeijer — Wed, 26 May 2021 12:14:50 +0000

Welcome readers to my side project diary!

Introduction

I'd like to share the story and thoughts so far I had from the start up until the end of the side project I'm working on. The biggest reasons I start this, is to give this process more structure and also to help other devs that are feeling the exact same as I did/do.

A little information about my younger self: Writing about parts of my life is very valuable. At age of 10, I started writing a small newspaper of a few pages 2 time a week. I did this, because my parents wanted to help me improve my language. At that age, it was not my favorite thing to do, because I loved gaming and didn't care much. I still kept writing 2 times a week, though with some push from my parents here and there, for 7 years. And I am happy to I did, because it is like a timemachine for me. I can recall much easier what I did, and where I was, which is fun on itself in my opinion. The real message I want to tell that writing is really valuable if you want to learn new things. That's why I like to talk about my side project I'm working on.

Earlier side projects

I'm working as a frontend developer for 4 years now. Most of the times, I still feel like an imposter, like many of us frontend developers do. I also did a lot of unfinished side projects, which I think I handled very inefficiently in my eyes when I look back. I "flew" in the project with a vague global idea of what I wanted, and just started building. Building a few simple features worked out okay. But working on a fairly complex side project needed some more guides and structure. I didn't have such. I kept forgetting what I wanted to build exactly and for what, then lost interest in the project and value of the idea, while the projects were also far too hard and big at that time. Most certainly without any kind of structure.

The game side project

So after a warehouse full of failed and unfinished side projects, I felt bad. I need projects that challenge me to learn the things I want to get good at, and something I really like to build. I struggled with this a lot. Why build something that already exists? And what does it solve? Well, I should keep in mind that it solves one of my great goals: Building a cool app/website that also allows me to get me more knowledge of programming subjects.

Then I started "metselen".

Enter "metselen" the game

So I started this game side project out of nowhere on a Tuesday evening. I remembered this small game that I was playing in primary school, and I wanted to rebuild it and extend it with my own ideas. But first, I started writing exactly what came up into my mind, and made little user stories out of that. This helped me to setup a small structure, so when I returned to this project later, I knew where I left off, and what/why I wanted to build this again. Very useful.
I also introduced talking about this project on a weekly basis with a colleague of mine, who helped me up to speed and still encourages me to work on it, because he is interested in the game and the steps I take.

"Metselen" is a dutch word which actually means bricklaying. In short, the game works like this: You answer multiplication sums and for each correct answer, you'll get a brick in a given time.

An earlier version of the game:

Basic functionalities are working. I was happy!

Next week I'll share the progress and some other dev hurdles I needed to take.

See you next week!

How the CSS stacking context works

Marciano Schildmeijer — Tue, 21 May 2019 00:00:00 +0000

Anyone who has ever worked with HTML and CSS may have heard of, or worked with the z-index property. What it does is pretty straightforward: It allows you to manage the stacking order of so called “positioned” HTML elements. Anything with a higher z-index number should always appear above elements with a lower z-index. However, sometimes you end up in situations where the z-index property doesn’t seem to have any effect at all and it isn’t that straightforward as it seems. In these situations it’s likely that you’re dealing with differences in the stacking context.

Default rules of stacking elements

When no positioned elements are applied, the basic rules of the element stacking order is as follows:

When the root element is rendered, it creates the root (or global) stacking context.
Followed by non-positioned elements, where the position value is not specified. The position value defaults to static.
Followed by positioned elements, which are all elements with a position property other than static, such as fixed, absolute, sticky or relative.

All respecting the order they are declared in the document.

Stacking with positioned elements

When elements are positioned, they appear above non-positioned elements. Many layouts consist out of positioned elements where controlling the stacking order of elements is required. A common use case is for instance a modal you want to show above the normal content of your page. To control the stacking order, z-index is used on positioned elements. Z-index won’t work on non-positioned elements. Applying the position properties with values like fixed and sticky, or absolute and relative in combination with a z-index value other than auto, will create a new local stacking context.

Taking (local) stacking contexts into account

Things get more tricky now. When stacking contexts are created on an element, that element will become a root stacking context element for its children elements. Documents can have many stacking contexts, so it is not rare to have stacking contexts inside other stacking contexts. The problem this creates is that children of the newly created stacking context won’t be able to render on top of an element in a different stacking context. Never ever. Even when the children will become positioned elements. Even with z-index: 999999;.

To overcome this problem, you can swap out these child elements in the current DOM hierarchy and bring them to the same level of the root stacking context ( element). Positioned sibling elements can be ordered with the z-index property. However in more complex DOM structures where many elements live inside each other, this may include some rework of your CSS or even JavaScript and may be more complex.

Implicit creation of stacking context

Another important thing to mention is that there are more implicit ways of how stacking contexts are created. Earlier in this post, I mentioned one way of how stacking contexts are created. There are more CSS properties that create their own stacking contexts implicitly. Unfortunately there is no clear way to see when a stacking context is created at a glance. However, there is a cool Chrome plugin that can be a bit of a help when identifying stacking context elements. It basically collects the properties that cause the stacking context for each element and outputs information about the element like this (shown in the right column, Z-index tab):

Properties that also create stacking contexts are (source from MDN):

Element that is a child of a flex (flexbox) container, with z-index value other than auto.
Element that is a child of a grid (grid) container, with z-index value other than auto.
Element with an opacity value less than 1.
Element with a mix-blend-mode value other than normal.
Element with any of the following properties with a value other than none:
transform
filter
perspective
clip-path
mask / mask-image / mask-border
Element with an isolation value isolate.
Element with a -webkit-overflow-scrolling value touch.
Element with a will-change value specifying any property that would create a stacking context on non-initial value.
Element with a contain value of layout, or paint, or a composite value that includes either of them (i.e. contain: strict, contain: content).

Why these properties have side-effects like these, is unclear.

Solving it in when using React

Most React applications can consist of those more complex DOM hierarchies, which won’t allow you to swap out elements with their own stacking context so easily. However, React incorporated a neat addition called “Portals” in v16. Portals will allow you to mount any DOM element at any place in your DOM structure. React also mentions this in their documentation:

“A typical use case for portals is when a parent component has an overflow: hidden or z-index style, but you need the child to visually “break out” of its container. For example, dialogs, hovercards, and tooltips.“

Summary

I hope this helped you prevent future headaches by learning about stacking contexts and the way they interact with z-indexes. Here is a summary of this post:

Applying certain CSS properties will allow you to control the stacking context.
Applying a z-index value of the highest possible value number to a local stacking context won’t make that element appear above other elements with stacking contexts living higher up in the DOM.
Z-indexes only have meaning in their self-contained stacking context (global or local)
Layouts can have many stacking contexts alongside each other, and inside each other.

Thanks for reading and good luck stacking!

Forem: Marciano Schildmeijer