I don't know about you, but as far as I'm concerned, I mostly use SASS for 3 reasons:

• To be able to nest declarations

• To split my css into multiples files

• To use variables

As it turns out, if you are using esbuild and targeting a browser that supports css variables (that is, pretty much everything since 2018), you can basically ditch sass and just use esbuild to compile your css.

The magic part of your package.json looks like this (and yes, using bun, even if I'm on windows and bundows had some issues at launch) :

{
  "name": "my project",
  "module": "./public/assets/js/index.js",
  "dependencies": {
    "esbuild": "^0.20"
  },
  "scripts": {
    "build": "esbuild --bundle --minify --loader:.woff2=file --target=safari15.4,chrome88 ./src/css/index.css ./src/js/index.js --outdir=./public/assets",
    "watch": "bun run build -- --watch",
    "start": "bun run build -- --servedir=./public"
  }
}

Nesting declarations

Only supported by browsers from 2023, native css nesting is not ready yet for public consumption at the time of writing this article. But by using esbuild, you can transpile easily your nicely nested css to plain old expanded css.

The syntax is almost the same as the one from SASS.

Splitting files

Again, using esbuild, you simply @import your files and they will be bundled automatically. If you are including woff2 files for local fonts, don't forget the --loader:.woff2=file part of the script.

CSS Variables

On this one, I even think SASS variables are less powerful that CSS variables. It's so cool to have fallback values, to be able to change variables based on media queries, inject them in Javascript, use them in math representation...

I'm still a bit sad about not being able to use properly oklch colors. Yes, they are converted automatically by esbuild, but then you cannot use them as part of a formula, which is, I think, the main reason behind using oklch.

And it seems I'm not the only one, since I've recently read these two articles:

https://heydonworks.com/article/what-is-utility-first-css/

https://nuejs.org/blog/tailwind-misinformation-engine/

Which I highly recommend, obviously.

But it works!

Yes, sure it works. But at what cost ? In order to make tailwind work, you need to have a build pipeline to analyze which utilities are used in order to include only them. Not possible for you ? Too bad !

By using only utilities (and I'm not saying utilities, as such, are bad... I do like having a little spacer utility here and there or a flex class to do flexy stuff), you end up with a big pile of classes in your html. Sure you can refactor that into a custom class... but isn't that basically writing old, traditional css then?

<!-- Before extracting a custom class -->
<button class="py-2 px-5 bg-violet-500 text-white font-semibold rounded-full shadow-md hover:bg-violet-700 focus:outline-none focus:ring focus:ring-violet-400 focus:ring-opacity-75">
  Save changes
</button>

<!-- After extracting a custom class -->
<button class="btn-primary">
  Save changes
</button>

And why on earth would I want to use @apply when I could just write css ? Where I could just, write things, refresh my page, see the changes ? (You can do that in tailwind, but not without tooling).

And in this specific example, it's very likely that you would actually have two classes. A global btn class, and a btn-primary variant. So even this example taken straight from Tailwind docs is not quite realistic. How do you split these properties in two in Tailwind? I don't know (it's probably possible, but since I don't use it...),

What about customization ?

So you have your pretty tailwind.config.js file where you store your configuration.

But you know, css can have configuration too, even without using scss or anything.

    colors: {
      'blue': '#1fb6ff',
      'pink': '#ff49db',
      ...
    },

Could really just be:

--color-blue: '#1fb6ff';
--color-pink: '#ff49db';

That works just fine :-) And you can scope them if needed. Make them responsive. Have fallback values. So if you want a design system, as advertised as one of the strengths of Tailwind, you could very well do something like https://www.pollen.style/.

My dislike for Tailwind is very similar to my dislike for Typescript. I don't like adding a tool unless it really brings a big added value. Most of the time, the cost of adding/learning/dealing with upgrades/changes of version of these tools are not worth the effort. Regular css and js is actually quite fine these days (I wouldn't have said that 5 years ago, but here we are).

Type safety

This is probably the biggest argument... And while it's nice and convenient to be able to declare types directly, you can do something quite similar with jsdocs.

function add(a: number, b: number): number {
  return a + b;
}

/**
 * Add some numbers
 * @param {number} a
 * @param {number} b
 * @returns {number}
 */
function add(a, b){
  return a + b;
}

You might argue this adds quite a bit of boilerplate, but in most cases (something other than adding a and b) you would probably end up adding a docblock anyway to document the function usage, what the parameters actually do (not just their type...)... And best of all, with jsdocs, you could generate documentation from all this.

Detect errors

When jsdocs is used, you can detect errors statically in just about the same way. Just create your jsconfig.json.

{
  "compilerOptions": {
    "checkJs": true,
    "maxNodeModuleJsDepth": 1
  },
  "input": ["src"]
}

No need for typescript here...

Interfaces ?

interface Person {
  name: string;
  age: number;
}

const person: Person = {
  name: "Bob",
  age: 30
};

Is this really better than

/**
 * @typedef {Object} Person
 * @property {String} name
 * @property {Number} age
 */

/** @type {Person} */
const person= { name: 'Bob', age: 30 };

And again... what if you need to document some other things along the way ?

Conclusion

This is not to say that Typescript is bad. I'm sure it can help teams producing quality code. For my part, I don't like leaving up to some bundler to convert my code to something I don't control. I enjoy running native js code on the browser with no conversion whatsoever.

In any case, please stop saying that there is no way to type data in js without using typescript :-)

I recently published pop-notify a custom element that is framework agnostic, fully accessible and html friendly. You can use it with any framework. It works great with bootstrap's toasts. You can use its default styles if you want. Or you can go on and make your own thing.

Here is the playground

And here is the repository

Did I mention it's html friendly ? If you use something like htmx, this might just be a great way to send toast notification along with the html over the wire. Any notification will reassign itself to the toast container and be nicely displayed in a popover container (if your browser supports it, otherwise it's going to be a good old fixed div with a z-index).

I hope you have fun with it :-)

It is now easier than ever to create a color palette system using just a handful of css variables. Simply set the lightness from 0 to 100%, then, set up your chroma (an average value of 0.2 works well, but you might want to lower this to 0.10 or 0.15 for softer tones, or crank it up to 0.3 or more for vivid colors), and your hue (starting with 0 being pink, then move it up to 360... being pink again. Increments between 25 and 50 work well).... and you are good to go!

Here is a simple example with APCA contrast value being written in it to assess accessibility.

Useless emails

The e-Box Enterprise aggregates messages from all sources for your company. Each time there is a new message, you get a notification by email telling you there is a new message available.

But that notification doesn't contain any information. Is it an important message? Is it urgent? Is there a deadline?

You don't know! So, each time, I need to connect to check what this is about. And most of the time, it's useless stuff like VAT notification.

I wish there was more information in the email: sender, type of message, and deadline if any.

EDIT December 2023 : good thing ! This is now a thing, they finally included the subject of the document :-) And I get the email in my own language.

So slow

Since you don't know what the notification is about, you need to connect. So, first you need to identify using ItsMe. That's not too bad, just make sure you get your phone near you.

And then, you enter a wonderfully (ahem) designed angular application that makes TONS of ajax calls to load data from various sources. So, obviously, you get a wonderful loader with no idea of progress, because how could they know how long it's going to take ?

And when I say it's slow, it's like, really slow. Some calls take up to 13 seconds. When loading the e-Box, you have time to take your coffee. Sometimes it does load fast (when things are cached, I guess), but sometimes, half of the fetch calls fail with 403, 500 or CORS errors.

And sometimes, it doesn't work

Once your coffee is finished, you get back to the app, and what do you see? You would expect a list of messages, but sometimes, it doesn't work, saying you don't have access to the application. Which is false, because sometimes it works just fine, with the same credentials, same urls, same browser, same everything.

And when it does manage to load the list, sometimes it fails at replacing the values. Ah, the good old {{value1}}...

And when it works, it's not really helpful

When everything works, you can read the message. So here I have a friendly message of MyMinfin... as a pdf attachment. So you download the pdf, called with the very unique name "message from myminfin" (i got another one which was called "mainDocument.pdf"... so you know, naming things is hard I know).

Do they know you can display the pdf in an iframe ? Nope...

And what's inside the pdf? You guessed it, a new button ! Because, you know, it would be too hard to put the actual message from MyMinfin in the e-Box, it's much more fun to have to go somewhere else to read the message.

So you go to MyMinfin. Where sometimes you need to login. AGAIN. Then you need to pick if you login for yourself or for your company. The whole thing cannot work automatically, because you clicked in a bloody link in a pdf. Then you go to a list of messages. Then you download another PDF.

And then you realize it's not relevant and you just lost 15 minutes out of nowhere.

Welcome to productive Belgium :-)

When it comes to select an (open source, obviously) editor, there are a few choices that comes to mind. The most obvious being: TinyMCE. Did you already try to bundle this as a custom element (yes, there is one, but it's basically a glorified loader) ? It leads to a file of about 1mb. That's a lot if you are just looking of adding a couple of styles to your text.

I've also tried Jodit, but that's not much better: around 700kb. Still a bit much in my opinion.

Let's try Squire

Squire is a lightweight editor that doesn't use the deprecated exec command. By default, it doesn't contain an ui so I had to create one, but that was quite straightforward. You can see an example below.

The good news? Its weight is about 60kb, ui included. On top of that, you need to add DOMPurifier if your browser doesn't support the sanitizer api.

I think that's a really nice result! The only issue I had was using paragraphs instead of divs by default.

But by design, Squire is also limited. What if you need to extend it? Let's have a look at another contender.

Tiptap, the headless editor

Titap is an extensible, headless editor. Just like Squire, it doesn't contain a ui. But not problem, I just used the same as the one I've built for Squire :-)

Tiptap is built on top of ProseMirror, making it much more powerful, but also a bit more heavyweight. For example, ProseMirror includes its own sanitizer thanks to its dom parser, so it's bound to be heavier than an alternative that can use the sanitizer api.

How does it look? You bet: just the same :-) Its weight? Just about 300kb, so 5 times more than Squire, but it includes a few more tricks by default (like, a proper code block, horizontal rules, and typography rules...).

Why would you want to use it instead of Squire? Because it's extensible! You can add many plugins so for more complex projects, that's definitely the way to go.

And that's it for today! Happy editing :-)

Using a polyfill ?

The obvious solution is to use a polyfill, which uses DOMPurify under the hood. The issue with this is that unless you use feature detection to include the polyfill, you are going to include it in Chrome even if you don't need it. And if you use feature detection, you need to wait until the polyfill is loaded before using any code using the polyfill, which may be difficult to detect.

A simpler approach

In my case, all I needed is the setHTML. I don't really care about the rest of the spec.

So let's see what we got:

/**
 * @link https://web.dev/sanitizer/
 * @link https://sanitizer-api.dev/
 * @param {HTMLElement} el (NOT a template element)
 * @param {string} html
 * @param {Boolean} force
 */
export default function setHTML(el, html, force = false) {
  //@ts-ignore
  if (window.Sanitizer && !force) {
    //@ts-ignore
    el.setHTML(html);
  } else if (window["DOMPurify"]) {
    el.innerHTML = window["DOMPurify"].sanitize(html, {
      WHOLE_DOCUMENT: false,
      FORCE_BODY: false,
    });
  } else {
    el.innerHTML = html;
  }
}

/**
 * Set the global DOMPurify if missing and if Sanitizer api is not available
 * Call this with await before any call to setHTML
 * @param {Boolean} force
 */
export async function loadDOMPurify(force = false) {
  //@ts-ignore
  if ((!window.Sanitizer || force) && !window["DOMPurify"]) {
    //@ts-ignore
    window["DOMPurify"] = (await import("https://cdn.jsdelivr.net/npm/dompurify@3/+esm")).default;
  }
}

Import this little snippet, and you are good to go. Call await loadDOMPurify before any code using the setHTML helper. This will load DOMPurify using dynamic import from the cdn (or feel free to use your own local path for this).

Neat, no? :-) I've been using this in my WIP formidable elements library.

EDIT: it seems the current draft has been deprecated, see here: https://developer.chrome.com/blog/sanitizer-api-deprecation?hl=fr

But recently, I've built a SPA (to be more precise, a PWA-SPA, which is a funky acronym if you ask me, or should we say a PSPWA ?). And I'm also dealing with ajax loaded interfaces for my admini panel.

And you know what? Suddenly, document.ready is not so magical anymore: your ajax loaded content does not trigger DOMContentLoaded . Your nodes get initialized twice. Event handlers are getting crazy. Stuff gets removed from the DOM. Not nice.

A more robust initialization phase

What's becoming very clear, is that as soon as you do anything a bit more complex, you cannot rely on DOMContentLoaded anymore. Take Unpoly for example. They have this special up.compile function which parse each fragment loaded into the page. Nice, but then you need to tweak everything to work with this. And what if you want to switch to Turbo for example?

The first step is to make sure you don't initialize things twice. This can be easy and simple. Simply call a initialize function which takes care of doing everything you need and add the element to a WeakSet. It won't prevent garbage collection once it leaves the dom, and you can just fire your big "init" function which contains multiple initialize calls.

But you could make your life easier

Most of the time, you want to listen to event, and add some initialization code. Therefore, calling addEventListener yourself might be a bit verbose, so you can go this way.

Again, the goal here is to prevent the same handler to fire twice, so in our case, we create a registry of events for each element and only add it once. And then, all you need is listen('.my-elem', 'click', someHandler)

But what about ajax content?

Yes, I hear you. This is all nice and well, but you still need to call your big old global init function each time some part of the dom changes. What if somehow this could be done automatically?

There are three ways to deal with this:

• Event delegation: since we listen at document level, new element works transparently

• Mutation observer: bind/unbind behaviour dynamically as stuff gets added to the dom

• Self initializing elements: with custom elements, it's now trivial to have elements that take care of themselves

Let's look at these solutions.

Event delegation

I didn't find a library I liked, so, I've tried a little something on my own. That also let me test and try things :-)

It works like listen above, but instead of adding a listener to the element, we add everything to the document. We define a global listener. Then, we leverage closest to match the actual target during the capture phase.

Mutation observer

This is the big one. Inspired by jquery.entwine the entwine function lets you define a set of definitions for a given selector. For example:

    entwine('.my-elem', {
      click: function (e, el) {
        console.log("click", e, this, el, el === this);
      },
      mouseenter: (e) => {
        console.log("enter", e);
      },
      mouseleave: (e) => {
        console.log("leave", e);
      },
    });

There is also support for connected and disconnected events thanks to the mutation observer. I added namespaced definitions support like in the original lib, otherwise multiple definitions matching the same selector would get merged together.

Self initializing elements

Last, but not least, a topic I've already discussed on this blog: self-initializing elements. If you can afford to go the custom elements way, they will initialize themselves.

The only real downside with this is that is that you are forced to use dedicated html, so that may not work too well if you cannot change how your html is done.

Check the repo for modular behaviour

Also worth a visit

• Event Listener from thednp

• Unpoly.compile

However, things are not so great when you use the querySelector and querySelectorAll api, because it returns a generic Element. How to fix this ?

The issue

You want typesafe js, so you enable this in your project in the jsconfig.jsonfile

{
  "compilerOptions": {
    "target": "esnext",
    "module": "esnext",
    "moduleResolution": "node",
    "lib": ["es2017", "dom"],
    "allowJs": true,
    "checkJs": true,
    "noEmit": true,
    "strict": false,
    "noImplicitOverride": false,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "esModuleInterop": true
  },
  "include": ["src/*.js"],
  "exclude": ["node_modules", "./test/"]
}

Let's say you have a form with an input. Maybe you do something like this:

const myInput = document.querySelector('form input');
myInput.checked = true; // you get "Property checked does not exist on Element"

The obvious fix: add some inline jsdoc

/**
* @type {HTMLInputElement}
*/
const myInput = document.querySelector('form input');
myInput.checked = true; // yay!

This works, but it's not so great when you need to deal with collections. Sure, it works, but it's not exactly developer friendly.

document.querySelectorAll('form input.checkbox').forEach((input) => {
    input.checked = true; // Huho... again ?
});

document.querySelectorAll('form input.checkbox').forEach(
/**
* @param {HTMLInputElement} input
*/
(input) => {
    input.checked = true; // yay!
});

A better solution?

Introducing q the only function you need to query your dom! If you were missing jQuery ease of use, this might just be your new best friend.

/**
 * Query elements in a typesafe manner
 *
 * You can declare your owns tags in the HTMLElementTagNameMap namespace
 *
 * ```js
 * // my-tag.d.ts
 * declare global {
 *   interface HTMLElementTagNameMap {
 *      "my-tag": MyTag;
 *   }
 * }
 *

*

• @template {keyof HTMLElementTagNameMap} K
• @param {K|String} tagName Name of the element, or global selector string (returns any element).
• @param {String} selector Selector appended to the type. If it contains a space, type is ignored.
• @param {Document|HTMLElement} ctx Context (document by default). If a context is specified, :scope is applied
• @returns {Array} */ export default function q(tagName, selector = '', ctx = document) { // Don't prepend the type of we are asking for children, eg: #my-element type selector = selector.includes(' ') ? selector : ${tagName}${selector}; // Needed for direct children queries // @link https://developer.mozilla.org/en-US/docs/Web/CSS/:scope#direct_children // Needed to avoid inconsistent behaviour // @link https://lists.w3.org/Archives/Public/public-webapi/2008Apr/0251.html if (!(ctx instanceof Document)) { selector = :scope ${selector}; } return Array.from(ctx.querySelectorAll(selector)); } ```

Let's revisit our previous examples

const myInput = q('input', 'form input')[0];
myInput.checked = true; // yay!

q('input', 'form input.checkbox').forEach((input) => {
    input.checked = true; // yay!
});

Not sure yet if it's worth it to make another function that returns only one element using querySelector, but that would be easy enough to create on your own :-)

Some extra goodies

You might have noticed that the code does a little bit more than that. Let's see the extra goodies included.

You can easily query an element and add more specificity.

const inputs = q('input', '.checkbox'); // will query input.checkbox

When querying children nodes (as soon as you have a space in the selector), the tag name is ignored.

const inputs = q('input', 'form input'); // will query form input

Fragments are properly scoped by adding :scope automatically. This is almost always the desired behavior because it allows using direct selectors without extra syntax, and it will make sure you don't get elements outside of the context.

This scope issue was so bad in even wondered if it makes sense to allow this third parameter.

const form = q('form')[0]; // will query form
const formInputs = q('input', '.container .checkbox', form); // will query :scope .container input.checkbox
const directInputs = q('input', '> .checkbox', form); // will query :scope > input.checkbox

You can still query multiple elements if you want.

const mixed = q('label,input'); // still working fine since you can pass a regular string, but obviously, you don't get a proper type back

You get an array as a result... meaning, you can map, filter... with properly typed element inside your callback function.

const allNames = formInputs.map((el) => {
  return el.getAttribute('name');
});

You can extend the list of tags if you use custom elements.

declare global {
   interface HTMLElementTagNameMap {
      "my-tag": MyTag;
   }
}

And let the magic happen.

const myTag = q('my-tag'); // who gets a properly typed element ?

You can play with it here (check the console).

Recently, I made a small one-pager and I decided to give it a try. On this website, I'm using bootstrap 5 and I'm going to show you how I manage to get it working.

What are we working towards?

The end goal is to have something like this:

<link href="/css/default.min.css" rel="stylesheet" />
<link href="/css/mobile.min.css" media="screen and (max-width: 767.98px)" rel="stylesheet" />
<link href="/css/tablet.min.css" media="screen and (min-width: 768px) and (max-width: 991.98px)" rel="stylesheet" />
<link href="/css/desktop.min.css" media="screen and (min-width: 992px)" rel="stylesheet" />
<link href="/css/print.min.css" media="print" rel="stylesheet" />

At the same time, in my source file, I don't want to split my logic between files. This means, that the following scss code:

// This should go to default.min.css
.col-separator {
  border-right: 1px solid $primary;
}
// This should go to mobile.min.css
@include media-breakpoint-down(md) {
  .col-separator {
    border-right: 0;
  }
}

Should get split properly between multiple files. While scss is really great at combining files, it does not provide much out of the box to split files.

Getting your structure ready

First things first, let's get our files in a proper structure. In my workflow, where I'm using plain dart sass cli tooling, I need to find a way to have my files sent to the /public/css folder. I do it like this:

 "scripts": {
    "build": "esbuild --bundle --minify --format=esm --sourcemap src/index.js --outfile=public/js/index.min.js",
    "start": "npm run build -- --servedir=./public",
    "watch": "npm run build -- --watch",
    "compile-css": "sass scss/dist:public/css --load-path=node_modules/",
    "compile-min-css": "sass scss/min:public/css --style compressed --load-path=node_modules/",
    "watch-css": "npm run compile-css -- --watch --poll",
    "watch-min-css": "npm run compile-min-css -- --watch --poll",
    "prefix-css": "postcss public/css/*.min.css --replace --use autoprefixer",
    "build-all": "npm run build && npm run compile-css && npm run compile-min-css && npm run prefix-css"
  }

I create two folders: one scss/dist and one scss/min. Both of them get their own compile command with dedicated settings. If you only want minified files, it gets even simpler.

In these folders, I create the following files:

• default(.min).scss : this is the general stylesheet that get non specific styles

• desktop(.min).scss : for desktop (> 992px)

• mobile(.min).scss: for mobile (< 768px)

• tablet(.min).scss: for tablet (between 768 and 992px). Not sure this one is actually worth it, feel free to remove it and put these styles in default instead.

The content of these files is the same:

$css-sheet: "mobile"; // change according to current file
@import "../bootstrap/bootstrap-common";
@import "../index";

The only difference is this mysterious css-sheet variable.

Let's get the print out of the way

But before diving into the media queries, let's go the print styles out of the way. Bootstrap 5 removed their print styles, so if you want to restore them, you need to create a distinct file. You can find its content here, but the general idea is like this:

• Creating some nice default print styles

• Include print utils through a reduced utilities api

• Remove the print utils from the regular utilities api to prevent their inclusion in default.css

Ok, simple enough. Let's have a look at the media queries now.

Sending media queries to distinct files

The main issue with my first snippet is that there is no way to know what should belong to the "default" stylesheet. Let's solve this:

@include media-default {
  .col-separator {
    border-right: 1px solid $primary;
  }
}
@include media-breakpoint-down(md) {
  .col-separator {
    border-right: 0;
  }
}

Notice the updated media-default mixin. This is actually kind of nice because it allows you to treat "base" scss code into its own block. The issue with this is that my approach doesn't work for code that is not organized to work with it, so base bootstrap code will have to be sent to default.scss.

Remember the little css-sheet variable? This variable will help us to track which file we are currently processing and include (or not) the content based on it. This require overriding the default media queries mixins with the following code. Again, feel free to read to code (warning! while it seems to be working all right, there might be edge cases that I've missed), but the basic idea is this:

• We know that some media queries are only relevant to a specific breakpoint and don't need to be included for some viewports (eg: include media-breakpoint-down(md) should only be included in mobile.css).

• Knowing that, it's easy enough to process the media query mixins according to the current sheet being processed. Based on that, we ignore or include the content. We can even get rid of the top level media query if it matches the stylesheet criteria.

• Our new mixin media-default allows us to flag content that should be included in the default.css and ignored on viewport specific sheets.

And that's it! As mentioned, this approach doesn't help us with base bootstrap code, but any custom code will be split properly into its own file.

At the end of the day, for my project, it proved not so effective because most of the code still belongs to default.css and due to bootstrap size, css splitting by viewport does not bring many benefits. But I can imagine that a framework engineered for these viewports or for large websites, this approach could provide a real size reduction.

What is the issue?

As strange as it may sound, Bootstrap toast stacks are not well-designed for animated toasts (in my opinion, anyway...). This means that it looks great for static toasts, but as soon as you try to add or remove toasts in them, they move in a very "jumpy" way due to the display: none being applied at the end of the animation.

This can be seen in the codepen below

What is the solution?

The solution is simply to animate the margin (top or bottom, depending of the position of the order of your stack) by the height of the toast. This require disabling the display:none being applied by default and in my case, it's not an issue, since I'm working with dynamic toasts that get removed from the dom anyway (after some delay...).

These changes have already been integrated in my bs-companion library and can be seen lives here.

To tab or not to tab

The issue is the following: while you type, you show suggestions. The focus is still in the input field, and yet, you should somehow show to the user what is the currently matched suggestion (I'm using bg-primary to show this). I cannot use hover styles, because you can hover a proposal, and yet, change suggestions with the arrow key. I cannot use the focus styles, because they don't exist as a pseudo class (and I really want to avoid any extra css for my library). Also, focus styles are ugly :-)

But the, I realized that when pressing tab, I was moving the focus to the suggestions. At first, it seemed like a great idea: this way, users can tab through proposals. And at the same time, it also seems like a really bad idea: because users need to tab through all proposals to move to the next input field.

Tab vs arrow keys

I wondered: how does behave a native datalist ? Turns out: you need to use arrow keys to move through proposals, and tab move you to the next element. So I decided to do just that: I added a tabindex=-1 and it works fine. You can still use arrow keys as before to move through suggestions.

But is it accessible? How would the user know which proposal is selected if he is blind? I guess I can use Live Regions but I'm not sure how well that is supported (sometimes, the specs are wonderful, but real life isn't).

At least, with tabs, you know for sure that when focusing an element, it will get announced. I'm still on the fence regarding this, but I will definitely investigate and make sure it's working as intended for version 1.1.

Full demo

If you are curious, here is a demo of the new library

You can also head to the repo

Extra tip: using regions

Since I didn't want to split my library into multiple files, but still keep it manageable, I discovered the region/endregion syntax in vs code that allows to collapse/expand whole section of code. It also helps to keep your code structured and grouped in a meaningful way.

// #region REGION_NAME_HERE

... some code

// #endregion

One part in particular is great: push notifications. Now that Safari 16 has added support for them, it's not realistic to actually use this in production.

Show me the snippet

I know, i know... let's get to the point of this article: the snippet.

// @link https://flaviocopes.com/push-api/
// @link https://web.dev/push-notifications-handling-messages/
self.addEventListener('push', function (event) {
  if (!event.data) {
    console.log('This push event has no data.');
    return;
  }
  if (!self.registration) {
    console.log('Service worker does not control the page');
    return;
  }
  if (!self.registration || !self.registration.pushManager) {
    console.log('Push is not supported');
    return;
  }

  const eventText = event.data.text();
  // Specify default options
  let options = {};
  let title = '';

  // Support both plain text notification and json
  if (eventText.substr(0, 1) === '{') {
    const eventData = JSON.parse(eventText);
    title = eventData.title;

    // Set specific options
    // @link https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerRegistration/showNotification#parameters
    if (eventData.options) {
      options = Object.assign(options, eventData.options);
    }

    // Check expiration if specified
    if (eventData.expires && Date.now() > eventData.expires) {
      console.log('Push notification has expired');
      return;
    }
  } else {
    title = eventText;
  }

  // Warning: this can fail silently if notifications are disabled at system level
  // The promise itself resolve to undefined and is not helpful to see if it has been displayed properly
  const promiseChain = self.registration.showNotification(title, options);

  // With this, the browser will keep the service worker running until the promise you passed in has settled.
  event.waitUntil(promiseChain);
});

So what does this do ?

• In your service worker (using workbox is highly recommended), define the listener for push notifications
• Do some checks to see if the push is actually valid
• Support push messages in both plain text and json format. The json format allows us to set custom options for each push message (body, icons, actions...)
• I added an expiration check. Indeed, if the device is offline, it will get the push notifications as soon as it gets online. But maybe your push notifications won't be relevant anymore. If it's the case, simply pass a "expires" property along with the timestamp at which the notification expires.
• And then, show the notification :-)
• (and yes, I added some comments and links to make sure to remember how it works)

Happy coding :-)