[Robin]: Here’s my photo of the week: a picture from a 2015 blog post by Paul Irish of the Wikipedia team walking through an enormous printed version of their performance timeline:
As bananas as this might seem at first, I think this is a wonderful idea! Once you print this thing out, all of a sudden these bottlenecks in the performance timeline are bound to feel like real, physical problems that you need to resolve. And you can scribble ideas on it, add sticky notes about what this particular problem might be or how long it might take to fix this thing, etc.
If I was running a performance workshop then something like this is probably where I’d start.
?
Say, CSS container queries are pretty handy:
Container queries are going to solve this long-standing issue in web design where we want to make design choices based on the size of an element (the container) rather than the size of the entire page. So, if a container is 600px wide, perhaps it has a row-like design, but any narrower than that it has a column-like design, and we’ll have that kind of control. That’s much different than transitioning between layouts based on screen size.
And container units solve a bunch of related problems. These are units that look like this:
.element {
font-size: 1qw; /* 1% of a query container’s width */
font-size: 1qh; /* 1% of a query container’s height */
}This is handy because we can make the gap or line-height or anything respond proportionally to the element that wraps this .element, unlocking a ton of CSS possibilities in the future.
One of the more obvious ways is that they let you delete a ton of media queries, as Ahmad Shadeed describes in his great post about container units:
?
Okay, now this is exciting: a proposal for CSS @when. I must’ve missed this post last week but returning to it now reminds me that with container queries/units in the future and this @when stuff is going to make media queries much easier to cope with in a complex CSS codebase.
So when you’re writing media queries you probably used to writing this:
@media (min-width: 600px) {
/* when the viewport is 600px wide, run the code in here */
}
@media (max-width: 599px) {
/* if the viewport is less than 600px wide, do this instead */
}But with this proposal we’d write something like this in the future:
@when media(min-width: 600px) {
/* ... */
}
@else {
/* ... */
}That’s… so much nicer! And now I don’t have to keep these two media queries in sync with one another if I wanted to change the breakpoint to 700px, for example.
? ? ?
Here’s another interesting future maybe thing: Priority Hints. That doc describes the problem pretty well…
Currently web developers have very little control over the heuristic importance of loaded resources, other than speeding up their discovery using
<link rel=preload>.
The idea is to tell the browser which resources are important and which aren’t, which could be useful for a carousel with a bunch of images:
<ul class="carousel">
<!-- The first image is visible -->
<img src="img-1.jpg" importance="high">
<!-- The other carousel images are not -->
<img src="img-2.jpg" importance="low">
<img src="img-3.jpg" importance="low">
</ul>In my head, this was how I was treating loading="lazy", as I’d often add that attribute to images which didn’t have to render right away. I guess the example above can be applied to scripts and links and all sorts of other things beyond images though.
You can sign up for the Origin Trial today to start using it and enable for users via Chrome.
?
Ethan Marcotte wrote about how the web is littered with those “install app” banners:
When responsive design first became a thing, mobile websites were peppered with links to “the full website”…which invariably contained the content or features you actually wanted to access on your mobile device. In practice, this encouraged product teams to adopt device-specific design methods: features weren’t deployed to people, but to specific types of devices.
By and large, these app prompts feel like fancier versions of that old pattern. And when new product features are built on the native experience, I think it’s illuminating when they don’t make it back to the web.
Even today, in 2021, I still often hear folks talk about the mobile web as if it’s a separate thing from the rest of the web. In a room full of software engineers, I’ll still hear stuff like “do we need a responsive website if we have a mobile app?” Although it makes me flinch for reasons beyond my understanding, it all just feels wrong to me. We should care for mobile users as much as—if not more than—folks visiting on a desktop device.
If I was to be real cynical for a bit, I’d say that websites are feeling increasingly less website-y to me and are now mostly billboards for the mobile apps you’re forced to download. The optimist in me says: good. When folks use the websites I make, I hope it’ll be night and day in comparison. I hope folks will think: dang, there is no other way a website could be. Of course it works like this.
Lots of folks have written about the experience of using the web today, with my favorite being this one by Guangyi Li:
It’s upsetting because it’s true. A ton of websites, even big name brands with enormous budgets for their website, feel like this demo by Guangyi. And he wasn’t the first to notice the problem, as Brad Frost famously described the problem:
Bullshit lies on a spectrum somewhere between ineptitude and outright deception.
[…] Popups, jargon, junk mail, anti-patterns, sensationalism, begging for likes, tracking scripts, marketing spam, dark patterns, unskippable ads, clickbait, linkbait, listicles, seizure-inducing banners, captchas, QR codes, barely-visible unsubscribe buttons, 24-hour news networks, carousels, auto-playing audio, bloatware, sudden redirects to the App Store, telemarketing, ticked-by-default subscribe buttons, “your call is important to us”, pageview-gaming galleries, native advertising, the list of bullshit goes on and on and on. This bullshit assaults our senses in a desperate attempt to capture our attention.
So what to do here? I find it easy to moan and whine about the situation but really what we have to do is show folks how it’s done. Lead by example. Remove the bullshit. Save the day.
??
Ravgeet Dhillon wrote about how to collect email signups with the Notion API:
A lot of people these days are setting up their own newsletters. You’ve got the current big names like Substack and MailChimp, companies like Twitter are getting into it with Revue, and even Facebook is getting into the newsletter business. Some folks are trying to bring it closer to home with a self-managed WordPress solution via MailPoet.
Let’s talk about another possibility: collecting your own email subscribers the good ol’ fashioned way: a that submits to an API and puts them into data storage.
I’ve been meaning to look into the Notion API for ages and it’s lil’ projects like this that get me super excited to check it out and play around with it.
?
Temani Afif continues to explore the CSS Paint API, this time looking into polygon borders like this:
Each one of Temani’s posts are a real deep dive into the underbelly of CSS and they’re always a blast to read. Highly recommended.
?
Ben Myers reminded me just how useful and flexible the <dl> element is. In this post, he walks through some examples and marks things up as he sees fit, which also reminded me that we can use the aria-label attribute to give screen readers headings for each section and then also use divs within the <dl> element to get the styling just right:
<dl aria-label="Traits">
<div>
<dt>Sunlight Sensitivity</dt>
<dd>While in sunlight, the kobold has disadvantage on attack rolls, as well as on Wisdom (Perception) checks that rely on sight.</dd>
</div>
<div>
<dt>Pack Tactics</dt>
<dd>The kobold has advantage on an attack roll against a creature if at least one of the kobold's allies is within 5 ft. of the creature and the ally</dd>
</div>
</dl>Not only that but the examples that Ben shows are just great, too:
Sponsor
Static WordPress in one click
Deploy WordPress as headless & static in one click on Strattic’s end-to-end hosting platform. Get the speed, security and scalability of headless while your marketing team uses WP as usual.
Get started with your 30-day free trial →
Sponsor
We speak your language: three days of learning, CSS, design, and more
Spanning the spectrum from climate-conscious development to design beyond the screen, and from advanced CSS to inclusive design and development, An Event Apart Online Together: Fall Summit 2021 will give you deep insights into where we are now, and where things are going next.
Join us online October 11–13.
Save $100 on any multi-day pass with promo code AEACSST21.
See the detailed three-day agenda and register now →
[Chris]: I use online “transformer” tools fairly often. Like, I’ll have a video in some slightly unusual format that I want to use on the web and I want to make it .mp4 because that tends to work everywhere, I look for one. I usually just Google “video to .mp4 converter” or something, land on some site that feels a little shadier than I’d like, but ends up doing the job just fine. Same for converting audio files from obscure to less obscure. Less commonly for images, as the laziest way is just to make it the original size on-screen and take a screenshot of it, which is then a .png by default on MacOS, which is easy enough to deal with.
If I have a lot of transforming to do, it ends up being a whole journey, then I forget everything I learned next time.
Code conversion is another story. I ran across this the other day:
There is a whole bunch of transformers in there to take code from one syntax to another. For example, there was a weird period where Netlify was supporting YAML in addition to TOML for their configuration files, but then YAML was dropped. So you need to convert? It’s there:
Or you have a bit of SVG that you need to put into JSX for a React project:
We were just looking at the HTML soup of Twitter.com the other day, I thought it would be funny to look at that as Pug:
I think the “reverse preprocessor” types are the most interesting in there. Probably not useful every day, but sometimes you’ve decided to pick up the usage of a preprocessor and could use a jumpstart on getting into that syntax.
