Notices by Nolan (nolan@toot.cafe), page 8

The web is capable of so much more than people are doing with it nowadays. A lot of the problems are business incentives (ads, trackers, third-party junk) and cargo cult (bloated toolchains, bloated deps, a main thread that doesn't scale).

We're waiting for the next Ajax/Web2.0/whatever revolution where somebody comes up with a bold new design that's better than everything that came before.

I guess I wanted to prove to myself that it's possible to write a webapp that isn't slow and bloated and terrible and all the things that people say about the web these days.

If I have one regret (or two) with Pinafore, it's that

1) the animations could be a lot nicer, and
2) the offline support could be a lot better.

All the APIs are there. It could have gorgeous intra-page animations and flawless offline support, just like a native app. I just didn't manage to do it. (yet)

If it had been me 7 years ago, I would have done it as an Android app. I was really into Android development at the time.

If it had been me 10 years ago, I'd have written it in… I dunno, Python? So Flask or something?

But these days I really like the web, so I wrote it in Web™

@tootbrute Thank you. 😊

I can't believe I wrote an entire Mastodon client.

@corbin This doesn't do exactly what shadow DOM does, but if you're looking for layout perf improvements, then containment is definitely the way to go. :)

CSS containment is still kind of mysterious to me, although I think the fundamental ideas behind it are good. Browsers already do a ton of optimizations to try to reduce re-layouts of unrelated parts of the DOM, but it's much better if you can tell the browser yourself what to update instead of relying on heuristics.

Not sure how I missed that CSS containment shipped in Firefox 69: https://developer.mozilla.org/en-US/docs/Web/CSS/contain#Browser_compatibility

I actually use CSS containment in Pinafore to optimize some parts of the DOM that should have their layout calculated independently (modals, virtual list items, etc.). I'm curious to know if perf actually improved in Firefox 69.

@raucao I don't think Pinafore would need to be forked to support KaiOS. I just might have to sniff it and slightly alter the keyboard shortcuts (e.g. up/down/left/right behaves more like tabbing through focusable elements).

@luka I use FastMail's calendar, which works with DAVx on Android via CalDav.

@raucao I've been meaning to grab a dev device and try to figure out if I can get Pinafore to support KaiOS. It doesn't seem obvious to me that it will work out-of-the-box, because:

1. KaiOS is based on a slightly older version of Firefox; up to now I've just targeted the latest version
2. The screen is really really tiny; up to now I've set the iPhone 4 as my minimum bar for a tiny screen
3. It doesn't have a touchscreen, so keyboard navigation has to be impeccable even on the small screen

@Chris It's not exactly the same. E.g. if you copy-paste HTML into it, then it will become actual HTML instead of escaped HTML-as-text. I think there may be other differences from a screenreader perspective.

@garrett @codesections Hmmm actually now that I think about it, using a ResizeObserver on the mirror element may actually be the best bet, because then you only change the visible element's height when it actually needs to be updated. This is an interesting idea; I may toy around with it a bit. Thanks! :)

@garrett @codesections Yeah the "input" event is exactly what I'm subscribing to to listen for changes. Effectively it happens on every keypress.

The article is interesting; the concept of a "mirror" element is neat, although I don't think it solves much here. Effectively this is what the JS solutions I've seen do, but with a single element. They set the height to 0 and then check what the overflow is, and then set it back. So you do 2 layouts each time. Same diff for mirror element AFAICT.

@Chris That's what I'm referring to with the <div> solution.

@djsundog Yeah! It's weird that they're like two completely separate code paths. Also I think some editors even use <canvas>. It's wild out there.

@codesections Another alternative (which I explored), is to only calculate layout in a requestIdleCallback(). That way, it doesn't have to run layout on every frame, only when the UI thread is actually free. The problem is that I think it looks ugly - sometimes there are delays where it takes a split-second for the textbox to resize to the right height.

I've considered trying to write a custom web component to do the <div> thing, but I worry it wouldn't work a11y-wise for some edge cases.

@codesections Yeah but that would be a heuristic, and it's probably not possible to get it right. For instance newline characters change the height more than a letter character, and some letters are wider than others. In practice you have to just check every time anything changes in the <textarea>.