I don't use Matrix anymore because our home server is falling apart, and I don't really have a _reason_ to use it anyways.
please email me or message me on Discord instead!
right now very barebones!
- doesn't sort pages quite correctly
- no search function
- still not sure about the UI design aspects
includes refactor of tree generation code
not to be confused with the Minecraft technical update
I'm moving about the pages to be have a more flat, less nested structure.
I feel like that'll improve URLs a lot, making them more readable than ever.
over the years I've learned that flatter is better, and that tagging is generally a much more effective way of organising things.
this doesn't get rid of categories entirely, as I think having the category makes the URL much a bit more readable in the end.
my current vision does include a concept of "major categories" either way.
this allows us to serve a precise Content-Type header for all our pages, rendering treehouse usable in browsers that require one
(like terminal browsers---w3m, lynx)
since initiating the whole liquidex -> riki thing, I've decided that disconnecting myself from "rikiddo" is probably gonna be for the better, and I'm slowly beginning to take on the moniker "riki moe."
client-side time zone adjustment still persists---the server renders them out in UTC, but the client will adjust the date to its timezone during loading.
this shouldn't cause any layout shifting because we use `font-variant-numeric: tabular-nums` (though Recursive seems to use tabular numbers either way.)
to accomplish this, I generalised emoji tooltips to a shared Tooltip class.
in the long run I'd like to transform all existing `title=""` tooltips into these for stylistic consistency with the rest of the website, but this is good enough for now.
I also ended up cleaning up some old code from before the /b rework.
branch permalinks still use /b, but /b?abc now acts as a redirect rather than doing annoying JavaScript garbage
I changed the branch element ID format to accomodate this---now the IDs are of form `b-{id}` rather than `{tree_path}:{id}`.
the old way was stupid anyways.
I hope nothing breaks too majorly because of this.
based on a very simple reading of the SVG's XML to find out its `width`, `height` and `viewBox`
no further parsing is required or will be provided
and you are an excellent test subject
