Activity for nilaallj.se
Loading activity...
Well that makes sense. A webp → webp reprocess is less harmful than a webp → jpeg → webp reprocess. But it is still a bit strange that a second reprocess happens even when the format is the same and the size is small already.
OK so today I learned that blobs are inaccessible until they are referenced by a record. 😅 It seems like the webp image I uploaded using goat (86 kb) was reprocessed to a 106 kb version for the CDN, but no visible drop in quality. That’s not always the case when uploading through the app.
Did not expect to see Sweden’s national selection for Eurovision at #5 on Bluesky’s trending list. AFAIK that feature only covers English language posts which makes it gravitate towards global events or stuff going on in the anglosphere, especially the US. This almost feels like a bug. 👀
But doesn’t Bluesky already reprocess to avif? If I append `@avif` to an image URL from the Bluesky CDN I get an avif version of that image.
I tried to upload a webp directly to my PDS using goat, but it doesn’t seem to work? It looks good in the command line. No error message, it shows correct MIME, I get provided a CID and everything, but it does not show up in the repo? 🤔
My thoughts exactly! Using Bluesky to upload a webp image will store a jpeg on the PDS. So the webp provided by the Bluesky CDN is re-encoded a second time.
You will still be able to download jpeg versions from Bluesky by adding @jpeg at the end of the image URL. 🙂
Especially if this means that WebP uploads get re-encoded in the app only to be re-encoded again at the AppView? Do you know if it’s possible to sidestep the re-encoding somehow? Maybe by using Goat to upload the blob and then use PDSls to create the post?
This is a bit annoying imho. I think many users want to be able to optimise their images before upload in order to ensure good quality (while still keeping the file size slim). WebP i SO much better at that compared to JPEG. This re-encoding will increase file size while quality gets worse… 🫠
Imho handling the document outline is cursed as it is. There are so many websites out there with poor a11y partly because of this problem. Sometimes the state of things can improve by making it easier for developers to implement them right. This could imo be one of those things. :)
I think the use of `:heading()` makes most sense together with the upcoming `headingoffset` HTML attribute. If I remember this correctly, it lets you set `headingoffset="2"` on an element to make a descendant `h1` have the semantic heading level 3, and a `h2` would have level 4 and so on.
Since type selectors in CSS targets the actual element used and not its semantics, the `:heading()` selector was added to the spec to fill that gap. I think this is good. Two new features that will make it easier to create reusable components without having to worry about the document outline. 🙂