UI designer and developer. Love CSS, accessibility, and design systems. Occasional illustrator and beatmaker, eternal etymology nerd and probably presently pondering the origin of a citrus fruit or something.

Front-end developer at Mastodon. He/Him. No AI.

Location: Berlin
Website: https://diondiondion.com
Work: https://joinmastodon.org/about
🦆: https://play-duck.com

Last Notes

- reply

Sure. My "defense" of the design was based on the assumption that this "Goodbye" dialog would exist with or without the reminders, in which case, no harm no foul IMO. But if that's not the case, I agree that it's not an effective pattern.
But my original point was that your original post read like you didn't think any attempt at a solution was worth it, which you clarified. So, all good.

2026-06-30 20:48:30 UTC

- reply

Of course it is, and rightly so. I still don't see the issue, have these "Goodbye" messages not always existed? My phone also says "Shutting down" when shutting down. So, IMO, an additional reminder on such a screen is fine. The problem is complex enough that no single technical solution can fix it, and none will completely eliminate it.

2026-06-30 13:44:22 UTC

- reply

If around 40 deaths a year in the US alone aren't enough to _try_ to prevent them... you kind of lost me there.

2026-06-30 12:04:18 UTC

- reply

Can you elaborate on your first point? I'm struggling to come up with an interpretation of it that isn't really, really horrible.

2026-06-23 12:00:49 UTC

- reply

Hi @npub1zdf…6u9l, we had a chat about this and would be happy to accept a PR for this in core. :)

2026-06-19 19:50:52 UTC

- reply

Thanks, that could be great, and totally understandable that you don't want another npm package on your hands. Let me bring it up with the rest of the team next week before you put any work into this, just to check that we want to take this direction, and I'll let you know :⁠-⁠)

2026-06-19 18:15:00 UTC

- reply

Oh, that stylelint plugin for detecting unused custom properties is something we've been looking for! I think the existing lib on npm only works for plain CSS. Would you be interested in contributing this to core, or putting it up on NPM if it's generic enough?

2026-06-13 16:12:36 UTC

- reply

You might want to include this patch, we've received lots of reports of this crashing the main UI: https://github.com/mastodon/mastodon/pull/39408

2026-06-05 11:51:55 UTC

- reply

Oof, that's a long time! And no worries, glad it's working well for you.
We just merged some more tweaks to this for 4.6 to make post navigation more robust and reduce the risk of "getting stuck" in a list.

2026-06-03 09:32:52 UTC

- reply

We're still not sure what caused this, but we'll make a change for the upcoming Mastodon 4.6 that will limit the compose field's height to make it scrollable, which will hopefully restore the behaviour you're used to.
As a more immediate workaround, does Ctrl + Start/End work for moving the cursor to the start or end of the field for you?

2026-06-03 08:28:28 UTC

- reply

Thanks. Which OS are you on? For me (on MacOS), PgUp/PgDn only scrolls within long text fields on other websites, but without moving the cursor.
It looks like our compose field never stops growing, thus never gets its own scrollbar, which would explain the behaviour you're seeing. I wonder if this changed compared with older Mastodon versions.

2026-06-03 08:16:51 UTC

- reply

Can you confirm that this is happening on your mamot.fr server? I'm not aware of any changes to the composer's keyboard handling in the version that this server is on, but I can confirm that PgUp/PgDn doesn't move the cursor to the start or end of the field here either. Cmd + Up/Down still does, however.

2026-06-01 21:32:47 UTC

- reply

Ah, thanks for checking! I'm used to it from Firefox and assumed other browsers do the same.
Edit: I wonder if this changed in recent years. For example there's an old stack overflow question about making button text selectable that doesn't seem to be scoped by browser: https://stackoverflow.com/questions/34494405/how-to-select-a-text-with-a-cursor-in-a-button-element

2026-06-01 21:23:04 UTC

- reply

I think `user-select: none` on buttons is the default user-agent style in most browsers.

2026-05-25 11:28:22 UTC

- reply

We're always happy to merge bugfix PRs. It's more complex for PRs affecting UX, but even those are not rejected categorically.

2025-08-21 08:42:53 UTC

#a11y folks, what's your take on this UI pattern that's quite common on social platforms:
A button with a verb label (e.g. "Follow") that, after the button was pressed, changes to an adjective describing the status (e.g. "Following"), rather than being explicit about the action it'll perform when pressed again (e.g. "Unfollow").
Do you find this problematic in practice?
https://cdn.masto.host/indiewebsocial/media_attachments/files/115/065/745/812/804/803/original/dc470de6dac2107d.png