Somnius @somnius@merveilles.town

Super excited to be heading to BLFC starting tomorrow evening! It'll be great to check out Reno again, and it'll be super nice to get some time to relax :D

@cancel @neauoire Aside from what I've already said, you can use both device width and height with media queries if you're only targeting devices at a certain resolution, if that's what you're looking for!

@cancel @neauoire Er, to be clear, the latter example was meant for if I was using EM units.

@cancel @neauoire Oh, hm, I think I see what you're getting at. That's not how I'd be using media queries! I'd always be using widths with pixel units for media queries and adjusting font sizes with em/rem units.

That way, I can adjust the base "body" font size based on the device pixel width (if I was using REMs) or I could adjust the font-size right on the parent based on the device's pixel width.

@cancel @neauoire Not exactly. EM units change size based on the set parent element, whereas REM units will change size based on the size set by the font-size set on the HTML or BODY tag of a page! You can do some fancy stuff with this to change the font size on a webpage with these rules in mind. https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduction_to_CSS/Values_and_units

Unfortunately, however, I don't know of a way to set a maximum font size, which may be what you're looking for.

@cancel @neauoire Uh, I mean, it refers to how big text will be on the intended screen!

Using em/rem units might actually help for you here, since they're related to the default text size set by the body element (for rem) or by the parent element (for em). If that doesn't work, there's also vh or vw units that you can look into! Those are related to the viewport height or width respectively, which is more closely related to device size.

@cancel That's true—but I think that works out, in the end. If someone has a browser that they've only set to a quarter of their screen's width, making the website's typeface more legible or bigger somehow is completely usable.

@cancel You can use media queries to do this, based on the device's height or width! :3

@neauoire Oh yeah, that makes sense. When the main point of decentralization is to replicate your data to everyone, making sure everyone recovers from one point of failure is extremely difficult.

@neauoire A few of my friends have noted the trade-off you get with decentralized technologies—specifically, centralized services (Twitter/birdsite) are very easy to sign up on, and decentralized services are obscure/unknown but give the user more control over their own data. The trade-off is accessibility vs control.

That, however, doesn't even get into the implementation of those technologies. I know it was very easy to edit Rotonde feeds on the fly, for example.

@Merristasis Hello! 👋

@m Moi aussi — j'ai appris un peu dans lycée, mais c'était trops longue puisque j'ai parler français avec quelqu'un >w>

Oh, to be clear, all prices I listed in the original post are in USD!

One thing to note here is that we're now using Fastmail! This is going to be another expense that we're undertaking, but I'm planning to separate the expenses for Merveilles-related things from my own finances. Having a separate email is one part of that, and more work on this will involve migrating our server and images to new accounts. This will take a while, but I'll keep you all updated on when and how that all happens. Thanks for being rad, everyone! :D

Total Donations for Month
$15.00 via ko-fi

Infrastructure Costs
Amazon S3: $10.87
DigitalOcean: $24.00
Sparkpost: $0.00
Fastmail: $0.00

Total: $34.87

Donations to Date
$454.00

Infrastructure Costs to Date
$263.41

Money left over
$190.59

@urutau Wait whaaaaaat?? This is the same shit I hear coming from Jordan Peterson and his supporters, that's awful

Hey y'all! I'm going to be checking over the finances a little later this week to let you all know how things are going. Cheers, and thanks for your patience :3

@floatvoid The thing that kills me is that this whole ecosystem of stuff in front-end development all eventually compiles down to the same shit all browsers use: HTML, CSS, & JS. That's it. The more I work on this stuff the more it feels like we're just adding more layers of bullshit to do the same thing.

There's no one way to do something because the ECMAScript maintainers don't wan't to break old code and rewrite things, everything has to be opt-in, too. Shit's real weird.

@kyle That sure is a big mood