overture VS markwhen

Fastmail shows lists of messages using a progressively-loaded list, where each item is of a consistent height (88px for me, but it can be a few other values too, depending on your configuration—I think 51px is the default). This means that the scrollbar is real and accurate, and you can seek to any point in your mailbox easily (provided your platform allows interacting with the scrollbar, which largely means “on desktop platforms”). But this does cause problems for very large mailboxes, because browsers only support finite lengths.

A few years back, while I worked at Fastmail, we had a ticket come in from an IE user that they could suddenly only access the first few messages in their mailbox. Trouble was they’d gone over IE’s limit, and IE just ignored the entire height declaration in that case, and so you ended up with only the initially-rendered list items available.

The limits I found:

• Firefox: ignores declarations that resolve to a value higher than 17,895,697 pixels (which is a bit more than 2²⁴).

• IE: ignores declarations that resolve to a value equal to or higher than 10,737,418.23 pixels (2³⁰ − 1 hundredth pixels).

• WebKit: clamps values somewhere around 2²⁵ (~33,554,432) pixels; clamping means you don’t need to worry about it so much, since that was the best workaround in other browsers anyway.

And so we ended up with the workaround code at https://github.com/fastmail/overture/blob/41cdf36f3e7c8f0dd1... (the Firefox check was of much older vintage, I just added the IE case). (Nowadays, the IE part is gone again because IE is gone, hooray!)

So yeah, it actually only took about 200,000 messages in the list to hit this limit and fall over, or subsequently just make the bottom of the mailbox inaccessible. 200,000 messages in one mailbox is uncommon, but not at all unrealistic, especially in an “All mail” sort of mailbox.

One uncommon place where clipping is justified at the design level: lazy-loading but finite lists. I’ll use Fastmail’s webmail (on which I worked a few years back) as an example. I could load a list of a hundred thousand emails, and each message in the list is 88px tall (containing four lines of text—approximately, sender and date, subject, and two lines of preview, with truncation on each), so the list container is made to be 8,800,000 pixels high¹, and I can use its scrollbar to immediately jump to any place, and it will figure out which messages to fetch and render based on the scroll position. If the subject line were wrapped, which would be nice at times, you’d lose this ability: you’d have to guess the approximate height of each element, and your scroll positions will be imprecise and you’ll have to make messy adjustments from time to time. Overall it generally won’t be too bad so long as there’s not too much variation in them, but it’s definitely still inferior.

¹ Browser do have limits on how large you can make containers, and handle excess in different ways. IE had the lowest threshold of failure at around ten million pixels, beyond which point it would ignore values; the workaround I implemented in https://github.com/fastmail/overture/commit/8d01c74d8c5d4ae0... came as a direct result of a customer reporting that scrolling was broken in IE in their mailbox with a couple of hundred thousand emails. Firefox breaks a little after 2²⁴ pixels, also ignoring values, so it’s still covered in https://github.com/fastmail/overture/blob/0c9828a5b77ad14383... (note the IE stuff is gone because IE is dead! :-) ). Chrome accepts larger values, but clamps them to about 2²⁵ pixels.

It is, however, interesting to note that Fastmail’s webmail doesn’t use EventSource, but instead implements it atop fetch or XMLHttpRequest. An implementation atop XMLHttpRequest was required in the past because of IE, but it still deliberately doesn’t use EventSource; my foggy recollection from a few years ago is that it had to do with control over timeout/disconnect/reconnect, and handling Last-Event-ID, plus maybe skipping browser bugs in some older (now positively ancient and definitely unsupported) browsers. The source for that stuff is the three *EventSource.js files in https://github.com/fastmail/overture/tree/master/source/io.

The creator of this (Chee Aun) is quite prolific and creative with their work (https://cheeaun.com/projects/).

They created https://cheeaun.life, a timeline of their life, more than 10 years ago (which looks to be kept up to date), which was my inspiration for markwhen (https://markwhen.com).

Markwhen

Looks like markwhen[0]. When making it, which initially started out as a strictly timeline-making tool, I realized it is essentially a log or journal language - write a date, any date, and add some stuff to it. Good for notes, blogging, a calendar, etc etc.

[0] https://markwhen.com

https://markwhen.com

I’ve had a lot of these thoughts when working on markwhen. It’s basically turning into a calendar and planning IDE, pretty excited about where it’s heading.

https://markwhen.com - very cool. however, If I could share with you, I would see the value in following case: if I could connect my calendar(s) to it and see what is going on and overlay it with the data here in comment. Use case is both - for retrospective and for planning (for example if you're preparing the meeting and don't want to share content just yet, or jotting something for time in-between meeting what to do, etc)

I realized just over the weekend that the side project I'm working on is in fact a kind of journaling language. It has passed through a number of iterations, started out as a timeline maker (and still does that best), but at the end of the day is a spec for writing what happened when. Or indeed what you hope will happen in the future - I find it's a good planning tool too.

I find myself actually journaling now that I don't have to think about where I'm going to do it, or in the case of most note-taking apps, which note I should put my current thought in. Journal it first, and if it deserves to be somewhere else, move it later.

The project is https://markwhen.com

https://markwhen.com

Timelines in markdown (gantt, calendar, map, other views)

It's open source (https://github.com/mark-when/markwhen) and there are some paid options for storing markwhen documents in the cloud.

Straddling paid SAAS and open source is a bit tricky and I still haven't figured it out completely yet. I have some sponsors as well as some paid saas clients but it's not quite paying the bills yet... I like working on it though, hopefully I can find the right balance or a different revenue model that works better.

Are you familiar with markdown? If so, try markwhen.