CSS Properties Memory Test

Remember that HTML Tags Memory Test from before? Šime Vidas recently joked that a similar Memory Test but for CSS Properties should exist.

Of course I couldn’t resist, so here is the CSS Properties Memory Test 🤪


See the Pen CSS Properties Memory Test by Bramus (@bramus) on CodePen.

In total there are 653 properties for you to guess. Good luck! 😅

~

# Behind the scenes

The demo itself is a straight up fork from the aforementioned HTML Tags Memory Test with an adjusted list of items to guess and a small style change to tweak the appearance of the already guessed results.

The list of itself properties was generated from the “Properties and Descriptors” CSS Index. The index lists 705 properties, but I’ve filtered out -webkit-prefixed properties that also exist without such a prefix. The filtered array was eventually converted to a string and base64 encoded to discourage cheating.

// Get all listed properties
const allProps = $$('#properties + div > ul.index > li').map(($li) => $li.textContent.trim().split("\n")[0]); // ~> 705 props

// Filter out -webkit prefixed props that also exist without a prefix
const filteredProps = allProps.filter(prop => !(prop.startsWith('-webkit-') && allProps.includes(prop.replace('-webkit-', '')))); // ~> 650 props

// Base64 encode the whole lot string to discourage cheating ;)
const encodedProps = btoa(filteredProps.join(','));

Note that when decoded again there are 653 properties to guess. That’s because one of the entries lists 4 properties separated by a comma.

~

🔥 Like what you see? Want to stay in the loop? Here's how:

Using Emoji as the Mouse Cursor on a Webpage

Recently I saw this tweet by Marco Denic fly by:

To use an emoji as the cursor you can’t simply type in the emoji though.

/* ❌ This won't work */
html {
	cursor: 👻, auto;
}

What you’ll have to do instead is embed the emoji inside an SVG and then successively embed that SVG in the CSS file by passing it as a Data URL into the url() function.

/* ✅ This will work */
html {
	cursor: url('data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32" height="64" width="64"><text y="28" font-size="32">👻</text><path d="M0,2 L0,0 L2,0" fill="red" /></svg>'), auto;
}

See the Pen
Emoji Cursor
by Bramus (@bramus)
on CodePen.

I’ve also added a little triangle in the top left corner of the SVG, as that’s where the actual tip of the pointer is. Omitting it makes up for a really weird experience.

If you’re on a device that does not show a pointer, here’s a recording of what the demo looks like:

To customize the color of the tip you can change its fill value to any color you like. Although not recommended you can remove the entire <path> if you don’t want it.

To change the overall size of the emoji cursor, change the height and width attributes of the SVG. Best is to leave the other attributes (such as viewBox and font-size) alone, as those have been carefully tweaked.

🔥 Using this same technique you can set an emoji as the favicon.

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

CSS mix-blend-mode not working? Set a background-color!

💡 If you find your CSS mix-blend-mode not working as expected (on a white background), you need to explicitly set a background-color on the underlying element. The easiest way to do so is to apply background-color: white; on the html and body elements.

html, body {
    background-color: #fff;
}

~

Demos + Explanation

Without a background-color set

You’ll notice here that for the “white” sections, the set mix-blend-mode: difference does not seem to work. The navigation will stay white and visually blend into the white background. Note that the navigation is not actually gone, as you can still see it shine through whenever a number of any of the sections crosses it.

See the Pen CSS mix-blend-mode not working? (1/2) by Bramus (@bramus) on CodePen.

The reason why it doesn’t work is that the white sections don’t really have a white background. They have no background-color set, so they fall back to the default value of transparent. Visually this is manifested as a white color, but to the compositor it will still be transparent. As the compositor can’t calculate the difference of the white text against the transparent background, the text will remain white.

~

With a background-color set

With background-color: #fff; set on the body/html the compositor does know how to calc the difference, and the demo will behave correctly.


See the Pen CSS mix-blend-mode not working? (2/2) by Bramus (@bramus) on CodePen.

Alternatively we could set this declaration on the sections themselves:

section {
    background-color: #fff;
}

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Accept several email addresses in a form with the multiple attribute

A popular tweet of mine that’s been doing rounds again (thanks to an RT by Stefan, whom you should definitely follow) is this little tip:

By setting the multiple attribute on an input[type="email"] you can have it accept multiple entries. Each entry is separated by a comma and is validated individually.

Here’s a little demo video of how that works:

💁‍♂️ For a slight moment there you can see that [email protected] is considered valid. As per RFC 822 the [email protected] format — used mainly in local networks — indeed is allowed.

~

However, it was pointed out to me that on iOS this isn’t usable by default:

On iOS, the “email keyboard” looks like this, with no comma to be found (not even when switching to numbers/symbols):

To work around this limitation you can manually override the input to use the regular keyboard by setting the inputmode attribute to text.

That way we still have the built-in browser validation rules (triggered by [type="email"]) and a means to type in a comma (triggered by [inputmode="text"]). Double win!

💁‍♂️ Sidenote: With this inputmode attribute you can create better number inputs.

~

Combining what we know, here’s a full demo for you to play with:

See the Pen
Accepting multiple e-mail addresses in one input
by Bramus (@bramus)
on CodePen.

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Nested Media Queries

I can’t seem to find any mention of this in the Media Queries Module specification, but apparently it’s allowed to nest media queries, as shared by Šime Vidas:

That’s … awesome! 🤯

Fiddling with it a bit more, turns out this snippet also works as expected:

@media not print {
  @media (min-width: 0) {
    p {
      font-weight: bold;
    }
    @media (max-width: 750px) {
      p {
        background: yellow;
      }
    }
  }
}

You can play with this CodePen demo to try it yourself.

💁‍♂️ Don’t confuse Nested Media Queries with CSS Nesting, an upcoming feature of CSS, which allows you to nest selectors.

UPDATE: Thanks to reader Vadim Makeev for pointing out that support for nested @media blocks was added to Opera 12.50 back in 2012! Its syntax is defined in the CSS Conditional Rules Module specification.

The future of CSS: Higher Level Custom Properties to control multiple declarations

When using CSS Custom Properties we mainly use them directly as variables in calculations for other properties. Having one CSS Custom Property control a varying set of other properties — such as both colors and numbers — is not exactly possible. There are some hacky workarounds we can use, but these don’t cover all scenarios. Thankfully there’s a new idea popping up: Higher Level Custom Properties. Although still premature, these Higher Level Custom Properties would allow us to drop the hacks.

Let’s take a look at our current options, and how this (possible) future addition to the CSS spec — along with the @if at-rule it introduces — might look …

~

~

# CSS Custom Properties as Variables

When working with CSS Custom Properties today, they are mainly used as CSS Variables. If you’ve used them, you’re quite familiar with code like this:

:root {
    --square-size: 2vw;
    --square-padding: 0.25vw;
}

.square {
    width: var(--square-size);
    padding: var(--square-padding);
    aspect-ratio: 1/1;
}

.square--big {
    --square-size: 16vw;
    --square-padding: 1vw;
}

Using the var() function we create a CSS Variable which gets substituted for the value of the Custom Property it refers to.

E.g. The variable var(--square-size) will hold the value of the --square-size Custom Property — namely 2vw — which is then set as the value for the width CSS property.

🤔 CSS Custom Properties vs. CSS Variables — Is there a difference?

Yes there's a difference:

  • A CSS Custom Property is any property whose name starts with two dashes (U+002D HYPHEN-MINUS), like --foo. Just like with a normal property you can assign a value to it, e.g. --foo: 200;.
  • A CSS Variable is created when the var() function is used. When creating the CSS Variable var(--my-prop), it will be replaced with the value of the --my-prop Custom Property it refers to, namely 200.

~

# Using CSS Custom Properties to affect multiple CSS declarations

In the example above we have two types of squares: regular sized ones and big ones. To differentiate between them we need to toggle the .square--big class. Toggling that class affects two CSS Custom Properties: both --square-size and --square-padding are altered.

But what if we wanted not to toggle a HTML class but a CSS Custom Property to do so? E.g. we want to toggle one CSS Custom Property, and have that automatically affect both --square-size and --square-padding.

As it stands today it’s not very straightforward to let one single CSS Custom Property affect multiple other CSS Properties, unless you resort to some hacky workarounds. Let’s take a look at the options we have today.

~

# Binary Custom Properties

If all you’re setting is numeric values, you can use Binary CSS Custom Properties within calculations. You give these Binary Custom Properties the value of 0 or 1 and use them within your calculations. Think of these Binary Custom Properties like light switches: they can either be OFF/false (0) or ON/true (1).

:root {
    --is-big: 0;
}

.square--big {
    --is-big: 1;
}

.square {
    width: calc(
        2vw * (1 - var(--is-big)) /* Value to apply when --is-big is 0 (~false) */
        +
        16vw * var(--is-big) /* Value to apply when --is-big is 1 (~true): */
    );
    padding: calc(
        0.25vw * (1 - var(--is-big)) /* Value to apply when --is-big is 0 (~false) */
        +
        1vw * var(--is-big) /* Value to apply when --is-big is 1 (~true): */
    );
    aspect-ratio: 1/1;
}

In the example above the --is-big Custom Property acts as a binary toggle that controls the results of the calc() functions. In the case of --is-big having a value of 0 those functions will yield one specific value, while when --is-big is set to 1 it will yield another value.

☝️ With some extra effort you can even perform Logical Operations (AND, NAND, OR, NOR, XOR, …) using CSS Custom Properties!?

Ana Tudor worked out the math for us in Logical Operations with CSS Custom Properties:

:root {
    --j: 1;
    --k: 0;
}

element {
    --notj: calc(1 - var(--j));
    --and: calc(var(--k)*var(--i));
    --nand: calc(1 - var(--k)*var(--i));
    --or: calc(1 - (1 - var(--k))*(1 - var(--i)));
    --nor: calc((1 - var(--k))*(1 - var(--i)));
    --xor: calc((var(--k) - var(--i))*(var(--k) - var(--i)));
}

🤯

~

# The Guaranteed-Invalid Value Hack

When you need to set things other than numeric values — such as colors — you can’t rely on a toggle that is either 0 or 1, as performing calculations with colors is invalid.

.square {
    /* ❌ This won't work! ❌ */
    color: calc(
        hotpink * (1 - var(--is-big))
        +
        lime * var(--is-big)
    );
}

The spec detailing calc() is clear on this:

It can be used wherever <length>, <frequency>, <angle>, <time>, <percentage>, <number>, or <integer> values are allowed.

CSS Values and Units Level 3: 8.1 Mathematical Expressions: `calc()`

What you can do however is use The CSS Custom Property Toggle Trick by James0x57 — which I like to call “The Guaranteed-Invalid Value Hack” — where you set a Custom Property to the “guaranteed-invalid value” of initial to force the var() function to use its fallback value:

If, for whatever reason, one wants to manually reset a variable to the guaranteed-invalid value, using the keyword initial will do this.

CSS Custom Properties for Cascading Variables Module Level 1: 2.2. Guaranteed-Invalid Values

In code it boils down to this:

--my-var: initial; /* initial => var() will use the fallback value */
color: var(--my-var, green); /* ~> green */
--my-var: hotpink; /* Any value other than `initial` (even simply one space!) => var() will not use the fallback value */
color: var(--my-var, green); /* ~> hotpink */

That means that you can flip the switch ON by setting a Custom Property to the value of initial. Here’s an example where the text will turn green and italic once --is-checked is flipped on:

input[type="checkbox"] + label {
    --is-checked: ; /* OFF */
    color: var(--is-checked, green);
    border: var(--is-checked, none);
    font-style: var(--is-checked, italic);
}

input[type="checkbox"]:checked + label {
    --is-checked: initial; /* ON */
}

A limitation of this approach however is that you can’t define several values to use in case --is-checked is in the OFF state. Say I want the text in the example above to be both red by default and with a border. Setting --is-checked to red will only get me halfway, as that value is only valid for the color property here.

input[type="checkbox"] + label {
    --is-checked: red; /* Default value to use */
    color: var(--is-checked, green); /* ✅ Will be red by default */
    border: var(--is-checked, none); /* ❌ What about a default value for border? */
    font-style: var(--is-checked, italic); /* ❌ What about a default value for font-style? */
}

~

# Update 2020.01.22: The Space Toggle Trick

UPDATE: As James0x57 himself pointed out in the comments below, the “CSS Custom Property Toggle Trick” can be used for this, but it takes some adjustments when compared to the implementation above. Here’s what James0x57 calls the Space Toggle Trick:

  • Consider the value   (space) to be the ON position, and the value of initial to be the OFF position.
  • Assign property values to new custom properties using the syntax --value-to-use-if-custom-toggle-is-on: var(--my-custom-toggle) value;, where you put the value to be used after the CSS Variable.

    --toggler: initial;
    --red-if-toggler: var(--toggler) red;
  • To use the value, use the var() syntax as before (e.g. adding a fallback value):

    background: var(--red-if-toggler, green); /* will be green! */
  • If you have more than one property than can affect a toggle, you can chain them up:

    • AND Logic:

      --red-if-togglersalltrue: var(--tog1) var(--tog2) var(--tog3) red;
    • OR Logic:

      -red-if-anytogglertrue: var(--tog1, var(--tog2, var(--tog3))) red;

Here’s a pen that applies his technique, with some cleaned up property names:

See the Pen
3. Binary Custom Properties + “The CSS Custom Property Toggle Trick” (Renamed)
by Bramus (@bramus)
on CodePen.

Thanks for clarifying James0x57, as I only understood half of your hack before 😅

~

# Future Solution: Higher Level Custom Properties

So the problem is that, as it stands today, we can’t have one single CSS Custom Property affect a varying set of other CSS Properties, or at least not in an easy way. At the CSS WG Telecon from early December 2020 Lea Verou proposed something called “Higher Level Custom Properties”, which would allow exactly that!

🚨 Do note that this proposal is still in it’s very very early stages and part of an ongoing discussion. The CSS WG has merely expressed interest in this proposal, suggesting that it should be explored further. If if tends to be helpful and possible, only then work on a Working Draft will start. Right now it still is a concept.

~

# Definition and Example

“Higher Level Custom Properties” are Custom Properties that control a number of other CSS Properties. As the proposal stands right now you use them in combination with a newly proposed @if at-rule, like so:

.square {
    width: 2vw;
    padding: 0.25vw;
    aspect-ratio: 1/1;

    @if (var(--size) = big) {
        width: 16vw;
        padding: 1vw;
    }
}

Unlike the Custom Properties we know today, a Higher Level Custom Property controls multiple declarations, way beyond simple variable substitution. In the example above we set our HLCP --size to have a value of big. This value isn’t used directly, but affects the other properties width and padding.

Using this HLCP also improves the meaning of our code. Setting width: 16vw; does not clearly express our intent, whereas setting --size: big; does.

💁‍♂️ If you don’t like @if then please don’t discard the whole idea immediately, but focus on the problem it’s trying to fix here. Lea’s proposal is a possible solution, not the solution. Could be that — in the end — we end up with a totally different syntax.

~

# Issues that still need to be tackled

Before you get too excited, there are still some cases that need to be taken care of. In a follow-up comment on the proposal, Lea documented some already identified issues.

🚨 Note that these issues are blocking issues. As long as these aren’t resolved, HLCPs won’t happen.

# Partial Application

A first issue is a problem with the desugaring of @if and partial application. Behind the scenes a @if at-rule desugars to the still discussed if() function call. The example above eventually becomes this:

.square {
    width: if(var(--size) = big, 16vw, 2vw);
    padding: if(var(--size) = big, 1vw, 0.25vw);
    aspect-ratio: 1/1;
}

This leads to no issue here, but it becomes quirky when comparing against percentages for example.

E.g. consider this:

.foo {
	@if (1em > 5%) {
		width: 400px;
		height: 300px;
	}
}

which desugars to:

.foo {
	width: if(1em > 5%, 400px);
	height: if(1em > 5%, 300px);
}

Now consider that an element that matches .foo is inside a 600px by 400px container and has a computed font-size of 25px; This makes 1em > 5% evaluate to false on the width property and true on the height property, which would make the @if partially applied. We most definitely don’t want that.

There are some ideas floating around to fix this — such as forcing percentages/lengths to always be compared against the width — but that’s still a bit vague right now.

# Cascading

Another issue that was pointed out is one on Cascading. I especially like this one, as it gives us a good insight in how CSS behaves and works:

Inline conditionals will have the IACVT (Invalid At Computed Value Time) behavior that we have come to know and love (?) from Custom Properties. Since @if will desugar to inline conditionals, it will also fall back to that, which may sometimes be surprising. This means that these two snippets are not equivalent:

.notice {
	background: palegoldenrod;
}

.notice {
	/* Desugars to background: if(var(--warning) = on, orange, unset); */
	@if (var(--warning) = on) {
		background: orange;
	}
}
.notice {
	/* Desugars to background: if(var(--warning) = on, orange, palegoldenrod); */
	background: palegoldenrod;

	@if (var(--warning) = on) {
		background: orange;
	}
}

You can file IACVT (Invalid At Computed Value Time) in the #TIL section there.

A declaration can be invalid at computed-value […] if it uses a valid custom property, but the property value, after substituting its var() functions, is invalid. When this happens, the computed value of the property is either the property’s inherited value or its initial value […].

This explains why in the example below the background won’t be red but (the default) transparent.

:root { --not-a-color: 20px; }
p { background-color: red; }
p { background-color: var(--not-a-color); }

👉 As 20px is no valid <color> value, the last declaration will become background-color: initial;.

💡 If we would have written background-color: 20px directly (e.g. without the use of Custom Properties), then that declaration would have simply been discarded due to being invalid, and we would have ended up with a red background.

~

# In Closing

The “Higher Level Custom Properties” idea by Lea Verou is one that quite excites me, as it solves an actual issue one can have in their code and would avoid having to use one of the nasty hacks.

There’s still a long way to go before we might actually see this land, yet as the CSS WG has expressed interest I’m hopeful that the already identified issues will be wrinkled out, and that work on an official spec can start.

If you have your own input on this subject, then I suggest to participate in the Higher Level Custom Properties discussion on GitHub.

~

🔥 Like what you see? Want to stay in the loop? Here's how:

Injecting a JavaScript Attack Vector using CSS Custom Properties

Earlier this week I saw this tweet by Sansec float by:

This one’s pretty nice I must say: as the syntax for CSS Custom Properties is overly permissive (see here) you can use Custom Properties to store your JavaScript attack vector in. If you then use window.getComputedStyle to extract the contents of the Custom Property (see here) and combine it with a function constructor and an IIFE, it’s possible to execute it.

Here’s a pen that loads a remote confetti script using the method described:

Let this underline the importance of a Content Security Policy to prevent remote script loading script evaluation.

Update: Blocking this “hack” with a proper CSP

It took me some time to figure out — as I’m no CSP expert — but turns out the unsafe-inline keyword in the CSP’s source list is enough to block the execution of the JS-IN-CSS.

As a reminder, here are the four allowed keywords:

  • 'none', as you might expect, matches nothing.
  • 'self' matches the current origin, but not its subdomains.
  • 'unsafe-inline' allows inline JavaScript and CSS.
  • 'unsafe-eval' allows text-to-JavaScript mechanisms like eval.

I first thought unsafe-inline would be insufficient here as the code does not call eval, but apparently a function constructor is (correctly!) considered equally harmful, and therefore also blocked.

Here’s an updated demo that blocks the script evaluation:

See the Pen
Injecting a JavaScript attack vector using CSS Custom Properties (with CSP)
by Bramus (@bramus)
on CodePen.

The CSP used is this one:

<meta
    http-equiv="Content-Security-Policy"
    content="script-src https://cpwebassets.codepen.io https://cdpn.io https://cdn.jsdelivr.net 'unsafe-inline';"
>

It works as follows:

  • https://cpwebassets.codepen.io and https://cdpn.io are there for the CodePen demo to work
  • https://cdn.jsdelivr.net is there to allow legitimate loading of scripts — such as a jQuery you might need — from that CDN.
  • unsafe-inline is the one that prevents the execution of the JS-IN-CSS defined script by blocking the call to the function constructor

That calls for confetti! 🤪

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Using the Numpad in vi over SSH

One of the things that kept on bothering me when SSH’ing is that the keys of the numpad would not work in vi: when pressing any key on the numpad, another key would be sent somehow.

Should’ve Google’d this a lot earlier because the fix is very simple: in the preferences of Terminal, go to Profiles → Your Profile → Advanced and uncheck the “Allow VT100 application keypad mode” option.

You can also tweak this setting from the CLI using PlistBuddy:

/usr/libexec/PlistBuddy -c "Delete 'Window Settings':Pro:StrictVTKeypad" ~/Library/Preferences/com.apple.Terminal.plist > /dev/null 2>&1
/usr/libexec/PlistBuddy -c "Set 'Window Settings':Pro:StrictVTKeypad bool true" ~/Library/Preferences/com.apple.Terminal.plist

There, much better 🙂

☝ I’ve also added this tweak to ./freshinstall, a tool which I built to automatically configure my MacBook (Preferences, Dotfiles, Installed Software, etc)

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

css-houdini-circles — A Houdini Paint Worklet that draws Colorful Background Circles

Last night — inspired by the Paint Worklet demos on Houdini.how — I decided to give Houdini a spin myself and created my own Paint Worklet. The result is css-houdini-circles which draws a bunch of random circles on the background.

🎩 Houdini, ain't that a magician?

Houdini is a set of low-level APIs that exposes parts of the CSS engine, giving developers the power to extend CSS by hooking into the styling and layout process of a browser’s rendering engine. Houdini is a group of APIs that give developers direct access to the CSS Object Model (CSSOM), enabling developers to write code the browser can parse as CSS, thereby creating new CSS features without waiting for them to be implemented natively in browsers.

It really is magic, hence it's name Houdini. I'd recommend this slidedeck and this video to get you started

As a user you can configure the number of circles, the size range, the opacity range, and the colors to use. In true Houdini style these are all configured using CSS Custom Properties.

.element {
    --colors: #f94144, #f3722c, #f8961e, #f9844a, #f9c74f, #90be6d, #43aa8b, #4d908e;
    --min-radius: 20;
    --max-radius: 100;
    --num-circles: 30;
    --min-opacity: 10;
    --max-opacity: 50;

    background-image: paint(circles);
}

~

Here’s a CodePen demo for you to play with:

(Hit “Edit on CodePen” and change the CSS Custom Properties to your liking)

~

What first started out as a demo on CodePen, eventually led to me creating and publishing it as a package on NPM.

npm install css-houdini-circles

Furthermore I also created a pull request to add the site to the Houdini.now website. I was quite surprised to learn it already got merged and is already published on the website 🙂

~

Feel free to fork the repo to have a starting point to creating your own Paint Worklet. If you know how to work with HTML canvas, I’m confident you’ll find it very easy to do so.

css-houdini-circles source (GitHub) →
css-houdini-circles on npm →

Send mail with Exim from the CLI

I needed to test whether mail relaying worked with Exim or not. To do so I used this command:

exim -v [email protected]

After this type in your mail contents as shown below and hit CTRL+D afterwards to send it:

From:[email protected]
Subject: Hello From the CLI
This is a test from the CLI

It’s also possible to use a one-liner:

echo -e "From:[email protected]\nSubject: Hello From the CLI\nThis is a test from the CLI" | exim -v [email protected]

You’ll see the raw output appear on screen, and should see a 250 status code near the end if all went well.

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.