Drew Powers

107 Followers
109 Following
215 Posts
Design Engineer @ Figma
Moved to Bluesky
📍CO, USA
Blueskyhttps://bsky.app/profile/pow.rs
GitHubhttps://github.com/drwpow

🦋 Moving to Bluesky 🦋

https://bsky.app/profile/pow.rs

Mastodon was fun but I am not smart enough to navigate and find people across all these servers (running different setups no less). I don’t like racking up server costs for random internet strangers, and I refuse to learn the difference between ActivityPub and AT Protocol

Drew Powers (@pow.rs)

🏭 Design Engineer @figma.com 🚀 co-creator @astro.build 🛜 pow.rs 🆓 building terrazzo.app + openapi-ts.dev

Bluesky Social
say what you will about #node but old projects still run
make the restaurant homepage the menu PDF you cowards

Good reminder: don't lazy load hero or product images.

https://cloudfour.com/thinks/stop-lazy-loading-product-and-hero-images/

It hurts both your UX and your Largest Contentful Paint (LCP) score.

Stop Lazy Loading Product and Hero Images

I see a recurring performance problem on many ecommerce sites—the most important images on the page are being lazy loaded when they shouldn't be. You’re better off not implementing lazy loading at all than implementing it incorrectly.

Cloud Four
The #oss maintainer urge to trick someone disagreeing with you in issues to create their own OSS library, improving the ecosystem and putting more good ideas into the community 😈

@ma1 I do work with accessibility on a regular basis, and this is a well-known issue. It already has been reported, but as you know browsers aren’t always the fastest to fix things.

Also that article says “<input type="date"> is usually better than custom widgets” and I don’t disagree! But they *don’t* pass all requirements yet, and my original comment still stands.

https://a11ysupport.io/tests/tech__html__input__input-date

Test: Basic html date input test | Accessibility Support

@ma1 They actually DON’T degrade gracefully when you factor in a11y! The native datepickers built into browsers aren’t accessible. Comboboxes need HTML attributes adjusted on what’s actively open and highlighted. Filtering must be done in JS. You actually NEED JS to pass WCAG 2 with these controls. It only degrades to a semi-working state for non-disabled users.
@molly0xfff same energy
@mook I mentioned progressive enhancement just as a nod to the argument that you can ship a JS-free version and a JS-enhanced version of a website (at least in its original form). I don’t see having JS-required sites as a bad thing anymore, since many things need JS to work (like comboboxes! and calendars! and context menus). If you’re mindful of budget and get creative, it’s possible to do one JS version better than two half-finished versions (not always of course, but often)
@berkes Eh I meant both. Modern TS is pretty good. It ships, it can be performant enough for the widest range of general programming, and the tooling is fast and mature now. To each their own, to point 8.