marfle-bark

curlfriend material

  • they/them and she/her

josie! a poly pan lesbian in ATX :3!

snow leopard (snep) + husky (ski) = snepski!!

EN native / ES / DE / YI

Music and other art, games, computing, gardening, chemistry, animals, and more~

I will rechost NSFW, it’s gonna happen, watch out ;3
@alt-snepsk-sex for the lewd account

sometimes i just think about my boyfriend and my girlfriend and it makes me so happy :333

one of those “two greek letters and an ampersand” girls


bsky
marfle-bark.bsky.social
email
josiesnepski@gmail.com

staff
@staff

hi again! it’s been a bit, but that’s just how it is sometimes.

since the last real patch notes post, most of Colin’s and Aidan’s time has been spent on dark mode; implementing what we have now required them to tear out a large chunk of the site style and create a working system for dynamic styling going forward, which ended up taking two weeks! while it’s not 100% done, we have the highest-usage areas of the site covered, future changes should be much more straightforward, and for the time being we’re leaving it there so we don’t spend the rest of the year on it.

we’ve done some digging into the occasional periods of site slowness recently and found some performance issues with the bookmarked tag feed that we believe are responsible for most of it. we thought we had a fix ready to go but unfortunately, while it does fix performance for the users who see the worst behavior, it seems like it makes things significantly worse for a lot of other people, so we’ve rolled it back and are going to keep working on it; if you’ve noticed the bookmarked tag feed being weird over the past day or so, that’s what that was.

also new:

  • fixed an issue causing sharing posts not to work for users in the activation queue.

  • improved keyboard navigation when viewing posts with automatic “read more”s. short version: it should work the way you expect now, mostly. long version:
    • the extremely disorienting behavior of the post content scrolling around inside the box to make the focused element visible should be entirely gone.
    • we’ve also fixed most instances of keyboard focus being able to enter elements hidden behind the “read more”.
    • however, firefox appears not to remove scrollable elements from the tab order even if you set tabIndex="-1"; posts with a read more hiding scrolling blocks (code and preformatted text, mostly, which can be wider than the post box) will still misbehave, requiring you to tab through all of those elements before your keyboard focus comes back.
      • unfortunately, a complete fix would require us to render the post once in your web browser, then completely delete the part of it that’s not visible on your screen so that the browser doesn’t think it’s there to tab into. this is both a pain to implement and would likely lead to noticeable performance issues in the browser, so we have opted to not do it.
    • internally, explicitly-requested read mores are much more straightforward and shouldn’t cause any of the same problems; we encourage folks to use those rather than relying on the automatically generated read more for posts that have a clear-cut introduction. (to insert one, put a line in your post containing only ---, with empty lines above and below it. this is also in the markdown reference.)
  • improved performance when generating the initial dashboard when not following anyone
    • we had some latent issues here which could cause site slowdowns during periods with lots of sign ups — if, say, a bunch of folks from tumblr decided to sign up at the same time.
  • our status page has incorrectly not been reflecting periods of increased latency since mid-August; we checked our status provider and the integration with our internal latency alerts had mysteriously disappeared without any notice. this issue is now fixed, and we’ve set up alerts for the status page on our internal chat server so we can make sure everyone else is getting notified. thanks to everyone who got in touch with us to let us know!

general eggbug plush update: currently waiting on our first prototype from makeship! we’re just as excited as you are :eggbug-smile-hearts:

that’s all for this week! thanks, as always, for using cohost :eggbug:


You must log in to comment.

in reply to @staff's post:

we encourage folks to use those rather than relying on the automatically generated read more

I may have to see how that would work when I'm making a post that's all contained within one <div> element with a background. Because I don't think I can do that within any HTML element. But I might be able to adjust padding and just have a readmore in between two <div>s without it looking obviously seperate...

yeah, to be clear we don't consider this a one-size-fits-all solution! if you're making something that's one long paragraph then we're not gonna demand that you go out of your way to figure out a fancy way to break it up. we just wanted to remind folks that the option is available.

Yeah of course, sometimes it might not work well, and I might just not be able to make it work well with a tiled background. But I'm curious to try! It sounds like a good challenge for me as I try to learn more CSS.

Regarding the rendering of posts with an implicit read-more, and with me coming from a background with no experience with web dev, but a bunch of experience in backend software engineering - my first thought was "why not insert a read-more marker in the post at publish-time, rather than render-time, so that there's very little difference in rendering between an implicit and an explicit read-more?

right now, the automatic read more appears after two screenfuls, as determined on the client side; we could absolutely change the behavior to be predictable at publish-time, but some work would be involved in predicting the length of a post on the server without running it through a browser's layout engine.

I'm probably misunderstanding the situation with automatic "read more", so I apologize in advance for what might be an annoying comment. But two thoughts:

I don't seem to see this behavior on my Firefox on Linux? That might be because I'm on a developer version, but I have run into focus "bugs" on Firefox that were Mac-specific in the past (I think that Chrome is a bit more aggressive about forcing the same behavior everywhere regardless of OS conventions) so my first thought when I couldn't get it to reproduce (other than, I'm probably doing it wrong X3) was "I wonder if this only happens on a Mac."

My other thought is that if you are directly setting tabindex="-1" on elements behind the read-all, I wonder if setting an extra overflow-x: hidden style on those elements at the same time would get rid of the extra behavior. It might be nothing though because I haven't been able to check without being able to reproduce the bug.

And there's probably stuff I'm missing, it's not my intention to annoy with development advice that's not relevant or applicable.