🕤 I’m terrible at predicting the future of anything. I’m always wrong about what startups will succeed, for one thing, and I have no idea at all what big changes to CSS we might see in 2020. Adam Argyle had 5 interesting predictions, some bolder than others.
Just in case it helps steer any cosmic forces, I say let’s keep talking about container queries every chance we get. Zach recently put together an interesting timeline of the concept.
⚛️ You know how you’re supposed to organize files in a React codebase, right? It’s like any other codebase, like this. But really, Adam Conrad has a concept which is organizing files based on how things relate to the data models they use. “Doman-driven design” that is, or DDD.
🙏 My hope is that all of us don’t just work on the web, but actively care about the web. It’s very possible to screw it up in some deeply fundamental ways, and it’s not always terribly obvious that any particular change is headed in that direction. Blue Beanie Day is dying off a bit, which is a shame because to me it was a pretty good rallying cry for protecting web standards:
Web standards, as an overall idea, has entirely taken hold and won the day. That’s worth celebrating, as the web would be kind of a joke without them. So now, our job is to uphold them. We need to cry foul when we see a browser go rogue and ship an API outside the standards process.
I got a little pissy about iOS 13 breaking CSS parallax, for example, and haven’t heard a word about it. It’s not good if we’re entering an era where browsers can just start doing whatever they want regardless of cross-compatibility or backward compatibility.
📹 Lemme do a quick test here… if I put a YouTube embed iframe on a page, it downloads 19 resources and 2.0 MB of stuff. But the UX of what shows up is largely just a static image and a play button. Paul Irish’s lite-youtube-embed is a tiny fraction of that. Quick demo, more like 57 KB which is mostly the image.
Another approach I almost like even better: lazy load it all.
[Robin]: For the past couple of days, I haven’t been able to stop thinking about Dave Rupert’s post all about why the details element is not an accordion and his frustrations when he discovers that it’s not possible to use these elements in the way he expects:
I think the biggest frustration here is expectations are broken.
details/summaryis the most accordion-like thing I’ve ever seen and yet it can’t be used as an accordion. My expectation as an Author does not match the Platform’s capabilities. Is this something that can be patched? Is this HTML’s fault? Is this ARIA’s fault? I don’t know. I only know that this creates more work for me.
Dave then vents his frustration with the web platform as a whole and argues that doing the very basics of modern web development is immensely complex and requires writing a ton of custom code:
At the risk of being a broken record; HTML really needs
accordion,tabs,dialog,dropdown, andtooltipelements. Not more “low-level primitives” but good ol’ fashioned, difficult-to-get-consensus-on elements. A new set of accessible controls for a modern era…except that these things have been in-use on nearly every major website and application for the last two decades and exist in every major design system.
This reminds me that some time ago I had an idea for an open-sourced library of components that are nothing but examples of how to make accessible elements. So, in other words, an Accordion element but with no styles and an API for you to make it look and work exactly as you’d like. Sort of like how react-dropzone is basically just a bunch of React hooks that gives you complete control over the HTML and CSS.
Anyway, as I thought more and more about this library — which would give you the correct ARIA roles and HTML elements to use and it make sure things are semantically proper — I realized something frightening. This is just how HTML should work! HTML itself should be the library upon which we build upon, rather than some npm nightmare of components and features.
If the markup isn’t allowing us to make things accessible then the fault lies squarely on browser vendors. How much time and how many resources are wasted doing the basics, like making tabs, modals, and dropdowns? Do we really need portal elements when the very basics of UI development is so difficult and frustrating?
But this isn’t just about developer convenience, it’s also about accessibility for users of the web, as Dave writes.
WordPress.com
People all over the world are doing amazing things on WordPress.com. All it takes is a glance at the Discover blog to see how flexible WordPress.com is for building everything from traditional blogs to full e-commerce storefronts. It’s one CMS with infinite possibilities.
WordPress.com gives you everything you need to create anything you want.
It’s flexible, secure, and powerful, just like you want your business to be.
🧩 I’m sitting here writing this newsletter in the Gutenberg editor inside WordPress. So this article from Mel Choyce about Art Direction and the New WordPress Editor hits home extra well. These blocks offer an awful lot of design control. But it feels different than if you were to just use a bunch of custom HTML and CSS within the editor. That, dear listeners, tends to not age very well. But when there is a layer of abstraction involved, and the customization is done by a tool provided as a first-class citizen of the CMS, it feels much better.
🗣 Wanna feel like you have a really strong grasp on how to handle quotes in HTML, both inline and block style? John Rhea has a really deep dive. I particularly like the pattern that involves figure and also the look at hanging-punctuation.
