The other day Jen Simmons solicited some open feedback about WebKit, asking what they might “need to add / change / fix / invent to help you?” First of all — brave. Brave of Jen to open her timeline up for everyone to vomit their opinions and snark. I, too, contributed my own bits of vomit to the thread.

Later in the thread, Jen asked me to elaborate about the “one-offs” issue and because blogs are cool, I thought I’d elaborate here.

The one-offs problem

When I think about Safari, it has a reputation as a little bit of a prima donna to the Pixar characters in my brain. From the humble -webkit-appearance: none to make buttons not look like trash on iOS to even more sophisticated tricks polyfilling scroll-behavior: smooth, every project has “one-offs” written inside it to appease Safari. It adds up to a non-zero amount of cognitive load that I maintain as a developer to support Safari.

The one-offs fall into three distinct categories of complaints:

  1. Stuff I do to appease Safari
  2. Stuff I don’t need anymore, but is still in my codebase.
  3. Stuff I didn’t use, but Safari has now

1. Stuff I do to appease Safari

There’s a handful of properties I use to make sites work in Safari. These may impact other browsers but that’s an unintentional side effect, these are purely for Safari to me.

  • appearance: none to fix buttons on iOS
  • Keeping up with <meta name="viewport"> rules: minimal-ui? viewport-fit=cover? This keeps changing
  • 100vh issues, solveable by height: -webkit-fill-available and a slew of new viewport units
  • -webkit-text-size-adjust: 100% and other hacks to prevent input zoom
  • iPhone env() notch negotiation
  • Monochrome SVG favicons
  • Polyfilling for scroll-behavior: smooth
  • The -webkit soup required to style any inputs like input type="range"
  • Double <meta name="theme-color"> for light/dark mode (Safari 15)

The common thread between these is that they exist to “solve” UI design choices made by Mobile Safari or physical design choices on the iPhone itself (rounded viewport and the notch).

I’m certainly missing some quirks (touch-action: manipulation?) that I can’t recall. If you, dear reader, claim I don’t need some of these anymore, that further demonstrates my problem! It has gotten to the point where I don’t know what I need/don’t need anymore, I keep carrying over these little tricks from project-to-project until I forget to add it and the world doesn’t fall over.

2. Stuff I don’t need anymore, but is still in my codebase.

We all have tricks and polyfills lurking in our codebases. Here’s some that I know I don’t need because Safari has made updates.

  • Custom date and time pickers (input type="date|time" added in 14.1)
  • -webkit-overflow-scrolling: touch (fixed in iOS 13)
  • Fastclick to workaround to remove 300ms tap delays (fixed in iOS 9.3)

My list here is short, but more “don’t needs” are on the horizon with loading="lazy", :focus-visible, and aspect-ratio coming soon to Safari. Which is something to get excited about.

Deprecation is actually a good problem to have! Browsers getting better. Compat going up. But until I delete these old polyfills from my projects, they’ll continue to occupy a space in my brain and it’s slow work. Removing old code requires a certain mindset. Last week I removed a <details> polyfill from my blog because I realized Edge got <details>/<summary> in it’s Chromium switch last year. Took me that long to realize I didn’t need it.

3. Stuff I didn’t use, but Safari has now

In re-reading Safari’s release notes for recent major versions, I realized there’s wonderful APIs we can and should use for even better websites. The availability of these new tools is something I need to retrain my brain about, because in the past I’ve punted on or redesigned features because of a lack of Safari support.

  • Individual transform properties for translate, rotate, and scale (Safari 14.1)
  • Flex gap (Safari 14.1)
  • Intl operations like NumberFormat and ListFormat (Safari 14.1)
  • date, time, and datetime-local inputs (Safari 14.1)
  • Web Speech API (Safari 14.1)
  • HTTP/3 (Safari 14)
  • Biometric logins (Touch ID/Face ID) with the WebAuthentication API (Safari 14)
  • WebP (Safari 14)
  • :is() and :where() (Safari 14)
  • Web Animation API (Safari 13.1)
  • Resize Observer (Safari 13.1)
  • enterkeyhint (Safari 13.1)
  • Font keywords: ui-serif, ui-sans-serif, ui-monospace ,and ui-rounded (Safari 13.1)
  • CSS Conic gradients (Safari 13)
  • inputmode attribute (Safari 12.2) (Mobile Safari only)
  • <input type="color"> (Safari 12.1)
  • <datalist> (Safari 12.1)
  • Web Share API (Safari 12.1)
  • Intersection Observer (Safari 12.1)
  • Updated rgb() color function (Safari 12.1)
  • passwordrules attribute (Safari 12)
  • autocomplete="username|current-password|new-password" (Safari 12)
  • autocomplete="one-time-code" for 2FA (Safari 12)

These features are great, but I had to dig them up out of release notes becuase I didn’t know off-hand. This is to say, keeping up with what’s in and what’s out of Safari is a bit of a chore… and I’m a person who keeps up with browsers! I’m in the Open UI CG, I’m in the Web Components CG, and I’m a pundit on a web development podcast. If it’s difficult for me, it’s probably even more difficult for everyone else. More education or broadcasting updated webcompat would go a long way.

But there’s a larger problem looming…

The low-expectations about new features problem

My final point is about sorely needed features. A lot of my pain points are almost psychosomatic; time spent wondering about features I want but don’t know if I’ll ever get.

As a member of the Web Components Community Group I’m privy to a lot of ideas and discussions happening in that space. For example, a Context API for Web Components created by people at Adobe would launch a whole new era of component systems based on actual Web Components. But the future for these features is uncertain and it 100% comes down to whether Apple is on board with the plan. The quickest way to wet-blanket any discussion is to ask “Does anyone know what WebKit thinks?” Google’s there, Adobe’s there, Salesforce is there, RedHat is there, Dave Rupert LLC is there, but Apple is not. Discussions get iceboxed until the next TPAC.

There’s a lot of history here. WebKit — being a part of Apple — plays it slow and a bit close to the chest. Historically, they’re pretty tight-lipped about the small number of features they’re working on and uninvolved in community outreach. Quarterly updates to Safari Technical Preview have been an awesome consolation prize, but after years of waiting I find my expectations for the annual release of Safari (specifically Mobile Safari) are intolerably low. This creates an increasing amount of apathy in me that the situation with Safari will get better soon.

Some people can succinctly quantify their list of feature requests. I love that. I’ll take whatever I can get, but my short list of pet projects would be Container Queries, scoped styles, and any other specs written by Miriam; but my problem isn’t feature requests, my problem is patience.

If I could ask for anything, it’d be that Apple loosen the purse strings and let Webkit be that warehouse for web innovation that it was a decade ago.