Skip to main content



Safari is getting Web Push! (on the Webventures blog)

Roderick E.J.H. Gadellaa, author of the Webventures blog writes that at their June 2022 Worldwide Developers Conference (WWDC) Apple announced that it will bring Web Push (web-based push notifications) to Safari, including iOS Safari.

MacOS is going to get it first and iOS will receive it in a later iOS 16.x update, sometime in 2023.

This could be a big deal, because…

The lack of the web being able to do push notifications on iOS is probably the biggest reason why web developers see a potential project end up being built as a native app instead of a web app


Web Push on iOS will change the “we need to build a native app” decision.

I don’t like the idea that native mobile apps are superior to mobile web experiences, nor the notion that by having a native app you can ignore your small-screen web experience. PWAs and native apps can co-exist in harmony and address different use cases. But also web APIs are becoming more powerful all the time, and this announcement by Apple provides fuel for the argument that “you might not need a native app for that!”


How we think about browsers, on GitHub’s blog

Keith Cirkel of Github has written about how they think about browsers and it’s interesting. In summary Github achieve:

  • improved performance;
  • exploiting new native technologies; and
  • universal user access/inclusion

…via a progressive enhancement strategy that ensures a basic experience for all but delivers an enhanced experience to most. Their tooling gets a bit deep/exotic in places but I think the basic premise is:

  1. decide on what our basic experience is, then use native HTML combined with a bare minimum of other stuff to help old browsers deliver that; and
  2. exploit new JS features in our enhanced experience (the one most people will get) to make it super lean and fast

Pretty cool.


Using accessibility literacy to counter accessibility ignorance, by Devon Persing

The idea of accessibility literacy (having the right vocabulary, knowing the trustworthy info sources etc) makes sense.

The section on Accessibility ignorance and ableism presents some home truths about organisational attitudes to accessibility that need addressed.

Accessibility ignorance actually goes beyond just a lack of accessibility literacy. Accessibility ignorance is a facet of ableism, since it causes people to make decisions that actively harm disabled people.

  • Accessibility ignorance isn't usually malicious.
  • It's assuming that accessibility is taken care of because your organization has an accessibility specialist on staff, or has accessibility "baked in" to a design system.
  • It's providing accessibility training for only teams that build products and not people that work in support, legal, operations, leadership, or other parts of the organization.
  • It's expecting accessibility work to happen without impacting schedules and roadmaps that didn't originally take accessibility work into account.
  • It's assuming disabled people don't use your product.
  • It's not hiring disabled people.
  • It's hiring disabled people but only to do accessibility work.

The article wraps up with some great advice on cultivating accessibility literacy, and the senior buy-in needed to support it.


Getting Started With CSS Cascade Layers, by Stephanie Eckles

Yesterday I read Eric Meyer discussing CSS Cascade Layers and commenting that the speed at which it had transitioned from first public working draft to shipping as a full public release in every major desktop and mobile browser had made his head spin. Amazing stuff and an indicator of the turbo-boosted pace at which modern CSS is now evolving.

It also made me want to properly read up on Cascade Layers, because I knew some of the theory but now wanted to consider using it in practice. I’m no great fan of “cascade-taming” CSS frameworks like BEM and SUIT (although I acknowledge why we have them) so I’m interested to know if Cascade Layers can replace them. Stephanie Eckles’ article is an excellent primer.

Read my notes / Visit original


Refactoring a modal dialogue in 2022

My team will soon be refactoring our modal dialogue component. Ours has a few deficiencies, needs better developer experience and documentation, is not built to our Design System component standards, and could use a resilience boost from some progressive enhancement.

Read entry »


Does the HTML details element solve progressively-enhanced disclosures?

The HTML details element continues to gain fans and get developers’ juices flowing. Scott Jehl recently tweeted:

I love the details/summary HTML elements. So versatile. My favorite part is being able to show a collapsed state from the start without worrying about potential operability issues if JavaScript fails to run (since its behavior doesn't need it).

Scott goes on to describe how creating disclosure widgets (controls that hide and show stuff) with resilience in mind is so much more difficult when not using <details> since it can require complex progressive enhancement techniques. At the very least these involve making content available by default in case JavaScript fails, then hiding it when the disclosure widget script loads successfully, ideally without a jarring flash of content in between.

Read entry »


Min-Max clamp calculator, by 9elements

Here’s a handy tool from the smart folks at 9elements for making a value – such as a font-size, or margin – fluidly responsive. In their words the tool…

calculates the CSS clamp formula to interpolate between two values in a given viewport range.

Read my notes / Visit original


A better birthday input, by Vitaly Friedman

I recently signed up to Vitaly from Smashing Mag’s Smart Interface Design Patterns newsletter. This latest edition regarding “date of birth” inputs was interesting, and well timed as my work colleagues and I are about to revisit our form patterns. It’s a nice explainer on why we should approach UI for dates the user knows differently from UI for dates the user will choose.

Read my notes / Visit original


Tables and pseudo-tables: lessons and tactics

At work I have to think about complex HTML tables a lot. The challenge with doing tables well is that 99% of online table tutorials use fairly simple examples… whereas in reality design and product teams often want to squeeze in lots more. It’s really hard to balance those needs against accessibility, systemisation, styling and responsiveness.

Heads up: I’ve published this post early while it’s still a work in progress because it’s better for me to have it available for reference than languishing in drafts and forgotten. Apologies if you read it in a temporarily rough state.

Read entry »

External Link Bookmark Note Entry Search