Our Guide to Responsive Images Syntax in HTML
Here’s one for your bookmarks: if you’ve ever wondered if you’re using the correct responsive images syntax in HTML then our guide was made just for you. In the intro, Chris writes:
This guide is about the HTML syntax for responsive images (and a little bit of CSS for good measure). The responsive images syntax is about serving one image from multiple options based on rules and circumstances. There are two forms of responsive images, and they’re for two different things:
1) If your only goal is performance, then what you need is…
<img srcset="" src="" alt="">
2) If you also need design control, then what you need is…
The syntax for getting responsive images right can be tricky sometimes and so I’m extremely glad that now I have a resource I can return to again and again whenever I need it.
Striking a balance between native and custom elements
It can be pretty difficult to style a native
select element and make sure that it’s accessible for as many folks as possible, as well as matching the visuals of your website and design system. This is because that element is still rather difficult to style today but also because by default browsers will do a lot of hard work for us; keyboard access, respecting user preferences, and good support for screen readers too.
So: if we want to make a
select that is not only just visually nice but also meets all the common usability standards of a native
select then we have some work ahead of us.
But! Thankfully Sandrina Pereira has written this fantastic post all about the concerns we need to take into account when making a custom
select. But Sandrina’s idea is basically to use both types of select: the native one for accessibility and the fancy visual one for mouse-based users:
When we build a simple custom select, we are making a trade-off without noticing it. Specifically, we sacrifice functionality to aesthetics. It should be the other way around.
What if we instead deliver a native select by default and replace it with a more aesthetically pleasing one if possible? That’s where the “hybrid” select idea comes into action. It’s “hybrid” because it consists of two selects, showing the appropriate one at the right moment:
• A native select, visible and accessible by default
• A custom select, hidden until it’s safe to be interacted with a mouse
This trick isn’t that complicated at all — it requires detecting whether hover is supported with a media query and toggling the visibility of the fancy custom select element when that’s available. Pretty neat trick, I’d say.
z-index visualization tool is nice
Have you always found the concept of
z-indextricky? Did you give a
z-indexvalue of 99999 to a HTML element hoping it will be placed in front of everything in a page and it still didn’t work? If your answer is yes, you’ve come to the right place.
That’s Thiru Manikandan writing about the difficulties of z-index where he’s made some great demos that show why a ton of us probably get confused by z-index at one point or another. This stuff is typically known as the stacking context and a lot of things can impact it—one of the least obvious being the structure of your markup. So this post is definitely worth reading if you’re ever stuck and in z-index hell.
Last month Andy Bell wrote about how he likes to writes CSS with a new method that he calls CUBE CSS and in the post all about the subject he writes about why he finds it just so dang helpful:
CUBE stands for Composition Utility Block Exception, and CSS stands for, y’know, CSS (Cascading Style Sheets). As mentioned before, the CUBE methodology is very much an extension of good ol’ CSS, rather than a reinvention. This mantra is very seriously maintained too, as the cascade and inheritance particularity play a big role.
Andy breaks down each section of what this methodology entails but let’s jump straight to the good bit. What does this look like when it’s applied to HTML? Andy’s example looks like this:
class="[ card ] [ section box ] [ bg-base color-primary ]"
So each category of CUBE is broken up into different groups that are separated by brackets, just like they are above — and I sort of love this! It’s pretty clear even if you don’t understand what CUBE means that each group of these classes have a specific function. And I think it’s pretty clear that the last section above are utility classes that update the classes of the base class, like
Overall I’m excited to see Andy write more about this technique because lately I’ve been working on an app that heavily uses emotion—and if I’m entirely honest I don’t think it’s a big improvement over using something like CSS Modules.
Add IDs to your header elements, that is an order!
Okay, so I’ve had too much coffee, yes. But! I always love it when a site—particularly a documentation heavy website—uses IDs on heading elements so that I can link other people to the specific part of the document that I want to make note of. It’s an extremely small nice-to-have that always makes my life a tiny bit easier.
Creative Background Patterns Using Gradients, CSS Shapes, and Even Emojis
Lately on the web I’ve noticed a distinct lack of cool backgrounds made with CSS. So here’s a post that details how we can remedy that because there’s a ton of fancy ways to go about making rad backgrounds with CSS. We can use SVG and emojis, gradients—both linear and conic, and then we can even show off by using gradients on emojis that are also SVGs. The mind reels!
There has been one case lately of a website that I think has a rather beautiful background pattern and that’s from the ever-so-weird archive that is Dream Wiki. This is a website that defines words in a rather curious way but, however you might feel about the descriptions themselves, there is something lovely about the use of punctuation-as-background here:
Each time you refresh the page you’ll find a new background and I’m not entirely sure how it’s made but you can select the punctuation in the background which probably isn’t so great for accessibility. Either way though, this is a neat idea. More rad backgrounds please!
5 Myths about Jamstack
It seems like there’s a lot of myths about Jamstack these days, I see quite a lot of criticism on Twitter and the ol’ blogosphere and I’ve never had an issue with it. I love everything that the Jamstack offers and I like that this technique for making websites has a name because I think it highlights big changes that are happening in the web design world.
But despite me never having an issue with it, it’s still interesting to read Brian Rinaldi’s notes about 5 of the most common Jamstack myths he sees. The third myth is particularly interesting to me, the one that suggests that editing content is difficult. I definitely think that we’re some way away from having an ideal solution here but there are a ton of lovely CMS’s that can easily be used in your Jamstack projects. Just the other week I setup Netlify CMS and although the installation is definitely not one-click and you’re off, I still think it’s remarkably easier than it was to write content now.
It’s like using sticky-notes on a website. Using BugHerd means you spend less time pinpointing bugs & issues on a page. Clients & users simply click a page element to provide feedback with automatic screenshots & metadata pinned to the task. No install and easy to use even with non-technical folk.
[Chris]: We all certainly like to argue about tabs vs spaces a lot. But have you considered Fibonacci indentation?!
Just a silly joke right. Or is it? I’m not sure if I would like it or hate it in day to day use, but I think it’s interesting to think about. Nested things that aren’t very deep aren’t very hard to reason about. Maybe those things don’t need that much indentation. But the deeper nesting gets, the harder it is to see and understand what is going on. Maybe more dramatic indentation is actually useful in that way.