safari

Attention over time

7-day rolling share of analyzed posts/comments mentioning this entity · 90 daily points ending 2026-10-15

Final complete day: 2026-10-15. Attention was 0.3% — this entity appeared in 8 of 2,852 analyzed posts/comments in the seven days ending that day (9 mentions).

Each point is a seven-day rolling window of complete UTC days; a point is comparable only when at least 100 analyzed posts or comments fall inside it. A day with no analyzed records counts as zero; missing coverage is marked and never shown as zero. The series ends at the latest complete analyzed day — it never extends into the current incomplete day. How attention is measured.

Recent mentions

1. 2026-10-14 06:40 UTCComment

   Client-side compression is a solid choice here, and plenty of image-heavy apps do exactly this. A few things that made it work well for me: 1. Resize first, format second. Capping the long edge at \~2048px with quality around 0.8 does most of the work. A 12 MP phone photo usually ends up at 300–600 KB as JPEG, so WebP vs JPEG matters much less than people think. 2. Don't assume WebP encoding works everywhere. Call canvas.toBlob(cb, 'image/webp', 0.8) and check blob.type in the callback. If the browser silently gave you a PNG instead, fall back to 'image/jpeg'. That covers older Safari without any user-agent sniffing. 3. Upload straight to R2 with presigned URLs so the file never touches your Next.js server. Still enforce a max size on that side (e.g. reject anything over 2 MB). Never trust the client completely. 4. On Expo, expo-image-manipulator does the same resize + compress before upload. 5. Bonus for a P2P marketplace: re-encoding through canvas strips EXIF data, including GPS. Otherwise sellers can leak their home location in listing photos. If you later want fancier variants (thumbnails, crops), look at an on-the-fly image transformation service instead of doing it in your serverless functions. Check current pricing, but small volumes are often free or very cheap.

2. 2026-10-12 13:21 UTCComment

   Finally. I've been messing with image compression tools for a while and JPEG XL's lossless JPEG recompression mode is genuinely the killer feature nobody talks about — you can shrink existing JPEGs by \~20% without decoding or re-encoding them, which is wild for legacy photo galleries. Real question though: how far are we from actually shipping JPEG XL in production? Safari still doesn't support it, and Firefox has been lukewarm at best. Is this Chrome-only for the foreseeable future, or do we end up in a world where AVIF and JPEG XL split the market?

3. 2026-10-12 10:32 UTCComment

   another case pulling the other way: private relay rotates its egress ips over time and between sessions, so one safari user can split into several ids within a day. and if the relay share of your traffic changes, that bias won't stay constant either

4. 2026-10-11 19:43 UTCComment

   Yea, that’s a four year old device. What browser are you using? Have you updated your android version recently? The scroll container CSS was supported on android before iOS, and it functions fine in chrome, safari, and firefox.

5. 2026-10-11 17:35 UTCComment

   WebP I hardly knew you. Caniuse shows Safari support going back a year. It doesn’t support animation, but I’m starting to think GIFs will never die. Since almost everything is Safari or Chrome under the hood, JXL could be viable for new sites pretty soon. Just need to wait for people to let their browsers update.