Earlier this month, Jeremy Keith posed the question: “How green is my server?”. As Jeremy notes, it’s surprisingly hard to get that information! So how do you ensure that you’re hosting your website on a green server?
The Session does very well in terms of performance. You can see the data from the Chrome UX Report (CRUX).
What’s good for performance is good for the environment. Sure enough, The Session gets a very high score from the website carbon calculator:
Hurrah! This web page achieves a carbon rating of A+
This is cleaner than 99% of all web pages globally
But under the details about hosting it says:
Oh no, it looks like this web page uses bog standard energy
The Session is hosted on DigitalOcean, who tend to be quite tight-lipped about their energy suppliers. Fortunately others have done some sleuthing to figure out which facilities are running on green energy.
One of the locations to get the green thumnbs up is the Amsterdam facility housed by Equinix. That’s where The Session is hosted.
I’m glad that I was able to find out that the site is running on 100% renewable energy, but I wish I didn’t need to go searching to find this out. DigitalOcean need to be a lot more transparent about the energy sources for their hosting facilities.
Maybe when I wrote about performative performance? Michelle has a prime example:
The low carbon toggle does absolutely nothing.
In fact, worse than nothing. It doesn’t prevent images being downloaded. It doesn’t switch the site to dark mode, or prevent autoplaying animations (e.g. the hero carousel), or reduce resources transferred in other way. All it does is overlay an extra element with a background gradient on top of the large images on the site to give the appearance that those images being prevented from loading.
I wrote recently about making the switch to logical properties over on The Session.
Initially I tried ripping the band-aid off and swapping out all the directional properties for logical properties. After all, support for logical properties is green across the board.
But then I got some reports of people seeing formating issues. These people were using Safari on devices that could no longer update their operating system. Because versions of Safari are tied to versions of the operating system, there was nothing they could do other than switch to using a different browser.
I’ve said it before and I’ll say it again, but as long as this situation continues, Safari is not an evergreen browser. (I also understand that problem lies with the OS architecture—it must be incredibly frustrating for the folks working on WebKit and/or Safari.)
So I needed to add fallbacks for older browsers that don’t support logical properties. Or, to put it another way, I needed to add logical properties as a progressive enhancement.
“No problem!” I thought. “The way that CSS works, I can just put the logical version right after the directional version.”
element {
margin-left: 1em;
margin-inline-start: 1em;
}
But that’s not true in this case. I’m not over-riding a value, I’m setting two different properties.
In a left-to-right language like English it’s true that margin-inline-start will over-ride margin-left. But in a right-to-left language, I’ve just set margin-left and margin-inline-start (which happens to be on the right).
This is a job for @supports!
element {
margin-left: 1em;
}
@supports (margin-inline-start: 1em) {
element {
margin-left: unset;
margin-inline-start: 1em;
}
}
I’m doing two things inside the @supports block. I’m applying the logical property I’ve just tested for. I’m also undoing the previously declared directional property.
A value of unset is perfect for this:
The
unsetCSS keyword resets a property to its inherited value if the property naturally inherits from its parent, and to its initial value if not. In other words, it behaves like theinheritkeyword in the first case, when the property is an inherited property, and like theinitialkeyword in the second case, when the property is a non-inherited property.
Now I’ve got three CSS features working very nicely together:
@supports (also known as feature queries),unset keyword.For anyone using an up-to-date browser, none of this will make any difference. But for anyone who can’t update their Safari browser because they can’t update their operating system, because they don’t want to throw out their perfectly functional Apple device, they’ll continue to get the older directional properties:
I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
JavaScript doesn’t get executed on very old browsers when native syntax for new language features is encountered. However, thanks to GitHub being built following the principle of progressive enhancement, users of older browsers still get to interact with basic features of GitHub, while users with more capable browsers get a faster experience.
That’s the way to do it!
Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.
Read on for the nitty-gritty details…
Smart advice on future-proofing and backward-compatibility:
There isn’t a single, specific device, browser, and person we cater to when creating a web experience. Websites and web apps need to adapt to a near-infinite combination of these circumstances to be effective. This adaptability is a large part of what makes the web such a successful medium.
Consider doing the hard work to make it easy and never remove feature queries and @supports statements. This creates a robust approach that can gracefully adapt to the past, as well as the future.
This is something I bump against over and over again: so-called evergreen browsers that can’t actually be updated because of operating system limits.
From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.
But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
So I had two older browsers that couldn’t be updated. It was device obsolescence because you couldn’t install the latest browser.
Websites stop working and the only solution is to buy a whole new device.
Safari has been subjected to a lot of ire recently. Most of that ire has been aimed at the proposed changes to the navigation bar in Safari on iOS—moving it from a fixed top position to a floaty bottom position right over the content you’re trying to interact with.
Courage.
It remains to be seen whether this change will actually ship. That’s why it’s in beta—to gather all the web’s hot takes first.
But while this very visible change is dominating the discussion, invisible changes can be even more important. Or in the case of Safari, the lack of changes.
Compared to other browsers, Safari lags far behind when it comes to shipping features. I’m not necessarily talking about cutting-edge features either. These are often standards that have been out for years. This creates a gap—albeit an invisible one—between Safari and other browsers.
Jorge Arango has noticed this gap:
I use Safari as my primary browser on all my devices. I like how Safari integrates with the rest of the OS, its speed, and privacy features. But, alas, I increasingly have issues rendering websites and applications on Safari.
That’s the perspective of an end-user. Developers who have to deal with the gap in features are more, um, strident in their opinions. Perry Sun wrote For developers, Apple’s Safari is crap and outdated:
Don’t get me wrong, Safari is very good web browser, delivering fast performance and solid privacy features.
But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.
Alas, that post also indulges in speculation about Apple’s motives which always feels a bit too much like a conspiracy theory to me. Baldur Bjarnason has more to say on that topic in his post Kremlinology and the motivational fallacy when blogging about Apple. He also points to a good example of critiquing Safari without speculating about motives: Dave’s post One-offs and low-expectations with Safari, which documents all the annoying paper cuts inflicted by Safari’s “quirks.”
Another deep dive that avoids speculating about motives comes from Tim Perry: Safari isn’t protecting the web, it’s killing it. I don’t agree with everything in it. I think that Apple—and Mozilla’s—objections to some device APIs are informed by a real concern about privacy and security. But I agree with his point that it’s not enough to just object; you’ve got to offer an alternative vision too.
That same post has a litany of uncontroversial features that shipped in Safari looong after they shipped in other browsers:
Again: these are not contentious features shipping by only Chrome, they’re features with wide support and no clear objections, but Safari is still not shipping them until years later. They’re also not shiny irrelevant features that “bloat the web” in any sense: each example I’ve included above primarily improving core webpage UX and performance. Safari is slowing that down progress here.
But perhaps most damning of all is how Safari deals with bugs.
A recent release of Safari shipped with a really bad Local Storage bug. The bug was fixed within a day. Yay! But the fix won’t ship until …who knows?
This is because browser updates are tied to operating system updates. Yes, this is just like the 90s when Microsoft claimed that Internet Explorer was intrinsically linked to Windows (a tactic that didn’t work out too well for them in the subsequent court case).
I don’t get it. I’m pretty sure that other Apple products ship updates and fixes independentally of OS releases. I’m sure I’ve received software updates for Keynote, Garage Band, and other pieces of software made by Apple.
And yet, of all the applications that need a speedy update cycle—a user agent for the World Wide Web—Apple’s version is needlessly delayed by the release cycle of the entire operating system.
I don’t want to speculate on why this might be. I don’t know the technical details. But I suspect that the root cause might not be technical in nature. Apple have always tied their browser updates to OS releases. If Google’s cardinal sin is avoiding anything “Not Invented Here”, Apple’s downfall is “We’ve always done it this way.”
Evergreen browsers update in the background, usually at regular intervals. Firefox is an evergreen browser. Chrome is an evergreen browser. Edge is an evergreen browser.
Safari is not an evergreen browser.
That’s frustrating when it comes to new features. It’s unforgivable when it comes to bugs.
At least on Apple’s desktop computers, users have the choice to switch to a different browser. But on Apple’s mobile devices, users have no choice but to use Safari’s rendering engine, bugs and all.
As I wrote when I had to deal with one of Safari’s bugs:
I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that’s a hell-freezing-over prospect, I wish that Safari updates weren’t tied to operating system updates.
Cassie’s enthusiasm for fun and interesting SVG animation shines through in her writing!
This is superbly in-depth and easy-to-follow article from Cassie—everything you need to know about motion paths in SVG and CSS! It’s worth reading just for the wonderful examples.
What a wonderfully in-depth and clear tutorial from Cassie on how she created the animation for her nifty SVG logo!
Also: Cassie is on the indie web now, writing on her own website—yay!
I spent the day in Greenwich, where there were two different web conferences happening simultaneously—Clearleft’s own UX London, and the annual Talk Web Design conference for web students at the University of Greenwich.
I was bouncing between both events, which meant I never really got immersed in either one. But that’s okay. I managed to meet up with plenty of people at both.
There was one unmissable talk today: Charlotte’s public speaking debut, opening up Talk Web Design with a presentation about her transition from student life to working at Clearleft. It was great. I knew it would be.
On Public Objects: Connected Things And Civic Responsibilities In The Networked City.
Flickr Commons just keeps growing and growing. Now there are wonderful collections of pictures from Greenwich available for us all to peruse and tag.
I should be depressed and dispirited after reading this, but the sheer quality of the writing gives me hope.
See, I'm not the only one who thinks that this is what she's singing.
A micro campaign to get people using switched extension blocks, you know four ways, multi plug sockets, this kind of thing, with switches
Adam Greenfield encapsulates his ideas from Everyware for the audience at the LIFT conference earlier this year.
Adam Greenfield talks about his new book, Everyware: The Dawning of Ubiquitous Computing.
Spot the anachronism from the forthcoming movie, Good Night And Good Luck.