Readit Newsaleksandrh commented on Ultimate Vocal Remover GUI, a FOSS audio stem splitter github.com/Anjok07/ultima... · Posted by u/aleksandrh
Tried this last night and it works really well so I figured I'd share it here, even though it's a few years old. It can even take advantage of your GPU to run faster. The sample song I tested with is 5:56 and it only took 30 seconds for this tool to split it into separate .wav files for vocals, guitar, piano, bass, etc. I recommend following this guide here: https://www.reddit.com/r/musicproduction/comments/1704kob/co...
aleksandrh commented on Mako – fast, production-grade web bundler based on Rust makojs.dev/blog/mako-open... · Posted by u/afc163
Time to reset the clock. 0 days since a new web bundler was released (in Rust!!).
So tired of this ecosystem and its ceaseless tide of churn and rewrites and hypechasing.
aleksandrh commented on A formula for responsive font-size jameshfisher.com/2024/03/... · Posted by u/jamesfisher
> From here on out, all font sizes remain proportional no matter what, even if a user changes their preferred root font size in browser settings.
I think you might have misunderstood my point. My point is not that font size is no longer proportional. It’s actually critical to my point that it is proportional.
The 62.5% trick became popular because designers were used to designing with pixels and didn’t want to design with more fluid units like em. They were forced to by external requirements or often they were just following trends without really understanding them. So they used ems with the 62.5% trick as a substitute for pixels but didn’t change how they designed. So they were still designing with pixels in theory, but using ems as a really bad placeholder.
So if they wanted something to be 100px wide, using the 62.5% trick, they would set it to 10em. This will not get them something that is 100px wide though. This will get them something that is 10em wide, which will happen to be rendered 100px wide only when the browser is using a 16px default font size.
What happens when that fake-100px-but-actually-10em wide element is meant to coexist with something that is actually set in pixels? For instance, a 120px skyscraper ad? The things sized in fake-pixels-but-actually-ems will change proportionally with the user’s font size, but the things sized in real pixels will not. All of a sudden different elements on the page have different ideas about what scale they should be rendered at, and the layout falls apart.
Were you surfing the web with a non-default font size when this particular practice took off? I was, and I could always tell when a site started to use it because their layouts all got screwed up.
If you want to design in pixels, design in pixels. If you want to design in ems, design in ems. But don’t use ems as fake pixels because it cannot work reliably. The two units are fundamentally different and you cannot convert between them. One is rooted in a subjective user preference that can be different on every device, one is an objective measurement.
> What happens when that fake-100px-but-actually-10em wide element is meant to coexist with something that is actually set in pixels? For instance, a 120px skyscraper ad? The things sized in fake-pixels-but-actually-ems will change proportionally with the user’s font size, but the things sized in real pixels will not. All of a sudden different elements on the page have different ideas about what scale they should be rendered at, and the layout falls apart.
This is technically also working as intended. When a user scales their preferred font size in their browser settings, their expectation is that the font sizes on pages will scale accordingly, not that every element will scale. The latter is what zoom accomplishes, but there's a reason why both zoom and preferred font sizes exist in browser settings.
In your example, the ad (or image, or whatever) should only be sized in rems/ems if it has text. For all other elements that aren't related to text, it makes more sense to size with pixels. If everything is sized in ems/rems, then scaling the preferred font size behaves identically to zoom. This is less than ideal because if I want to increase font sizes, and what you do in response is zoom the whole page, then there is less space for that same text to fit on the page because it competes with other scaled elements. So while I can read the text more easily because the glyphs are larger, I can read _less_ of the text within the same amount of space than if text were the only scaled element.
Also, at least in my experience, designers aren't the ones thinking in ems; they typically hand us Figma compositions that use pixels, and we translate to rems in our code base. Designers design for the base experience, and we are responsible for coding it in a way that scales proportionally/in a way that respects user preferences.
aleksandrh commented on A formula for responsive font-size jameshfisher.com/2024/03/... · Posted by u/jamesfisher
This was always a terrible thing to do.
The idea behind it was that the browser default font size was 16px, so if you set the root font size for your document to 62.5%, then 1em = 10px, and designers who really, really wanted to work with pixels could use ems and pretend they were using pixels without doing complicated maths every time they wanted to set the size of something – they just needed to divide or multiply by ten.
The reason for not just using pixels was partly because it was drummed into everybody’s heads at the time that ems were better than pixels (which, in context, they were, but not when you pretend they are pixels), and partly because Internet Explorer at the time was unable to resize text set in pixels when you increased the text size, which was an accessibility failure.
The problem with this idea is that pixels and ems are fundamentally different types of unit. You can’t make them equivalent using any kind of calculation in CSS. Pixels are objective, whereas ems are based on user preferences. The browser might default to 16px font size, but users can pick something else. So if somebody had poor vision and increased their default font size; or if they had a small laptop screen and decreased their default font size, 1em * 62.5% != 10px, everything the designer set in ems was a different size than they intended, and a lot of their page layouts disintegrated into an unholy mess.
You can’t convert between ems and pixels in CSS. Any calculation like this is fundamentally broken from the start. Nobody should have ever used the 62.5% hack.
> The browser might default to 16px font size, but users can pick something else. So if somebody had poor vision and increased their default font size; or if they had a small laptop screen and decreased their default font size, 1em * 62.5% != 10px, everything the designer set in ems was a different size than they intended, and a lot of their page layouts disintegrated into an unholy mess.
Howdy, author of the article you're responding to (but not the person who originally discovered/pioneered this trick). This is not true, and my article explains why.
The 62.5% trick is rarely used on its own, but people often cite it this way, leading to confusion. In practice, you set the root font size to 62.5% (of the user agent font size) and then also scale all body text back up to 1.6rem so it's not stuck at 10px. From here on out, all font sizes remain proportional no matter what, even if a user changes their preferred root font size in browser settings. Play around with the math if you doubt it (the article offers examples).
> everything the designer set in ems was a different size than they intended
That's working as intended—your design will scale up or down, according to the user's preferred font size. If you don't like this, your only option is to set font sizes in pixels, which [you shouldn't be doing anyway](https://www.aleksandrhovhannisyan.com/blog/use-rems-for-font...) (disclaimer: also written by me).
This gives someone like me everything we want. Better performance is something the Next community has been begging for for years: the Next team ignored them, but not the Cloudflare team. Meanwhile Vite is a better core layer than the garbage the Next people use, but you still get the full Next functionality.
I wish Cloudflare the best of luck with this fork: I hope it succeeds and gets proven so I can use it at my company!