Rafael Epplée

A CSS-Only Overflow Indicator for Multiline Text

2023-09-12T00:00:00+00:00

When building archive.observer</a>, a page for browsing the AskHistorians subreddit archives, I wanted to preview the text for each post in a list:

Posts in that subreddit can be quite long, so I wanted to truncate the preview to a fixed number of lines. If that happened, I needed an indicator showing that there was more text available to read. I settled for a “fadeout” effect:

In this post, I’ll show you how to implement this indicator, along with a little trick that makes sure it works in all of these cases:

The indicator is only shown if the text actually overflows its container.</li>

It works for multiple lines of text (many techniques documented elsewhere don’t).</li>

If the text needs less space than the maximum height, the container shrinks to fit the text.</li> </ul>
The Code</h2>
This is the code we’ll produce:
.hide-overflow { position: relative; max-height: 15.75rem; overflow: hidden; } .hide-overflow::after { position: absolute; height: 5.25rem; left: 0; right: 0; background: linear-gradient(transparent, white); content: " "; pointer-events: none; /* If text is shorter than max-height, push the overflow indicator down so it's hidden by the overflow. */ bottom: calc((100% - 15.75rem) * 20); } </code></pre> It assumes a HTML structure like this:
<div class="hide-overflow"> Lorem Ipsum dolor sit amet... </div> </code></pre>
Walkthrough</h2>
The CSS is mostly a standard affair. We give the container a class, set a max-height and hide the overflow:
.hide-overflow { position: relative; max-height: 15rem; overflow: hidden; } </code></pre> Using position: relative</code> allows us to position the ::after</code> pseudo-element relative to the bottom edges of our container:
.hide-overflow::after { position: absolute; height: 5rem; left: 0; right: 0; bottom: 0; /* ... */ } </code></pre> So far, so good. Let’s make the indicator visible using a simple gradient:
.hide-overflow::after { /* ... */ background: linear-gradient(transparent, white); content: " "; pointer-events: none; /* ... */ } </code></pre> pointer-events: none</code> ensures that users can still select text below the indicator. Here’s the trick. We change the bottom</code> style to actually hide this indicator when the text fits inside the containers max-height</code>: .hide-overflow::after { /* ... */ bottom: calc((100% - 15rem) * 20); } </code></pre> 100% - 15rem</code> is the key: This expression is lower than zero if the actual height of the container (100%</code>) is smaller than its maximum height (15rem</code>), meaning the text didn’t overflow the container. If it is lower than zero, we multiply it by an arbitrarily large number (in this example it’s 20) to move the indicator below the bottom edge of the container, effectively hiding it. The whole thing is basically a roundabout way of using calc</code> to “detect” if there’s any text overflow. Here’s an example showing the position of the hidden indicator in green. In this case, the bottom</code> property has a computed value of -160px</code>: Conclusion</h2> It took me a little while to work out this trick and I found no alternatives with similar features on the web; Even though it’s a hackish workaround, I’m quite fond of its simplicity, and I think other websites might profit from it as well. Reddit, for example, seems to use JS to determine whether the overflow indicator should be visible or not. I tried to implement the indicator using container queries</a>, but couldn’t get around some of their limitations.



Deploying Godot 4 HTML exports with cross-origin isolation
2022-11-14T00:00:00+00:00
Godot 4 games exported to HTML use a JavaScript feature called SharedArrayBuffer</a>.
This allows sharing memory between the main thread and service workers efficiently.
However, it makes it possible for scripts loaded from other pages to access this shared memory as well, which opens a page up to security vulnerabilities.</p>

    Side note</small>

    Check out my
    free and open source game knakk</a
    >!
</aside>
To prevent vulnerabilities, sites using the SharedArrayBuffer</code> feature need to fulfill some security requirements:</p>

They must be in a Secure Context</a>, which is mostly achieved by serving the site over HTTPS.</li>
They need to set a suitable Cross-Origin-Opener-Policy (COOP)</a> and Cross-Origin-Embedder-Policy (COEP)</a> header resulting in “Cross-Origin Isolation”.
The standard values for these are same-origin</code> and require-corp</code> respectively, but Chrome supports credentialless</code></a> as an embedder policy as well.</li>
</ul>
Let’s look at how we can fulfill these requirements when deploying our games to itch.io and Netlify.</p>
itch.io</h2>
itch.io has experimental support for SharedArrayBuffers</a>.
All we have to do is tick the “SharedArrayBuffer support” checkbox in the Embed Options > Frame Options</code> section of our game’s settings page.</p>
Setting the standard Cross-Origin Isolation headers breaks some features that interact with other domains. 
itch.io uses Chrome’s credentialless</code> option for the COEP header which lifts some of the restrictions imposed by the require-corp</code> option.
Firefox does not implement credentialless</code> at the time of writing, meaning Godot 4 HTML exports deployed on itch.io will only run in Chrome-based browsers.</p>
Netlify</h2>
In contrast to itch.io and other simple hosting options like GitHub Pages, Netlify allows setting custom headers</a> using a _headers</code> file or the netlify.toml</code> configuration file.</p>
Here’s the entry in netlify.toml</code> for setting the required cross origin policy headers to run both in Chrome and Firefox:</p>
[[headers]]
</span>for </span>= </span>"/*"
</span>
</span>[headers</span>.</span>values]
</span>Cross-Origin-Opener-Policy </span>= </span>"same-origin"
</span>Cross-Origin-Embedder-Policy </span>= </span>"require-corp"
</span></code></pre>
Closing thoughts</h2>
It has only been about half a year since Chrome shipped credentialless</code> support, and Firefox is testing it using an Origin Trial</a>. 
Going forward, it’s likely we’ll see credentialless</code> as the standard way to enable SharedArrayBuffers, resolving the itch.io Firefox incompatibility.</p>
I’d love to deploy my games to GitHub Pages as well.
GitHub pages does not allow setting custom headers, but there is a feature request for COOP/COEP with a potential workaround</a> that uses a service worker to set the required headers.</p>
See also</h2>

Cross-origin isolation Guide on web.dev</a></li>
Chrome’s post on credentialless support has a good explanation of Cross-Origin Isolation</a></li>
Proxying GitHub Pages through Cloudflare and Heroku allows setting custom headers</a></li>
</ul>


Making peer-to-peer multiplayer seamless with Godot
2022-01-02T00:00:00+00:00
When we started developing our recently-released mini-strategy game 2 Planets</a></span>, we wanted to add networked multiplayer support.
Since the game is a side project and would be released for free, we didn’t want to spend much time and money on maintaining dedicated servers.
Instead, we chose a simple peer-to-peer networking setup where both players would connect to the other player’s machine directly.</p>

    Side note</small>

    Check out my
    free and open source game knakk</a
    >!
</aside>
Our initial implementation was very simple - players entered the IP of their match partner, we passed it to Godot and let the engine handle the rest. This had some problems:</p>

Entering IP addresses by hand is cumbersome and error-prone</li>
No matchmaking support</li>
Machines behind a NAT</a>-enabled router are not accessible directly</li>
</ul>
To solve these problems, we set up a small “rendezvous” server capable of NAT hole punching</a>.
When starting a game, players connect to the publicly available server, which sends them the IP address of their match partner and punches holes into router’s NATs if needed.
Both game clients then connect directly to each other, and the server’s job is done.
This process allowed us to connect players using small “Match codes” which were shorter and easier to type than IP addresses. We haven’t implemented matchmaking yet, but adding it to the current implementation would be a simple task.</p>

    
</video>
Two players starting a game over the network in 2 Planets</small>
I consider this approach ideal for small indie games.
Dedicated servers allow better cheat protection, and NAT hole punching doesn’t work all the time, but with this approach, the maintenance burden and complexity is considerably lower, both for the game’s code and the server’s operation.</p>
If you’re looking for a way to have peer-to-peer multiplayer without setting up your own server, have a look at Steam’s Networking API</a> which also has a Godot integration via GodotSteam</a>, or have a look at the Epic’s NAT P2P API</a>. Both provide NAT hole punching support with relay services as a fallback.</p>
If, on the other hand, you want to stay independent of Steam and Epic or just like to do things yourself, continue reading! In the following you’ll find a short guide on setting up peer-to-peer multiplayer with NAT hole-punching in Godot for your own game, using your own server.</p>
Setting up your own</h2>
You’ll need the following:</p>

The excellent HolePuncher</a> Godot plugin and server by Cregg Hancock</li>
A server or service allowing you to host a small python application (e.g. Heroku</a> or Vercel</a>)</li>
Basic networking and server administration knowledge. Using a service like Heroku, you can get a python server up and running pretty easily, but you’ll still need some experience to configure everything correctly.</li>
An understanding of Godot’s multiplayer API</a> for connecting clients using the IP obtained from the rendezvous server and synchronizing the game state.</li>
</ul>
First, deploy the HolePuncher</a> python server. Make sure it is accessible from your development machine. You don’t need a domain: if your server has a static IP, you can use that to let your clients initiate a connection.</p>
Next, download and include the HolePuncher Godot plugin in your game. Copy the addons</code> folder from the HolePuncher repository and place it at the root of your Godot project folder. Afterwards, go to Project > Project Settings > Plugins</em> and enable the HolePuncher plugin.
You can now add and configure a HolePunch</code> node to your menu scene.
We’ll do that in the following script:</p>
hole_puncher </span>= </span>preload</span>(</span>'res://addons/Holepunch/holepunch_node.gd'</span>)</span>.</span>new</span>()
</span># your rendezvous server IP or domain
</span>hole_puncher</span>.</span>rendevouz_address </span>= </span>"1.1.1.1"
</span># the port the HolePuncher python application is running on
</span>hole_puncher</span>.</span>rendevouz_port </span>= </span>"3000"
</span>add_child</span>(hole_puncher)
</span></code></pre>
Refer to the HolePuncher documentation</a> to learn more about its configuration. 

You can now start the NAT traversal by calling the hole puncher’s start_traversal</code> method:</p>
# Generate a unique ID for this machine
</span>var player_id </span>= </span>OS</span>.</span>get_unique_id</span>()
</span>hole_puncher</span>.</span>start_traversal</span>(game_code</span>, </span>is_host</span>, </span>player_id)
</span># Yield an array of [own_port, host_port, host_ip]
</span>var result </span>= yield</span>(hole_puncher</span>, </span>'hole_punched'</span>)
</span></code></pre>
Run this code on both machines, with is_host</code>
set to true</code> on one machine, and to false</code> on the other. 

The game_code</code> variable is the match identifier, telling the server which peers’ IP addresses belong together. You can use any format, as long as it is unique for each match and both peers in a match use the same value. For an example on how to generate random game codes, look at this function in the 2 Planets source code</a>. 

After generating, you can display the game code you generated in your menu for players to exchange it through voice or chat messaging.</p>
The yield</code> call above turns your code into a coroutine</a> which will continue running after all the network calls have succeeded, which can take a few seconds.
When the hole puncher is done, you can use the returned information to create a Godot network peer.
You might use it like this:</p>
# Start a host
</span>var result </span>= yield</span>(hole_puncher</span>, </span>'hole_punched'</span>)
</span>var my_port </span>= </span>result[</span>0</span>]
</span>
</span>var peer </span>= </span>NetworkedMultiplayerENet</span>.</span>new</span>()
</span>peer</span>.</span>create_server</span>(my_port</span>, </span>1</span>)
</span>get_tree</span>()</span>.</span>set_network_peer</span>(peer)
</span></code></pre>
# Connect a client to a host
</span>var result </span>= yield</span>(hole_puncher</span>, </span>'hole_punched'</span>)
</span>var host_ip </span>= </span>result[</span>2</span>]
</span>var host_port </span>= </span>result[</span>1</span>]
</span>var own_port </span>= </span>result[</span>0</span>]
</span>
</span>var peer </span>= </span>NetworkedMultiplayerENet</span>.</span>new</span>()
</span>peer</span>.</span>create_client</span>(host_ip</span>, </span>host_port</span>, </span>0</span>, </span>0</span>, </span>own_port)
</span>get_tree</span>()</span>.</span>set_network_peer</span>(peer)
</span></code></pre>
After starting a host on one machine and connecting a client on another, you can start the game! Congratulations, you now have peer-to-peer multiplayer support from (almost) any network!</p>
Of course, this example only works for two players and is heavily simplified, you’ll need to add at least a way for players to exchange game codes and handle errors that appear during connection attempts. If you’d like to see a more realistic example, have a look at the lobby code from 2 Planets</span></a>. If you’re interested in adding matchmaking, have a look at the source code of the HolePuncher server. It’s pretty compact.</p>
I hope this guide was a good starting point for adding NAT hole punching to your game. NAT hole punching is a complex topic and you will probably have to look into other resources for a robust solution that fits your use-case, but getting started is surprisingly easy! If you have any questions or comments, feel free to reach out on twitter</a> or reddit</a>.</p>


Unity: Wishes for 2021
2020-12-02T00:00:00+00:00
I’ve recently finished building a VR project</a> in Unity. Since I’ve worked with Unity before and have gathered a little experience, I’m going to talk about that and highlight some topics I’d love to see addressed in the next few years.</p>

    Side note</small>

    Check out my
    free and open source game knakk</a
    >!
</aside>
Don’t touch that</h2>
Reading on how to implement a UI, I found this table in the unity docs explaining the situation at hand:</p>

Apparently, there are three different toolkits, used for different scenarios and development styles. 
Some features are only available in one of them, some things are easier to do in another, and one of them is generally the preferred choice because it will replace the other two someday.
Chances are you’ll be using all three of them at some time, multiplying the cognitive overhead as you switch between paradigms, file formats and APIs.</p>
A similar, but more frustrating situation is the state of VR support in Unity. There’s a legacy system and a new “plugin-based” system. The legacy system is deprecated, but the new system doesn’t support SteamVR – in my case forcing me to use the legacy system, the only reference to which I found in the Unity 5.4 docs</a>. </p>
This seems to be a pattern with Unity development: after discovering a component has problems, a new one is written (or bought</a>). 
But instead of getting replaced, the old component stays alive like a half-supported, half-documented zombie providing features the new component doesn’t get because the old one is still there.</p>
For me, this created an incredible amount of uncertainty while developing: Am I using the right tool for this? Is this bug caused by me or by this unmaintained legacy system? How do I know if I used this right when the docs where last updated in 2015?</em></p>
When even a tutorial for the new VR system tells you to use a Prefab from a folder named XR Legacy Input Helpers</code></a>, you can’t help but feel like you’re building on top of a tower of tech debt that can topple without warning. This confusion is a hurdle for people coming to Unity, and the complexity of having multiple competing solutions also complicates the workflows of seasoned Unity developers, even if they might not notice it a lot.</p>
I’ve seen the struggle with balancing new features and cleaning up legacy code in the teams I’ve worked with, and I sympathize with the Unity devs when thinking about the pressure that’s on them to ship fancy new features. However, It feels like the legacy systems are piling up</a>, damaging developer productivity and adoption of Unity in the long run.</p>
The obvious solution to this is to prioritize refactoring tasks on the roadmap – but I think there’s also a lesson to learn regarding software architecture. 
This issue highlights some of the dangers of rewriting code from scratch</a>, and it’s useful to keep this situation in your head when deciding whether to deprecate a piece of software or to refactor it and add backwards-compatible features. </p>
And if you decide to do the rewrite, pay attention to:</p>
Documentation & Communication</h2>
To find out what’s up with these legacy systems, you often have to dig through old blog posts in the Unity archive, just to understand the context the different solutions were written in, plans for their future and their capabilities. Guidance, context and overview regarding Unity’s capabilities is something I’m sorely missing from the official documentation.</p>
While the Unity docs are expansive in general, they often lack in details crucial to specific problems. Missing docs for legacy parts like the old VR system are one example, basic rules regarding colliders</a> are another. </p>
These are sometimes addressed by Unity employees in the forums</a>. Some are buried in in hours of videos on unity learn</a>. The community provides the rest of information on answers.unity.com</a>, Reddit, blog posts and YouTube videos. 
Trying to understand a specific behavior of Unity results in a journey through 30-minute videos, threads advising some form of power cycling and posts explaining basic concepts already covered in official materials, all to find a fact that could have been provided in a single sentence in the docs.</p>
Not to say that these resources are worthless. The Unity community is awesome, friendly and helpful. I just think Unity is missing a big opportunity in not channeling all these resources into a more structured, accessible format: 
Allowing the community to submit PRs for the official docs. (Or encouraging their own devs to write docs instead of forum posts, for that matter.) Linking from the documentation to specific videos in unity learn. Creating an index of links to resources covering specific topics.</p>
There are many specific questions and problems google can’t answer that a few sentences in the docs would clear up.</p>
Conclusion</h2>
Unity is incredibly capable in many ways. Improving on the existing codebase and documentation would make it even better: more stable, beginner-friendly and faster to work with.</p>


Automatically resolve Syncthing conflicts using a three-way merge
2020-09-17T00:00:00+00:00
I’m trying to move away from applications and services that store data using 
proprietary formats or servers that are not mine. I’m relying more and more on syncthing to do that,
and today I would like to show you a simple trick that I think opens up a whole range of 
possibilities for syncing app data.</p>

    Side note</small>

    Check out my
    free and open source game knakk</a
    >!
</aside>
For files that don’t change often, syncthing is already quite nice, but for other files like 
todo lists, notes etc. that get changed on multiple devices before being synced,
syncthing doesn’t know how to combine the changes and creates a 
conflict file</a>.</p>
As a developer being used to git’s convenient merging, this bugged me a lot. 
I tend to overlook these files, and resolving them using vimdiff</code> or meld</code> is time consuming.</p>
git merge-file</h2>
Enter git merge-file</code>. It’s bundled with git, but can run completely independent 
of any git repository. It automatically merges two versions of a file with little
to no conflicts. Exquisite!</p>
To work its magic, merge-file</code> performs a “three-way merge”, where it looks at
three files - the two conflicting edited versions, and their common ancestor.
The common ancestor is the version that both conflicting versions are based on.
Using this, git can figure out whether lines missing in one of the versions were
actually added or removed - with only two files, this would be impossible (See this stackoverflow post for a more thorough explanation</a>).</p>
“But where do we get the common ancestor from?”, you might ask. 
This is where syncthing’s awesome versioning feature
comes into play. As it turns out, syncthing can automatically keep an older copy of files
when they are modified. You can go all in with this and keep multiple older versions
depending on different criteria, but I simply use “Trash Can” versioning which
just keeps the most recent “backup” of a file. We can then use this backup to perform
a three-way merge using merge-file</code>!</p>
How to actually do this</h2>
Assuming we have a simple syncthing folder containing a file called notes.md</code> with the following content:</p>
- </span>I like markdown
</span></code></pre>
On one node, I add a line at the start:</p>
- </span>I like syncthing
</span>-</span> I like markdown
</span></code></pre>
On the other node, I add a line at the end:</p>
- </span>I like markdown
</span>-</span> I also like git
</span></code></pre>
Once syncthing detects the conflict, it will create a .sync-conflict</code> file, resulting
in this directory layout:</p>
├── notes.md
</span>├── notes.sync-conflict-20200917-224540-5CYLJKE.md
</span>└── .stversions
</span>    └── notes~20200917-173218.md
</span></code></pre>
We can now run git merge-file</code>, providing version one, the common ancestor and then version two:</p>
git</span> merge-file notes.md .stversions/notes</span>~<</span>xxxxx</span>></span>.md notes.sync-conflict-</span><</span>xxxxx</span>></span>.md 
</span></code></pre>
after which notes.md</code> contains the following:</p>
- </span>I like syncthing
</span>-</span> I like markdown
</span>-</span> I like also git
</span></code></pre>
Alright! Git merged the three files without us doing anything!</p>
Caveats</h2>
Since syncthing only creates backups in .stversions</code> when receiving changes from a remote
machine and not when the file is modified locally, you might end up in a situation 
without a common ancestor in .stversions</code>. 
In this case, you can simply use an empty file as the common ancestor:</p>
touch</span> empty.md
</span>git</span> merge-file notes.md empty.md notes.sync-conflict-</span><</span>xxxxx</span>></span>.md
</span></code></pre>
This might result in more conflicts than usual, but in general git is pretty good 
at figuring out common lines between differing versions. </p>
Closing thoughts</h2>
I’ve only been running this by hand since I didn’t have too many conflicts, but you could easily put this in a script that periodically scrubs your folder. This way, most merges run automatically, and if any lines actually conflict, you see them when editing the conflicting file the next time - way easier than manually looking for .sync-conflict</code> files all the time.</p>
I think this method has lots of potential to enable more use cases for syncthing.
For example, if you keep your playlists as .m3u</code> files in a syncthing folder,
you might use git merge-file --union</code> to tell git
to just keep both versions in case of conflicting lines. This way, at the cost of
some deleted songs re-appearing, you would never have a single conflict!</p>
This is why I love storing data in plain text files: I now have convenient, robust,
offline-capable note synchronization without needing any server (be that from a third party or maintained on my own), all while being free to choose and switch between a wide range
of note-taking software. For me, storing more and more of my personal data like this is the logical path forward.</p>

Rafael Epplée

A CSS-Only Overflow Indicator for Multiline Text

The Code</h2> This is the code we’ll produce:</p>

Walkthrough</h2> The CSS is mostly a standard affair. We give the container a class, set a max-height and hide the overflow:</p>

Deploying Godot 4 HTML exports with cross-origin isolation

Making peer-to-peer multiplayer seamless with Godot

Unity: Wishes for 2021

Automatically resolve Syncthing conflicts using a three-way merge