Guérilla.Studio

2024 Vanilla List’s state and what’s next

2024-10-09T07:50:19Z

As some of you may have noticed: Vanilla List—our index curating lightweight JavaScript plugins, is kinda in hiatus mode. I didn’t add any plugin/library since early 2023 and here were are, at the end of 2024.

There are several reasons behind it.

It was painfull to manage

Adding plugins to the website is a very manual and time consuming task.
Especially since I’m doing my best to curate only quality projects and take time to offer them a good presentation.

The process for suggesting plugins is even more laborious.
The (very kind) people suggesting plugins have to fork the project and send a Pull Request, followed by several back-and-forths, until everything matches my quality criteria. Which is also draining for me.

A radical change or just life? 😁

At the end of 2023 I was stuck in bed during a tough recovery time. So to keep my mind busy on something else than physical pain I started working on a new version of the website (funny considering the context of the last revamp).

I had in mind to improve the plugin addition and suggestion aspects, along with adding more complex features I think would be useful to have.

And while I was at it, also upgrade the entire stack the website is based on. This mainly includes upgrading to the next major version of the builder (Eleventy) and using some of its (at the time) bleeding edge features. Changing completely the framework was also on the table.

All that included re-organizing and sanitizing how plugins were currently stored.
So, it was making sense for me to keep the online version in a frozen state in the meantime to limit the amount of modifications I’d have to do when merging that new version.

What could possibly go wrong ahahah… *sigh* 🙄

Well, I finally got out from recovery but burnout caught up with me, big time.

And unfortunately all that work completely stopped.

I’ve spent basically all 2023 and 2024 trying to make things work in my life with burnout and other health issues.

That’s why not much has changed for quite some time.

What now?

Until now this project is purely made on my free time (my previous employer used to allow some time for me to work on it since it was useful for the company, that’s not the case anymore).
Needless to say that I always refused to monetize it in any way. It’s not in my values. Nothing is free but fuck the advertising economy.

Recently some things have slightly evolved in a better direction:

I’m progressively recovering, enough to start working on tech projects a bit (I've merged a few PR lately)
And big news: I’m now “full-time” working independently in a smaller structure I’ve co-founded that is no other that Guérilla.Studio! (I talked that decision briefly at the end of 2023 in a post on my personal blog).

Starting an adventure like that is certainly something big and time/energy/money consuming, but I’m surrounded by wonderful people and organisations that helped putting that into shape. (More info to come later)

All this to say that I should have more time to finish Vanilla List’s new website (probably in 2025) and also fill it with plenty new plugins and libraries, either suggested or that I’ve aggregated along the way.

It still will depend of the variable amount of available energy or free time I’ll have (since I’m a big fan of having a roof, food everyday and things like that 😅).

How to help

The project is not dead or looking for maintainer. I just need time.

I may in the future set up some kind of financial support through donations (GitHub sponsor for example), that would allow me to spend more time working on non-commercial open-source projects like Vanilla List. I’ll inform you when it will be in a more advanced state.

In any case any feedbacks, ideas for Vanilla List are welcome and a "Discussions" area on GitHub is now available if you want somewhere to post.

Aaaaand that’s about it.
Thank you already if you have read everything until now 🫶

As sign of hope for the future, a preview of the future homepage:

Thanks Hécate for fixing my typos🫶

The Mastodon media limitations final guide

2023-08-19T13:57:43Z

File extensions

Images: .jpg, .jpeg, .png, .gif, .webp, .heic, .heif, .avif
Videos: .webm, .mp4, .m4v, .mov

Size, dimensions & FPS

So, it's divided in two parts since it's changing starting in version 4.2.0.
_{(no it's not a weed joke, I'll stop you right here)}

Images

Before v4.2.0

Size: 10 MB
Upload limit: 3840 × 2160 px (4K)
Target dimensions: 1920 × 1080 px (1080p / Full HD)

Starting v4.2.0

Size: 16 MB
Upload limit: 7680 × 4320 px (8K)
Target dimensions: 3840 × 2160 px (4K)

Videos

Before v4.2.0

Size: 40 MB
Upload limit: 1920 × 1080 px (1080p / Full HD)
FPS limit: 60 FPS

Starting v4.2.0

Size: 99 MB
Upload limit: 3840 × 2160 px (4K)
FPS limit: 120 FPS

How to know on which version you are

In case you're wondering:

Write your instance's address (mastodon.social, octodon.social or eldritch.cafe or for example) in your web browser
Add /about at the end to access the about page
Scroll at the end where it's should displayed somewhere _{(woaw thanks Tixie for this specific info lol)}

That's it, that's the ~~toot~~ post. Hope it helped.

I may improve it over time, so don't hesitate to give me feedbacks, searching into Mastodon's codebase is a pain in the ass already (and I know what I'm talking about, I'm french).

Welcome the beta of Placehold.in

2023-07-25T11:56:03Z

Now available at https://placehold.in

Why?

For context, I was kind of pissed of after seen placehold.it being bought by placeholder.com (no big deal at this point, only had a search & replace urls in my ongoing projects)… and now placeholder.com have been being recently bought by some warehouse place renting (for the domain SEO ranking I guess 🙄).

So I decided it was time to buid our own placeholder image generator to be independant of that.
I talked about it with Milia and she ended up having a working prototype pretty quickly.

For now it’s on beta because we didn’t had the time to make a proper landing page with branding & fancy things, so it’s very… minimalist.

However the essential infos on how to use the service are here. And if you were using placeholder.com, our API is very similar so you shouldn’t be lost.

Features

It’s the kind without photos (unlike Lorem Picsum), with informations displayed to help debuging when you have to integrate optimized and responsive visuals:

size ({width} or {width}x{height})
format (png, jpeg, svg, webp, avif and heif)
dpr (inspired by imgix's dpr attribute if it can save you some time doing the calculation yourself)
and even a light/dark mode

All that to easily be sure the right image is showing when you want to.

would for example render this:

Infrastructure

Behind we use Netlify’s On Demand Builders to generate images only when needed and cache them as long as possible (Netlify say 10000 cached max so depending of the usage, we’ll see if we need to put a caching CDN in the middle to help with the cache).

Also that way we take avantage of Netlify’s CDN to make it fastly (and always) available pretty much anywhere is the world.

And overall so far it cost me only a domain a year.

Improvements we're considering

Adding JPEGXL (.jxl). It's for now not suppored because it’s not packaged inside libvips (the image processing library used) by default. That would require to make an extra step to compile our own version version libvips with libjxl. And then make sharp (the node package around libvips we use in the serverless function)
Make an interactive version of the example URL (currently at the top of the landing) where visitors could enter their own values, have an preview displayed dynamically + a button to copy the URL in their clipboard
Make interactive examples with <picture> code on one side and result on the other, with toggles to showcase differents situations (browsers not handling a format, DPR changes, or viewport resizing)

To conclude

First, if you have sucessfully read everything: bravo! 😅

Secondly: This is still in beta because we want to be sure everything is working as expected. And potentially have a first wave of feedbacks to fix the more problematic problems. So you are more than welcome to test it and reach us if you have any feedbacks, problems, ideas for things to improve, anything!

Don’t Hesitate ❤️

Accessibility and CSS customisation in Mastodon: The “Publish” button

2023-07-19T21:43:16Z

For context since its v4.0, Mastodon changed the post button's label previously called “Toot” to “Publish” for clarity reasons. However many people were attached to that historically funny label, and due to its limited customisability Mastodon wasn't allowing admins to setup a custom label for this button.

At this time I've seen many instance admins sharing a CSS hack to customize that label and reverse that change or just be creative. It was possible because Mastodon allows admins to apply additional custom CSS to their instance through their administration panel (Site Settings → Appearance).

However I'm not sure everyone knows the accessibility issue who come with: screen readers will read (and speak) both of the labels.

Why? Let's start with taking common snippet I seen (found here and here for example):

.compose-form__publish-button-wrapper button {
  text-indent: -9999px;
  line-height: 0;
}

.compose-form__publish-button-wrapper button::after {
  content:'Toot!';
  text-indent: 0;
  display: block;
  line-height: initial;
}

The original label will be read by screen readers

Screen readers won't read(/speak) hidden content in a web page. And for being hidden its requires to match one of these conditions :

contains a display:none
contains a visibility: hidden
take no space in the page (this one is tricky I agree)

In our snippet, the first two conditions can't be used since it would hide completely the button.
So the trick was to:

Throw the text backward with text-indent:-9999px (ew a magic number 🥴)
Remove any-height to the text with line-height:0
Use a pseudo element (here ::after) to create a child element inside button and fill it with the custom label through the content property.

With that made, our original label still being rendered, because even if it's thrown backward and its line-height reduced to 0, your text will still take some space:

line-height: 0 won't hide text outside of its height
the text still have a non-null width

So there is a good chance that the original label will still be read by screen readers.

The content property is also read by screen readers

It's a misconception I've encounter several time while talking to other developers. Maybe because since it's in CSS it shouldn't end up in the accessibility tree? Well it does.

I haven't made a test on all screen-readers myself, but someone did in 2017. I don't have more recent stats but since it's the behavior expected in the W3C specification, I think it's safe to imagine it's gonna be more adopted through the years.

What screen readers will probably end up reading

“Publish!Toot!” (or “Toot!Publish!” if :before is used instead of :after).

I haven't figured a CSS-only way to either hide the original label for screen readers too or hide the custom label for screen readers only. If someone have an idea (and tested it), I would be happy to edit this post to share the solution!

To conclude

If you're a sighted user and wanna use this snippet just for yourself (with a browser extension like Stylus), go for it, enjoy!
However I wouldn't advise deploying that kind of hack instance-wide.

How to make colored placeholder on Hugo

2020-03-17T18:41:53Z

While using Hugo as a static site generator, I've found a way to generate a colored placeholder with a little trick.

I used it on my music sharing website for example:

The trick is pretty simple in itself:

Firstly use the Hugo's image processing to generate a version of your image resized at 1px by 1px (your image must be a page resource).
Secondly generate a base64 version using the `base64Encode` function.
Then add it as an inlined background-image using the base64 version prefixed by the media type. That way this image not gonna be an external resource and will be visible before your final image.
Finally specify your image size to define a space for your placeholder to expand

The final result will look at something like that:

{{ $original := resources.Get '/img/your-image.jpg' }}
{{ $visual := $original.Resize "x400" }}
{{ $placeholder := $visual.Resize "x1" }}
<div style="background-image: url(data:{{ $placeholder.MediaType }};base64,{{ $placeholder.Content | base64Encode }});">
  <img src="{{ $visual.Permalink }}" width="400" height="400">
</div>

To go a bit further, I can imagine a solution where you generate a placeholder of 50x50px and add a background-size: cover in your css to have a blurred version for your placeholder.

Don't hesitate to contact me if you use this trick on your own project. I'm always curious of what can be done with it!