Container Query Pizza, Tailwind Buttons, and Terrific Toggles

This week's CodePen community highlights include a tasty container queries demonstration from Jhey Tompkins, a whole bunch of of Tailwind-powered buttons from Vincent Van Goggles, and a delightful collection of clever toggles from Nicolas Jesenberger.

Plus, Kit Jenson builds a tool for comparing MLB teams, and we wrap up the final week of the August #CodePenChallenge with photo galleries.

ScrollTrigger Keyhole Animation
A keyhole window expands into a mega-hero image on scroll in this GSAP ScrollTrigger-powered Pen from natszafraniec.
Responsive Flex Wrap Grid with Variable Columns and No Exterior Vertical Borders
Chris Heuberger demonstrates an elegant flexbox technique for keeping lots of text of varying lengths on-screen and easy to read at any screen size.
Modern Button Styles
Vincent Van Goggles brings us a boatload of buttons in this stylish set of "45 creative button styles built on tailwind v.3.3.3".
Container Query Unit Pizza Toggle
Tap to toggle the pizza box from delivered through delicious to disaster in this fun container query units demo from Jhey Tompkins.
Comparing Teams - MLB
With this handy side-by-side comparison of Major League Baseball teams, Kit Jenson demonstrates the most fun use-case for CodePen: scratching your own itch. "Could not find anything similar to this, so I made this myself over a couple of hours."
#CodePenChallenge: Photo Gallery
We randomly position ads like these within the content of The CodePen Spark. Have a strong message, reach web developers.
AQI Particle Matter 2.5
Rudy Romero recreates the meter we've all seen a little too much of this summer with SVG and live data from the US EPA.
Interior Design
yudizsolutions combines GSAP & Bootstrap to animate this stylish design concept for an interior design firm's website.
Rubber Button
Tyler Sticka revises a 2022 Pen with accessibility and compatibility improvements, and blogs about the process for Cloud Four.
Flip through a terrific collection of Pens from tenacious toggle tinkerer Nicolas Jesenberger.

Chris’ Corner

A collection of web design and development news and thoughts from CodePen's own Chris Coyier.

Web Components Don’t Need You

Dave Rupert blogged a bunch of reasons about why you probably aren’t using them yet. Some of it is technological, and more of it is historical, marketing, and psychological reasons. Then Dave, a pretty avid Web Components follower and advocate, followed up with another surprise. Should you rewrite your app to use them? Probably not.

It’s not that you shouldn’t use them because they aren’t good, it’s:

If your components only have one place to go, then you probably don’t need Web Components. Even if your components service a couple different apps or product teams that all use the same uniform tech stack, you probably don’t need Web Components. Where Web Components shine is when your components need to go to many places.

The grid of logos on tells that story: very big companies.

Nolan Lawson followed that up with Use web components for what they’re good at, a more specific take on this, which largely agrees with Dave. Big companies are reaching for them because they solve actual problems for them. But enterprise isn’t very present on social media, so you just don’t hear about it as much.

So why are big enterprises so gaga for web components? For one thing, design systems based on web components work across a variety of environments. A big company might have frontends written in React, Angular, Ember, and static HTML, and they all have to play nicely with the company’s theming and branding. The big rewrite (as described above) may be a fun exercise for your average startup, but it’s just not practical in the enterprise world.

Having a lot of consumers of your codebase, and having to think on longer timescales, just leads to different technical decisions. And to me, this points to the main reason enterprises love web components: stability and longevity.

If you have some of those problems, you’ll probably benefit from Web Components and could or should use them, or maybe you already are. If not, whatever. Nobody needs permission to use them, and plenty of companies are doing it without a single care about what the social media vibe is on them. Web Components still have some problems, and fortunately, are still being actively worked on, so the story should get better year after year, in case you’re on the fence and watching.

Nolan does shout out one thing Web Components excel at, obviously and immediately:

To me, [client-rendered leaf components are] the most unambiguously slam-dunk use case for web components. You have some component at the leaf of the DOM tree, it doesn’t need to be rendered server-side, and it doesn’t <slot> any content inside of it. Examples include: a rich text editor, a calendar widget, a color picker, etc.

Dan Ryan has another take: they can be really simple. He used a header component as an example, which didn’t buy them anything extreme — just a simple update for a simple benefit.

So what did this gain us? For this example not much really. But where it really shines for us is only loading the CSS needed for the components used on a given page. Most of our visitors only view a single campaign page which uses just a few components. Previously though we were bundling all our CSS into a single file and serving it to everyone.

I’m the biggest fan of Web Components when you can just pluck one off the shelf and use it for something useful, knowing it’s lightweight and flexible. Nolan’s own emoji-picker-element is a classic example. When I see one-off componentry that isn’t a Web Component lately, I immediately wish it was. Check out this OverlayScrollbars “plugin”. Wouldn’t it be awesome as an <overlay-scrollbars> component, making it declarative and easy to use? (Yes.)

But I’m down for bigger approaches, too, so long as they are solving a problem. Google’s Material Design is an example of that. Material 3 is their latest take, and it seems to be mostly leaning into native apps, with the web version “coming soon”. When it does, it appears as if it’ll be Web Components-based. That’s cool and maybe even a touch surprising, being that Google could have used it as a way to promote Angular. But just because they went Web Components doesn’t mean they didn’t go Angular, assuming they work nicely in Angular, which let’s just hope they do.

Allow me to end with a little linky-uppy: Tram-Lite. I really like how you just use HTML to define the whole component, then go on to use it elsewhere. It requires no build process and has a very native feeling. Actually, check out the principals — they seem sound to me. And I’m not just saying that because it works great on CodePen.

CodePen PRO

If you're ever in a situation where you're using CodePen to present something, you should try out Presentation Mode. As in, share over Zoom where you have no idea the size of the screens of people watching. Or at a conference or classroom using an overhead projector. Or you're recording a YouTube video even!

Presentation Mode allows you to hide the header, offering more screen real estate, and allows you quickly change (via options in the footer) visual things like the colors and how things are sized). From experience, it's often very nice to be able to flip to a "light" theme and jack up the font size on-the-fly.

You can adjust your email preferences any time, or instantly opt out of emails of this kind. Need help with anything? Hit up support.