Tags: feature

49

sparkline

Tuesday, September 7th, 2021

Using the platform

Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:

  • use custom elements (for modular HTML without frameworks)
  • use the in-browser package manager (for JavaScript packages without build tools)
  • match pages with files (to avoid routing and simplify architecture)
  • stick to standards (to avoid obsolescence and framework fatigue)

Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!

Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.

I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.

Thursday, August 19th, 2021

Is Safari the new Internet Explorer?

The transcript from the latest episode of the HTTP 203 podcast is well worth perusing.

  • Internet Explorer halted development, no innovation. Would you say Safari is the new IE?
  • There was loads of stuff missing. Is Safari the new IE?
  • My early career was built on knowing the bugs in IE6 and how to solve them. Is Safari the new IE?
  • Internet Explorer 6, it had a really slow JavaScript engine, performance was bad in that browser. Is Safari the new IE?
  • Internet Explorer had a fairly cavalier attitude towards web standards. Is Safari the new IE?
  • Back in the day that we had almost no communication whatsoever. Is Safari the new IE?
  • Slow-release cycle. Is Safari the new IE?

Tuesday, August 17th, 2021

SafarIE

I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.

But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:

I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.

It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.

On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.

And the verdict? Well, you’ll just to have to listen to the podcast episode.

If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.

When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.

Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).

I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.

Update: the bug with that episode of the HTTP 203 podcast has been fixed. Here’s the transcript! And all future episodes will have transcripts too:

Thursday, August 5th, 2021

Updating Safari

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.

Friday, July 30th, 2021

For developers, Apple’s Safari is crap and outdated – Perry Sun | Blog

Apple dragged their feet in adding support for PWAs in Safari, and when they finally did, limited the capabilities of a PWA so that native-like app functionality wouldn’t be possible, like notifications or a home screen icon shortcut – to name just a few of the many restrictions imposed by Apple.

But it goes beyond that. On iOS, the only web rendering engine allowed is Apple’s own WebKit, which runs Safari. Third-party iOS browsers such as Chrome can only use WebKit, not their own engines (as would be permitted in Windows, Android, or macOS). And it’s WebKit that governs PWA capabilities.

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.

The enormous popularity of iOS makes it all the more annoying that Apple continues to hold back developers from being able to create great experiences over the web that work across all platforms.

Wednesday, July 28th, 2021

One-offs and low-expectations with Safari - daverupert.com

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.

Monday, October 19th, 2020

Continuous partial browser support

Vendor prefixes didn’t work. The theory was sound. It was a way of marking CSS and JavaScript features as being experimental. Developers could use the prefixed properties as long as they understood that those features weren’t to be relied upon.

That’s not what happened though. Developers used vendor-prefixed properties as though they were stable. Tutorials were published that basically said “Go ahead and use these vendor-prefixed properties and ship it!” There were even tools that would add the prefixes for you so you didn’t have to type them out for yourself.

Browsers weren’t completely blameless either. Long after features were standardised, they would only be supported in their prefixed form. Apple was and is the worst for this. To this day, if you want to use the clip-path property in your CSS, you’ll need to duplicate your declaration with -webkit-clip-path if you want to support Safari. It’s been like that for seven years and counting.

Like capitalism, vendor prefixes were one of those ideas that sounded great in theory but ended up being unworkable in practice.

Still, developers need some way to get their hands on experiment features. But we don’t want browsers to ship experimental features without some kind of safety mechanism.

The current thinking involves something called origin trials. Here’s the explainer from Microsoft Edge and here’s Google Chrome’s explainer:

  • Developers are able to register for an experimental feature to be enabled on their origin for a fixed period of time measured in months. In exchange, they provide us their email address and agree to give feedback once the experiment ends.
  • Usage of these experiments is constrained to remain below Chrome’s deprecation threshold (< 0.5% of all Chrome page loads) by a system which automatically disables the experiment on all origins if this threshold is exceeded.

I think it works pretty well. If you’re really interested in kicking the tyres on an experimental feature, you can opt in to the origin trial. But it’s very clear that you wouldn’t want to ship it to production.

That said…

You could ship something that’s behind an origin trial, but you’d have to make sure you’re putting safeguards in place. At the very least, you’d need to do feature detection. You certainly couldn’t use an experimental feature for anything mission critical …but you could use it as an enhancement.

And that is a pretty great way to think about all web features, experimental or otherwise. Don’t assume the feature will be supported. Use feature detection (or @supports in the case of CSS). Try to use the feature as an enhancement rather than a dependency.

If you treat all browser features as though they’re behind an origin trial, then suddenly the landscape of browser support becomes more navigable. Instead of looking at the support table for something on caniuse.com and thinking, “I wish more browsers supported this feature so that I could use it!”, you can instead think “I’m going to use this feature today, but treat it as an experimental feature.”

You can also do it for well-established features like querySelector, addEventListener, and geolocation. Instead of assuming that browser support is universal, it doesn’t hurt to take a more defensive approach. Assume nothing. Acknowledge and embrace unpredictability.

The debacle with vendor prefixes shows what happens if we treat experimental features as though they’re stable. So let’s flip that around. Let’s treat stable features as though they’re experimental. If you cultivate that mindset, your websites will be more robust and resilient.

Monday, September 28th, 2020

The Empty Box | CSS-Tricks

This is an excellent framing for minimal viable products—what would the black box theatre production be?

Forget about all the production and complexity you could build. What’s the purpose you want to convey at the core?

Identify core functionality.

Friday, July 31st, 2020

On the origin of cascades

This is a great talk by Hidde, looking at the history and evolution of cascading style sheets. Right up my alley!

Tuesday, July 14th, 2020

Accessibility

There’s a new project from Igalia called Open Prioritization:

An experiment in crowd-funding prioritization of new feature implementations for web browsers.

There is some precedent for this. There was a crowd-funding campaign for Yoav Weiss to implement responsive images in Blink a while back. The difference with the Open Prioritization initiative is that it’s also a kind of marketplace for which web standards will get the funding.

Examples include implementing the CSS lab() colour function in Firefox or implementing the :not() pseudo-class in Chrome. There are also some accessibility features like the :focus-visible pseudo-class and the inert HTML attribute.

I must admit, it makes me queasy to see accessibility features go head to head with other web standards. I don’t think a marketplace is the right arena for prioritising accessibility.

I get a similar feeling of discomfort when a presentation or article on accessibility spends a fair bit of time describing the money that can be made by ensuring your website is accessible. I mean, I get it: you’re literally leaving money on the table if you turn people away. But that’s not the reason to ensure your website is accessible. The reason to ensure that your website is accessible is that it’s the right thing to do.

I know that people are uncomfortable with moral arguments, but in this case, I believe it’s important that we keep sight of that.

I understand how it’s useful to have the stats and numbers to hand should you need to convince a sociopath in your organisation, but when numbers are used as the justification, you’re playing the numbers game from then on. You’ll probably have to field questions like “Well, how many screen reader users are visiting our site anyway?” (To which the correct answer is “I don’t know and I don’t care”—even if the number is 1, the website should still be accessible because it’s the right thing to do.)

It reminds of when I was having a discussion with a god-bothering friend of mine about the existence or not of a deity. They made the mistake of trying to argue the case for God based on logic and reason. Those arguments didn’t hold up. But had they made their case based on the real reason for their belief—which is faith—then their position would have been unassailable. I literally couldn’t argue against faith. But instead, by engaging in the rules of logic and reason, they were applying the wrong justification to their stance.

Okay, that’s a bit abstract. How about this…

In a similar vein to talks or articles about accessibility, talks or articles about diversity often begin by pointing out the monetary gain to be had. It’s true. The data shows that companies that are more diverse are also more profitable. But again, that’s not the reason for having a diverse group of people in your company. The reason for having a diverse group of people in your company is that it’s the right thing to do. If you tie the justification for diversity to data, then what happens should the data change? If a new study showed that diverse companies were less profitable, is that a reason to abandon diversity? Absolutely not! If your justification isn’t tied to numbers, then it hardly matters what the numbers say (though it does admitedly feel good to have your stance backed up).

By the way, this is also why I don’t think it’s a good idea to “sell” design systems on the basis of efficiency and cost-savings if the real reason you’re building one is to foster better collaboration and creativity. The fundamental purpose of a design system needs to be shared, not swapped out based on who’s doing the talking.

Anyway, back to accessibility…

A marketplace, to me, feels like exactly the wrong kind of place for accessibility to defend its existence. By its nature, accessibility isn’t a mainstream issue. I mean, think about it: it’s good that accessibility issues affect a minority of people. The fewer, the better. But even if the number of people affected by accessibility were to trend downwards and dwindle, the importance of accessibility should remain unchanged. Accessibility is important regardless of the numbers.

Look, if I make a website for a client, I don’t offer accessibility as a line item with a price tag attached. I build in accessibility by default because it’s the right thing to do. The only way to ensure that accessibility doesn’t get negotiated away is to make sure it’s not up for negotiation.

So that’s why I feel uncomfortable seeing accessibility features in a popularity contest.

I think that markets are great. I think competition is great. But I don’t think it works for everything (like, could you imagine applying marketplace economics to healthcare or prisons? Nightmare!). I concur with Iain M. Banks:

The market is a good example of evolution in action; the try-everything-and-see-what- -works approach. This might provide a perfectly morally satisfactory resource-management system so long as there was absolutely no question of any sentient creature ever being treated purely as one of those resources.

If Igalia or Mozilla or Google or Apple implement an accessibility feature because they believe that accessibility is important and deserves prioritisation, that’s good. If they implement the same feature just because it received a lot of votes …that doesn’t strike me as a good thing.

I guess it doesn’t matter what the reason is as long as the end result is the same, right? But I suspect that what we’ll see is that the accessibility features up for bidding on Open Prioritization won’t be the winners.

Saturday, June 13th, 2020

CSS Custom Properties Fail Without Fallback · Matthias Ott – User Experience Designer

Matthias has a good solution for dealing with the behaviour of CSS custom properties I wrote about: first set your custom properties with the fallback and then use feature queries (@supports) to override those values.

Friday, May 1st, 2020

The beauty of progressive enhancement - Manuel Matuzović

Progressive Enhancement allows us to use the latest and greatest features HTML, CSS and JavaScript offer us, by providing a basic, but robust foundation for all.

Some great practical examples of progressive enhancement on one website:

  • using grid layout in CSS,
  • using type="module" to enhance a form with JavaScript,
  • using the picture element to provide webp images in HTML.

All of those enhancements work great in modern browsers, but the underlying functionality is still available to a browser like Opera Mini on a feature phone.

Monday, February 10th, 2020

Custom Styling Form Inputs With Modern CSS Features | CSS-Tricks

It’s now easier than ever to style form controls without sacrificing semantics and accessibility:

The reason is that we can finally style the ::before and ::after pseudo-elements on the <input> tag itself. This means we can keep and style an <input> and won’t need any extra elements. Before, we had to rely on the likes of an extra <div> or <span>, to pull off a custom design.

The demo is really nice. And best of all, you can wrap all of these CSS enhancements in a feaure query:

Hopefully, you’re seeing how nice it is to create custom form styles these days. It requires less markup, thanks to pseudo-elements that are directly on form inputs. It requires less fancy style switching, thanks to custom properties. And it has pretty darn good browser support, thanks to @supports.

Thursday, January 16th, 2020

Intent to Deprecate and Freeze: The User-Agent string - Google Groups

Excellent news! All the major browsers have agreed to freeze their user-agent strings, effectively making them a relic (which they kinda always were).

For many (most?) uses of UA sniffing today, a better tool for the job would be to use feature detection.

Tuesday, October 29th, 2019

Using the Platform | TimKadlec.com

Tim ponders the hard work that goes into adding standards to browsers, giving us a system with remarkable longevity.

So much care and planning has gone into creating the web platform, to ensure that even as new features are added, they’re added in a way that doesn’t break the web for anyone using an older device or browser. Can you say the same for any framework out there?

His parting advice is perfect:

Use the platform until you can’t, then augment what’s missing. And when you augment, do so with care because the responsibility of ensuring the security, accessibility, and performance that the platform tries to give you by default now falls entirely on you.

Wednesday, July 24th, 2019

Jon Aizlewood · Agile and design — How to avoid Frankensteining your product

Jon’s ranting about Agile here, but it could equally apply to design systems:

Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.

Monday, July 1st, 2019

8 DOM features you didn’t know existed - LogRocket Blog

If you ignore the slightly insulting and condescending clickbaity title, this is a handy run-down of eight browser features with good support:

  1. extra arguments in addEventListener(),
  2. scrollTo(),
  3. extra arguments in setTimeout() and setInterval(),
  4. the defaultChecked property for checkboxes,
  5. normalize() and wholeText for strings of text,
  6. insertAdjacentElement() and insertAdjacentText(),
  7. event.detail, and
  8. scrollHeight and scrollWidth.

Friday, February 1st, 2019

Limiting JavaScript? - TimKadlec.com

Following on from that proposal for a browser feature that I linked to yesterday, Tim thinks through all the permutations and possibilities of user agents allowing users to throttle resources:

If a limit does get enforced (it’s important to remember this is still a big if right now), as long as it’s handled with care I can see it being an excellent thing for the web that prioritizes users, while still giving developers the ability to take control of the situation themselves.

Thursday, August 30th, 2018

The Complete CSS Demo for OpenType Features - OpenType Features in CSS

Every single font-feature-settings value demonstrated in one single page.

Tuesday, August 7th, 2018

Coming to a browser near you - faster than ever before!

A great long-term perspective from Rachel on the pace of change in standards getting shipped in browsers:

The pace that things are shipping, and at which bugs are fixed is like nothing we have seen before. I know from sitting around a table with representatives from each browser vendor at the CSS Working Group how important interop is. No-one wants features to be implemented differently in browsers. This is what we were asking for with WaSP, and despite the new complexity of the platform, browsers rendering standard features in different ways is becoming increasingly rare. Bugs happen, sometimes in the browser and sometimes in the spec, but there is a commitment to avoid these and to create a stable platform we can all rely on. It is exciting to be part of it.