[Robin]: This week I’ve been thinking about this post from the team at gov.uk where they write about how they made a button to show and hide the password of an input. They do that by toggling between the input type of password and text with some JavaScript. There’s a host of lessons they jotted down in this post about the craft (and frustrations) of making forms.
It’s fascinating reading about how the team tackled this problem but it also makes me a tiny bit frustrated because a show/hide password button feels like something that should be built into forms by default. Here’s some of the lessons they learnt along the way that suggests this should be a problem that browsers solve for us:
- show or hide the password by toggling input type between ‘password’ and ‘text’
- use a button with type ‘button’ to avoid accidental form submission
autocomplete="off"doesn’t work in all browsers- don’t allow users to submit text inputs containing passwords
I know there’s that consortium to make browsers more consistent, but now that we have all sorts of fabulous layout tools on the web, I think it’s time for us as a community to return to the basics: let’s make forms on the web real good.
I know this is an extremely punk rock statement to make, but I’m scared to make a form on the web. Just look at what it took for this team to add a simple button to show the password! All this work and effort is required for something that results in extremely low pay-off in the end. I think browsers really need to meet us halfway here because making a form should be as enjoyable and as easy as creating a grid with CSS. Forms shouldn’t be scary.
I guess this is the lesson I came away from this post: whenever you feel like you’re fighting the browser to get it to do what you want, then those are the problems that should be the priority of browser manufacturers.
Okay, enough moaning about forms…
Is CSS a Programming Language?
…and onto moaning about CSS! But seriously, I love this piece from Chris where he asks if CSS is a programming language because he sort of questions the question to get to what it actually means.
This question tends to come up again and again on Twitter and in the web development community and each time it bothers me. But until Chris described why, I couldn’t put my finger on it. He writes:
I have a real distaste for this question. It might seem like a fun question to dig into on the surface, but the way it enters public discourse rarely seems to be in good faith. There are ulterior motives at play involving respect, protective emotions, and desires to break or maintain the status quo.
I completely agree with Chris. These questions are rarely asked to debate the merits of the CSS language in an inquisitive way and are really just arguments about power.
Preventing zooming on forms in iOS
Ha! I tricked you and have one more thing to moan about when it comes to forms: when you have a font size that’s less than 1rem (16px), then iOS Safari will automatically zoom into it once you click:
The example above comes from Josh W. Comeau and I’ve noticed it frequently and often on iOS but never sat down to think about why.
Can I email?
Okay this is an incredible resource: just like caniuse.com is perhaps the greatest invention since the telephone, there’s a complimentary website called caniemail.com which shows you which CSS and HTML features are compatible with mail clients like Outlook or Apple Mail.
As Chris made note of, it’s impressive to see how many email clients support display: flex these days, too.
How to improve CSS performance
Milica Mihajlija wrote about why CSS is very important when it comes to its impact on loading performance:
When there is CSS available for a page, whether it’s inline or an external stylesheet, the browser delays rendering until the CSS is parsed. This is because pages without CSS are often unusable. If a browser showed you a messy page without CSS, then a few moments later snapped into a styled page, the shifting content and sudden visual changes would make a turbulent user experience.
CSS loading can be a bit tricky though, asMilica suggests that we should load our critical CSS (what goes above the fold) in the <head> of the document and the rest should be loaded async via this neat hack:
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">Once this resource has downloaded that onload part there will then apply the styles to the page, potentially saving you critical time parsing other things like HTML and JavaScript.
Oh and my favorite note here, which is a hill I will die on, is that we shouldn’t worry about the speed of CSS selectors. I keep hearing folks talk about how slow things like the * selector is. But Millica argues that we shouldn’t waste our time here:
The CSS declarations are so friendly to compression algorithms that the effort required to optimise a CSS selector is usually better spent working on other parts of your application with a greater return on investment.
Custom States and Psuedo Classes
This is a new feature in Chrome 90 that allows custom elements to expose their state for styling. So let’s say you have custom element like <live-score> then you style it’s loading state like this:
live-score {
/* default styles for this element */
}
live-score:--loading {
/* styles for when new content is loading */
}That :--loading bit is the custom state that you can create within the custom element which makes a whole lot of sense to me.
Šime Vidas has the scoop on all this and how pseudo-classes should be used to style these elements from here on out. Well, except that this isn’t a standard just yet and Chrome is the only browser that supports it right now.
But this is all certainly interesting stuff.
Creating Colorful, Smart Shadows
Kirupa Chinnathambi made this super interesting and bonafide CSS trick here where he creates a lovely blurred shadow around an SVG of a sushi. All of this is done with CSS and then he makes it pulse over time:
The remarkable thing about this demo is how he built it: he uses two pseudo elements to inherit the background image of the sushi element (I didn’t know you could even do that!) and then blurs them and positions it behind the non-blurred sushi. That’s super smart.
I’ve seen this kind of technique when it’s applied to typography before and Chris made this demo example where you can use text-shadow to apply it to emoji:
color-contrast()
“Huh! That’s amazing!” I said out loud to myself earlier today when I read about Safari’s new color-contrast function that shipped in Technical Preview 122. Here’s why: color-contrast() allows the browser to decide which of two text colors works best with a specific background color so that you can always have accessible text that everyone can read easily. Here’s how it works:
section {
background: black;
color: color-contrast(black vs red, white);
}That vs part above isn’t a typo. What’s going on here is that you can tell Safari what the background color is (here we’ve said black) then pick either red or white depending on which color has best contrast with the background.
This gets particularly useful when you start to use variables and make things a bit more dynamic. So you could rewrite the above like this:
section {
background: var(--bg);
color: color-contrast(var(--bg) vs white, black);
}Here’s a great demo by Dave Rupert where he explores how you can make the text and the link color of a block of text more accessible when the background changes, too:
Sponsor
Video: Set up a fully functioning WordPress instance
In this 10-minute tutorial, learn how to use Linode’s One-Click Marketplace to set up a fully functioning WordPress instance. You’ll see how to connect your domain name to the website using the DNS manager and how to set up SSL with Certbot.
Sponsor
What to Do if Your WordPress Site is Hacked
Though WordPress is a safe platform, all websites are vulnerable to hacks. If you’re using Jetpack Backup, you’ll already be one step ahead. Jetpack stores files off-site, which means they may still be fine, even if your site’s been hacked. Plus, if your website is down, you can still restore a full backup with just a few clicks.
Psst! Automattic is looking for a Senior Data Engineer with experience in Spark/Scala to join their team of data scientists and engineers to build, deploy, and iterate on large-scale data pipelines and applications.
[Chris]: It’s been almost 2 years since I first wrote about Coil. It’s a service you can sign up for as a random consumer of the internet, pay them $5/month, and they’ll sprinkle it out to publications who are signed up to receive that money. I would be very blah on a service like that, except for one huge fact: this is just a small step toward making this kind of thing a real web standard: The Web Monetization API. That, I’m still hot on, although I have no idea what the chances of it making it are.
One thing that is true, at least from my perception of things, is that Coil hasn’t done much in those two years. There are a couple of really fundamental things that unlock real possibilities, but neither of them seem to be talked about much:
- The APIs behind this need to be incredibly fast. Part of the point here is delivering people something they are paying for, like we would if they signed up directly for our site. Me asking me own database if someone is paid is essentially zero seconds. The HTML doesn’t come back without that knowledge. But me asking Coil if a user is paid takes several seconds. I literally cannot wait that long to make a choice whether or not I’m going to do something like request ads for the page, lest shoot myself, monetarily, in the foot.
- The tech needs to be set up to give arbitrary sites arbitrary amounts of money. I’m not particularly interested in giving people valuable things for literally $0.02. If this stuff gets more serious, there will need to be tiers that I can define, that anyone can choose to bump themselves up into.
On that second point, if I’m a paying customer of Coil, I’d certainly want some reporting around this. This is tricky, as part of the point of Coil / Web Monetization is all the anonymousness of it. When the transactions take place, no information is exchanged, making it all very safe. But that doesn’t mean that I don’t want to know where my money goes. It seems like anonymity can still be true for the transactions, but Coil could still track for me where my money went and show me, couldn’t it? Without that, how is trust possible?
Daniel Aleksandersen wrote about this recently:
At the time of publication, Coil doesn’t have any competitors using its open Web Monetization protocol. Customers can’t choose another provider that’s more transparent or makes different micro-decisions about which creators to support. The lack of competition gives Coil the freedom to do as it wants. However, the lack of transparency and openness about the allocation of funds also makes people distrust the whole automatic micro-payments ecosystem.
On the day-to-day, I rarely think about Coil. I have the browser extension installed, and it just does its thing with my $5/month. But every time I seem to check on it, the browser extension has somehow lost connection with Coil.com and I have to re-connect it. How long has it been like that? Over a month? Does that mean no sites benefitted from my $5 this month? How can I check?
If I can start using Coil to pay a particular site $20/month, and I wish I could, then I really wanna know if that is operational and that the transactions are working as I intend.
There is a lot of trust that needs to be built here. The foundations are there, they just need to get the details right.