Tags: ors

154

sparkline

Wednesday, September 29th, 2021

Locus. — Ethan Marcotte

Ethan documents the sad plague of app-install banners on the web.

Wednesday, September 8th, 2021

Coaching on the Clearleft podcast

Season three of the Clearleft podcast is here!

The first episode is a nice gentle one to ease into things. It’s about coaching …and training …and mentorship. Basically I wanted to find out what the differences are between those three things.

But I must confess, there’s a commercial reason why this episode is coming out now. There’s a somewhat salesy promotion of an upcoming coaching programme with Julia Whitney. This is definitely the most overt marketing I’ve done on the Clearleft podcast, but if you listen to the episode, I think you’ll agree that it fits well with the theme.

Fear not, future episodes will not feature this level of cross-promotion. Far from it. You can expect some very revealing podcast episodes that pull no punches in getting under the skin of design at Clearleft.

The stars of this episode are my colleagues Rebecca and Chris, who were an absolute joy to interview.

Have a listen and hear for yourself.

Saturday, August 21st, 2021

Scope Proposal & Explainer

This detailed proposal from Miriam for scoping CSS is well worth reading—it makes a lot of sense to me.

Saturday, August 7th, 2021

Space Elevators: How a sci-fi dream could be built today

Surveying the current practical and theoretical factors for and against space elevators (including partial elevators—skyhooks!).

Tuesday, August 3rd, 2021

How To Build Resilient JavaScript UIs — Smashing Magazine

The opening paragraphs of this article should be a mantra recited by every web developer before they begin their working day:

Things on the web can break — the odds are stacked against us. Lots can go wrong: a network request fails, a third-party library breaks, a JavaScript feature is unsupported (assuming JavaScript is even available), a CDN goes down, a user behaves unexpectedly (they double-click a submit button), the list goes on.

Fortunately, we as engineers can avoid, or at least mitigate the impact of breakages in the web apps we build. This however requires a conscious effort and mindset shift towards thinking about unhappy scenarios just as much as happy ones.

I love, love, love the emphasis on reducing assumptions:

Taking a more defensive approach when writing code helps reduce programmer errors arising from making assumptions. Pessimism over optimism favours resilience.

Hell, yeah!

Accepting the fragility of the web is a necessary step towards building resilient systems. A more reliable user experience is synonymous with happy customers. Being equipped for the worst (proactive) is better than putting out fires (reactive) from a business, customer, and developer standpoint (less bugs!).

Monday, May 31st, 2021

Summertime in England

On Thursday of last week, Summer arrived in England. I accept full responsibility for this. That morning I left the house early and wore a winter coat. So of course the day was filled with glorious sunshine.

I was up early to head into the Clearleft studio to do a tech check and some pre-records for the upcoming UX Fest. We’ve turned a meeting room into a very swanky-looking recording studio with proper lights, mics, and camera. I’ll be hosting UX Fest, channeling my inner Alan Partridge and Ron Burgundy.

Recording an interview with the brilliant @KrysHiggins for next week’s @UXLondon #UXFest. (I made sure my shirt matched her excellent new book, Better Onboarding by @ABookApart.) https://abookapart.com/products/better-onboarding

Being back in the studio was nice. Some of my Clearleft colleagues joined the agency during The Situation so this was my first chance to meet some of them face to face (or facemask to facemask at least).

The next day I had even more opportunity to see my co-workers without the barriers of computer screens. We had a workplace walk in the countryside to mark one year of becoming an employee-owned agency. We rendezvoused at Devil’s Dyke and walked a bit of the Sussex countryside, just enough to work up an appetite and a thirst to be satiated at the nearby Shepherd and Dog pub in Fulking (near the brilliantly named Fulking Hill). We sat at tables outside, had pints of ale, and a proper pub lunch, chatting all the while, just like in The Before Times.

A nice day for a @Clearleft walk in the country.

When I got back to Brighton I met up with Jessica for a beer in the sun before wandered down to the beach together to meet our friend Kate and celebrate her birthday.

Hanging out on the beach.

Two days of good weather was a blessing, but it didn’t stop there. The next day, Saturday, was even sunnier. We spent the day working in the garden. We planted salads in our raised beds and then fortified those raised beds to make them impenatrable to the family of foxes living in our neighbourbood. Don’t get me wrong, the fox cubs are very cute. I just don’t want them digging up our salads.

There are multiple fox cubs hanging out in the garden. Fuzzy little cuties! 🦊

On Sunday, Jessica and I sauntered up the hill to Brighton Racecourse so we could cheer on Jake as he finished his hundred kilometre walk from London to Brighton. Normally this would be a very strange behaviour, but it was all for a good cause.

After that, we had a pub lunch (outdoors, of course) before heading home. I spent the rest of the day sitting out in the garden, admiring the handiwork of the previous day, reading and occasionally dozing.

Today it’s more of the same. Glorious sunshine. Sitting in the garden. Reading. Playing some tunes on the mandolin. Looking forward to grilling outside for the third evening in a row.

Sitting in the sunshine, playing tunes on my mandolin. ☀️ 🎶

It feels like something is changing and it’s not just the weather. The Situation, while far from ending, is certainly morphing. I still don’t plan on spending any time indoors, but with weather this good, I don’t need to.

In two weeks time I’ll get my second jab of vaccine. Two weeks after that I can start letting my guard down a bit more. Until then, I’ll be staying outdoors. If the weather continues like this, that won’t be a hardship.

Wednesday, May 26th, 2021

No, Utility Classes Aren’t the Same As Inline Styles | frontstuff

This is supposed to be a defence of utility classes …but it’s actually a great explanation of why classes in general are a great mechanism for styling.

I don’t think anyone has ever seriously suggested using inline styles—the actual disagreement is about how ludicrously rigid and wasteful the class names dictated by something like Tailwind are. When people criticise those classes they aren’t advocating for inline styles—they’re advocating for better class names and making more use of the power of the class selector in CSS, not less.

Anyway, if you removed every instance of the word “utility” from this article, it would still work.

Saturday, May 15th, 2021

Data isn’t oil, so what is it? - How To Measure Ghosts

The discussions around data policy still feel like they are framing data as oil - as a vast, passive resource that either needs to be exploited or protected. But this data isn’t dead fish from millions of years ago - it’s the thoughts, emotions and behaviours of over a third of the world’s population, the largest record of human thought and activity ever collected. It’s not oil, it’s history. It’s people. It’s us.

Can I :has()

This would be such a great addition to CSS—a parent/ancestor selector!

With the combined might of :has(), :not(), nth-child(), and calc(), CSS has become a powerful language for specifying rules to account for all kinds of situations.

Monday, March 29th, 2021

CSS { In Real Life } | Quick Tip: Style Pseudo-elements with Javascript Using Custom Properties

Oh, this is smart! You can’t target pseudo-elements in JavaScript, but you can use custom properties as a proxy instead.

Tuesday, March 23rd, 2021

Service worker weirdness in Chrome

I think I’ve found some more strange service worker behaviour in Chrome.

It all started when I was checking out the very nice new redesign of WebPageTest. I figured while I was there, I’d run some of my sites through it. I passed in a URL from The Session. When the test finished, I noticed that the “screenshot” tab said that something was being logged to the console. That’s odd! And the file doing the logging was the service worker script.

I fired up Chrome (which isn’t my usual browser), and started navigating around The Session with dev tools open to see what appeared in the console. Sure enough, there was a failed fetch attempt being logged. The only time my service worker script logs anything is in the catch clause of fetching pages from the network. So Chrome was trying to fetch a web page, failing, and logging this error:

The service worker navigation preload request failed with a network error.

But all my pages were loading just fine. So where was the error coming from?

After a lot of spelunking and debugging, I think I’ve figured out what’s happening…

First of all, I’m making use of navigation preloads in my service worker. That’s all fine.

Secondly, the website is a progressive web app. It has a manifest file that specifies some metadata, including start_url. If someone adds the site to their home screen, this is the URL that will open.

Thirdly, Google recently announced that they’re tightening up the criteria for displaying install prompts for progressive web apps. If there’s no network connection, the site still needs to return a 200 OK response: either a cached copy of the URL or a custom offline page.

So here’s what I think is happening. When I navigate to a page on the site in Chrome, the service worker handles the navigation just fine. It also parses the manifest file I’ve linked to and checks to see if that start URL would load if there were no network connection. And that’s when the error gets logged.

I only noticed this behaviour because I had specified a query string on my start URL in the manifest file. Instead of a start_url value of /, I’ve set a start_url value of /?homescreen. And when the error shows up in the console, the URL being fetched is /?homescreen.

Crucially, I’m not seeing a warning in the console saying “Site cannot be installed: Page does not work offline.” So I think this is all fine. If I were actually offline, there would indeed be an error logged to the console and that start_url request would respond with my custom offline page. It’s just a bit confusing that the error is being logged when I’m online.

I thought I’d share this just in case anyone else is logging errors to the console in the catch clause of fetches and is seeing an error even when everything appears to be working fine. I think there’s nothing to worry about.

Update: Jake confirmed my diagnosis and agreed that the error is a bit confusing. The good news is that it’s changing. In Chrome Canary the error message has already been updated to:

DOMException: The service worker navigation preload request failed due to a network error. This may have been an actual network error, or caused by the browser simulating offline to see if the page works offline: see https://w3c.github.io/manifest/#installability-signals

Much better!

Sunday, March 7th, 2021

Imagining native skip links | Kitty Giraudel

I like this proposal, and I like that it’s polyfillable (which is a perfectly cromulent word).

Friday, February 19th, 2021

ignore the code: Bookfeed.io

Such an elegant idea!

Bookfeed.io is a simple tool that allows you to specify a list of authors, and generates an RSS feed with each author’s most recently released book.

Small pieces, loosely joined.

Tuesday, December 8th, 2020

What Makes CSS Hard To Master - Tim Severien

CSS is simple, but not easy.

If we, as a community, start to appreciate the complexity of writing CSS, perhaps we can ask for help instead of blaming the language when we’re confused or stuck. We might also stop looking down on CSS specialists.

Monday, November 16th, 2020

CSS Stats

A handy tool for getting an overview of your site’s CSS:

CSS Stats provides analytics and visualizations for your stylesheets. This information can be used to improve consistency in your design, track performance of your app, and diagnose complex areas before it snowballs out of control.

Friday, November 13th, 2020

An Ocean of Books

What you see is the big map of a sea of literature, one where each island represents a single author, and each city represents a book. The map represents a selection of 113 008 authors and 145 162 books.

This is a poetic experiment where we hope you will get lost for a while.

Tuesday, November 10th, 2020

aria-live

I wrote a little something recently about using ARIA attributes as selectors in CSS. For me, one of the advantages is that because ARIA attributes are generally added via JavaScript, the corresponding CSS rules won’t kick in if something goes wrong with the JavaScript:

Generally, ARIA attributes—like aria-hidden—are added by JavaScript at runtime (rather than being hard-coded in the HTML).

But there’s one instance where I actually put the ARIA attribute directly in the HTML that gets sent from the server: aria-live.

If you’re not familiar with it, aria-live is extremely useful if you’ve got any dynamic updates on your page—via Ajax, for example. Let’s say you’ve got a bit of your site where filtered results will show up. Slap an aria-live attribute on there with a value of “polite”:

<div aria-live="polite">
...dynamic content gets inserted here
</div>

You could instead provide a value of “assertive”, but you almost certainly don’t want to do that—it can be quite rude.

Anyway, on the face it, this looks like exactly the kind of ARIA attribute that should be added with JavaScript. After all, if there’s no JavaScript, there’ll be no dynamic updates.

But I picked up a handy lesson from Ire’s excellent post on using aria-live:

Assistive technology will initially scan the document for instances of the aria-live attribute and keep track of elements that include it. This means that, if we want to notify users of a change within an element, we need to include the attribute in the original markup.

Good to know!

Operator Lookup - Search JavaScript operators · Josh W Comeau

Operators in JavaScript—handy! I didn’t know about most of these.

Tuesday, October 27th, 2020

ARIA in CSS

Sara tweeted something recently that resonated with me:

Also, Pro Tip: Using ARIA attributes as CSS hooks ensures your component will only look (and/or function) properly if said attributes are used in the HTML, which, in turn, ensures that they will always be added (otherwise, the component will obv. be broken)

Yes! I didn’t mention it when I wrote about accessible interactions but this is my preferred way of hooking up CSS and JavaScript interactions. Here’s old Codepen where you can see it in action:

[aria-hidden='true'] {
  display: none;
}

In order for the functionality to work for everyone—screen reader users or not—I have to make sure that I’m toggling the value of aria-hidden in my JavaScript.

There’s another advantage to this technique. Generally, ARIA attributes—like aria-hidden—are added by JavaScript at runtime (rather than being hard-coded in the HTML). If something goes wrong with the JavaScript, the aria-hidden value isn’t set to “true”, which means that the CSS never kicks in. So the default state is for content to be displayed. There’s no assumption that the JavaScript has to work in order for the CSS to make sense.

It’s almost as though accessibility and progressive enhancement are connected somehow…

Wednesday, October 14th, 2020

How-to: Create accessible forms - The A11Y Project

Another five pieces of sweet, sweet low-hanging fruit:

  • Always label your inputs.
  • Highlight input element on focus.
  • Break long forms into smaller sections.
  • Provide error messages.
  • Avoid horizontal layout forms unless necessary.