[Robin]: Chris collected some thoughts from the community about CSS4 and whether it will ever be a thing. Do we need it as developers? Will it be helpful to promote new features across all browsers?
It seems like there’s a very clear “nope!” coming from a lot of prominent web developers — that there will never be a series of technologies described as “CSS4” because we don’t need it anymore and it’s not useful. Today we have a ton of specifications that are all working rather independently of one another.
I’m not sure where I stand on this yet. I guess my question is what would be in CSS4? To do great web development today I can’t think of anything beyond Grid and subgrid that exponentially helps me in my day to day work. CSS3 made a bunch of sense because we needed to push browsers to, some degree at least, compete with native apps. We needed animations! We needed transforms!
Today though I can’t think of any CSS limitations that frustrate me. Instead, all of my vitriol stems from a lack of HTML improvements. Every project I work on to some degree encourages me that we need to return to the building blocks of the web — the markup itself — if we want to build accessible interfaces. In short, I don’t want CSS4.
I want consistent form inputs across browsers. I want a time input that is supported in more than half of a browser. I want us to take a look at design systems and UI frameworks and steal all of their best ideas. I want a modal! I want tabs!
I guess what I really I want to see is a flurry of activity improving the HTML language because I want us to extend the baseline of accessibility and the developer experience in general.
What I want is HTML6. (I think). (Please don’t shout at me.)
🤔🤔🤔
Last week I subscribed to Adam Silver’s newsletter on design and I was impressed by just how much practical advice can be found in each email. In the most recent edition on the subject of tooltips, he describes why they can be tricky for us to build and can potentially cause a lot of accessibility issues for our users.
When it comes to tooltips Adam’s advice is pretty short; don’t hide important information from users!
While tooltips provide a way to hide and show content, needing to clarify how your interface works indicates bad design. At best, tooltips make users jump through a series of hurdles in order to access the content. At worst, they’re not seen and totally inaccessible. A better alternative is to just show the content in situ, or better yet, design the interface so that users don’t need the additional guidance in the first place.
Another bit that stood out to me in this latest email is when Adam writes: “do the hard work to make it simple.” And I’m not sure I can think of better advice for designing interfaces on the web today. It sort of reminds me of this note from Scott Jehl:
🛠🛠🛠
Here’s a fantastic piece by Tristram Tolliday about the front-end framework Svelte, similar to Vue, Angular, or React but with three key differences that Tristram points out:
- All the code is compiled ahead of time.
- There is no virtual DOM.
- CSS scoping is baked in.
My personal recommendation is to give Svelte a try. We’ve only scratched the surface of the framework in this article, but having converted my personal website to Svelte, I can confidently say that it is a pleasure to work with. It is performant, has a brilliant VSCode linter, and best of all, is easy to use.
🔭🔭🔭
Guillermo Rauch’s 2019 in review is worth reading and has an interesting summary of what happened over the course of the year and in the Jamstack community especially.
Here’s one note that Guillermo makes about the improvements made in deployment previews—this is when services such as ZEIT Now will give you a link allowing you to see the application you’ve been working on and how your latest commit has improved it:
Code review is undeniably important (specially speedy code review), but nothing beats teams collaborating by sharing URLs to the actual sites that are being worked on and experiencing them directly. […] This means that instead of running tests that make all kinds of assumptions about the environment (like mocking it), we can instead test the _real thing_. As real as it gets.
I noticed this on a project I was working on a while ago with Netlify and I thought it was the coolest darn thing I’d ever seen.
⌗⌗⌗
With the help of Tabletop.js, we can use Google Spreadsheets as a database and make it super easy to access with some JavaScript. Tabletop gives us the data as JSON and then you can treat it like any other API! David Atanda walks us through how to create an editable web page with Tabletop.js and this might be especially handy if we don’t want to setup a CMS or something more complicated.
Oh and this might be particularly handy for building design systems sites, especially if you there are folks that need to update the copy of a site without having to learn a whole new technical thing.
✍️✍️✍️
I just spotted this neat website by Mandy Michael that showcases variable fonts and how to get started using them today. There’s already a bunch of neat fonts such as Fira Code to play with.
Here’s one example where Mandy breaks down how she created this rather stunning animation using the Decovar typeface: each portion of the letters unfurl and grow on these letters and it’s worth taking a look into how she built this:
I think it’s worth taking a look at variable fonts today because there is so much time and investment being poured into them from type designers and browser manufacturers alike. If you’re looking for more variable fonts to experiment with then I would highly recommend this great list of available fonts where you can try them out for yourself:
🔒🔒🔒
Jake and Surma published an interesting video about URLs and how different browsers treat them: there’s a lot of security and design issues that are pretty interesting!
I really like Jake’s design suggestion where the most important part of the URL is easily scannable (so phishing attacks are easier to spot) but the whole URL is accessible, too. (I can’t remember who said but many years someone mentioned that the URL structure of a web page should act like breadcrumbs, allowing folks to go back to where they before.)
Here’s his suggestion:
↗️↗️↗️
There’s some hot drama and advice from Adrian Roselli that I like a whole bunch: don’t open links in new tabs! He writes why that’s the case:
When you force links to open new windows or tabs, you are taking away the user’s ability to make that decision. Some users open every link in a new tab. Some users prefer to go forward and backward in the same window, and some might not understand how to navigate across windows or tabs. By forcing any links to open a new window, you have removed the user’s ability to control the experience, and in some cases made it impossible to understand.
As a user, I’ve always found a window opening in a new tab to be pretty hostile and annoying and as a developer, I’d always prefer to give control to the user anywho so I found myself nodding along to this piece a lot.
We’ve covered target="_blank" in depth before as well, honing in on do/don’t use cases.
⚡️⚡️⚡️
Chris shows us possibly the easiest way to run a static site generator where you don’t need a big framework or anything—instead you might want to create a tiny site and just not repeat yourself in the HTML, say with a navigation that’s used on three pages. So say you want the benefits of componentized HTML without all the hassle of having a complex setup.
Well! In this post, Chris shows how with this setup you don’t need a package.json, or a complex npm install step to get things up and running. You can just use something like Eleventy for its ability to make our HTML a bit more componentized! And I think all this is super handy.
📔📔📔
I love this piece about how CSS and HTML developed together over the years. There’s a ton of interesting history into table-based design, but it also looks into the time before DevTools and when our work was exponentially harder than it is today:
Notice the extremely precise positioning of these navigation links. This feat was accomplished the same way everyone did everything in 1996: with tables.
In fact, tables have one functional advantage over CSS for layout, which was very important in those days, and not only because CSS didn’t exist yet. You see, you can ctrl-click to select a table cell and even drag around to select all of them, which shows you how the cells are arranged and functions as a super retro layout debugger. This was great because the first meaningful web debug tool, Firebug, wasn’t released until 2006 — a whole decade later!
If all this is interesting then I would highly recommend The History of the Web newsletter which always happens to have tales of the web that I wasn’t particularly familiar with.
⏳⏳⏳
Mateusz Rybczonek shows us how to make an animated timer with HTML, CSS, and JavaScript that happens to look something like this. This demo happens to use the good ol’ stroke-dasharray trick that I’m so very fond of when creating SVG animations to make a line look as if it’s moving.
Sponsor
WordPress.com can process recurring payments for your customers
Have an idea for a subscription business? Need to charge customers on a monthly or yearly basis for something, not just a one-off charge?
WordPress.com can do that for you. You connect your Stripe account (the best payment gateway out there!) and the rest is as easy as adding button blocks to your site. The UI your customers see is clean and clear, and the pricing is straightforward. The eCommerce plan pays no fees, the Business plan pays 2%, and the less expensive plans go up from there.
📙📙📙
Whether you know it or not, you’re reading this over RSS! We publish this newsletter to the site, an RSS feed is generated just for newsletters, and new RSS entries are eventually sent out over email.
Isn’t that just giving content away for free? Yep, that’s how we like it. But what if you don’t? Here’s some thoughts.
