cross-browser – CSS-Tricks

Scroll Shadows? Pure CSS Parallax? Game Back On.

Geoff Graham — Fri, 29 Jul 2022 14:55:31 +0000

Chris calls scroll shadows one his favorite CSS-Tricks of all time. Lea Verou popularized the pure CSS approach using four layered background gradients with some clever background-attachment magic. The result is a slick scrolling interaction that gives users a hint that additional content is available in a scrollable container.

CodePen Embed Fallback

Just one problem: it broke in Safari iOS 13. One day it was all good. The next, not so much. And that wasn’t the only thing affected. Keith Clark’s CSS-only parallax effect also stopped working right about then.

Well, reader Ronald wrote in to say that all is working once again! In fact, I’m writing this on my iPad (Safari 15.5) right now and Chris’s demo is looking sharp as ever. So is Keith’s original demo.

So, what broke it? We still don’t know. But the Safari 13 release notes offer clues:

Added support for one-finger accelerated scrolling to all frames and overflow:scroll elements eliminating the need to set-webkit-overflow-scrolling: touch.
Changed the default behavior on iPad for wide web pages with responsive meta-tags that require horizontal scrolling. Pages are scaled to prevent horizontal scrolling and any text is resized to preserve legibility.

When was it fixed and what fixed it? Well, on the scroll shadow side, the Safari 15.4 included some work on background-attachment: local that may have done the trick. On the parallax side, Safari 14.1 added support for individual transform properties… so maybe that?

Scroll Shadows? Pure CSS Parallax? Game Back On. originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

“Evergreen” Does Not Mean Immediately Available

Eric Bailey — Tue, 01 Feb 2022 15:38:41 +0000

I have a coworker who is smart, capable, and technologically-literate. Like me, they work on the web full-time.

When they are sharing their screen in a meeting, I find myself ~~disassociating~~ fixating on the red update button in their copy of Chrome.

Clicking this button would start the process to update Chrome to the latest stable version.

I’ve asked some probing questions about how frequently they reboot, which would also force Chrome to update upon relaunch. That’s the point of an “evergreen” browser, right? It’s easy to make sure you’re always using the latest and greatest version.

It turns out they prefer to wait until they absolutely have to because of the disruption it would cause in their daily workflow. Their behavior makes sense. They are prioritizing the quality of their overall computing experience, rather than catering to the demands of one specific app.

Like me, my coworker also uses a top-of-the-line laptop to get things done. This means that the laptop can go for months without needing a reboot. Ironically, this might be a situation where a craptop is conditionally forced to have a faster browser upgrade path.

Evergreen browsers

Before the advent of evergreen browsers, you would need to go to the manufacturer’s website and manually download and install the update. Prior to that you had to use a CD or floppy disk.

Source: Floppy Disk of Netscape Navigator. Toshihiro Oimatsu, CC BY 2.0, via Wikimedia Commons.

By contrast, an evergreen browser is any browser that can automatically update itself. By this, I mean the browser will automatically pull down the code required to add new features and fix bugs once it has been released by the browser’s manufacturer. The update itself occurs with:

a prompt shown to the person using the browser that triggers an application restart,
a download that happens in the background and gets applied on application restart, or
on device restart.

The browsers themselves

Nearly all major browsers are evergreen. This includes Google Chrome, Microsoft Edge, and Mozilla Firefox.

Apple Safari is quasi-evergreen. By this I mean it automatically receives updates, but awkwardly requires them to be done via the macOS operating system update interface, where other system-wide updates are located.

If you haven’t been paying attention, the Safari team has been making a ton of improvements to their browser in the past few months—I’d love to see them continue with this trend by making the browser update path decoupled from existing macOS and iOS upgrade workflows.

The situation

With the actual, final, no-seriously-we-mean-it-this-time death of Internet Explorer, evergreen browsers are now the main consideration for desktop and laptop browsers. This is great! It means we can spend a lot less time fretting about who can use what.

Spending less time does not mean spending no time, however.

Delayed effects

Support from all evergreen browsers on caniuse.com does not necessarily mean support exists on the device a person is using—updates that have been pushed out don’t automatically get instantly applied.

Because of these two factors, I advocate for tempering your excitement with some restraint. It can be very tempting to rush and use the new and the shiny. Believe me, I’m not exempt from this urge—CSS is about to go from great to amazing, and the urge to use new features is very real.

Instead, wait a bit. Work with the platform’s ability to create progressively enhanced experiences with CSS and JavaScript.

Leverage the platform

The web is really good at being resilient, provided you work with its grain.

Both CSS and JavaScript have the ability to conditionally serve up experiences for browsers that support new features while providing alternatives for those that don’t.

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.”
—Jeremy Keith, “Continuous partial browser support”

JavaScript

You can use JavaScript to query whether or not a browser supports a certain feature. For example, the Navigator interface provides a mechanism for querying a user agent’s capabilities.

if (!(“geolocation” in navigator)) {
  // Logic if a user's current geographic location isn't available
} else {
  // Logic that is based on a user's current geographic location
}

In this example, I am inverting a request for support for a browser’s Geolocation interface. Although its syntax is initially a little confusing to parse, it helps emphasize a progressive enhancement approach.

Assume geolocation functionality isn’t supported to start and provide a way to accommodate the person using this browser (say manually typing in a ZIP Code, etc.). With this use case covered, you can then confidently build an experience for browser that support geolocation.

This thinking also extends to all other browser features and capabilities.

CSS

Like most other programming languages, CSS also lets us use if-like statements.

For example, the @supports at rule allows you to create a conditional statement that targets whether or not a browser supports something, and then apply logic to it. Browsers that honor the feature will utilize those styles, and browsers that don’t will ignore them. It is a concise, clever, adaptable solution.

.component {
  /* Base appearance */
}

@supports (grid-template-columns: subgrid;) {
  .component {
    /* Styling and positioning enhancement tweaks if subgrid is supported */
  }
}

For this example, this progressive enhancement approach ensures that a component’s content and functionality is preserved for every browser, but only creates fancy layouts for browsers capable of supporting them.

When can I remove this stuff?

Yes, this approach adds more code, and more code means more complexity and maintenance. But it’s very important code. You might even call it technical debt and you’d be correct. But technical debt can be a good thing, like an investment in the future.

You may want to remove that complexity when it’s no longer needed. Knowing the right time to do that in this age of evergreen browsers is difficult, but I have a couple of suggestions:

Patience is a virtue

In terms of waiting, I’d advise a conservative 6-ish months from release of a new feature before even beginning to think about investigating if you can remove feature detection. This accounts for:

Reboots
Update procrastinators
Update avoiders
Hardware refresh cycles
Corporate update policies,
etc.

I would also say that rough six month timeframe is in terms of a general, global web audience. This guesstimate changes if you cater to a specialized audience. The way to know who you actually serve? Analytics, yes, but also talking to people.

Maybe don’t

Remember: survivor bias is real. Is the brand new feature you’re using preventing someone from using your website or web app? I say this because some people:

are forced to use a device that is managed by a third party,
deliberately avoid updating their hardware and software for fear of losing the ability to interact with the world,
understand their device is the problem, but don’t have the knowledge for how to fix it, and
use “dead” evergreen browsers, devices that used to receive browser updates, but are no longer supported by their manufacturer.

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.

The future is uncertain

We’re long past the age of desktop computers. Browsers are showing up in more and more places: phones, tablets, watches, ebook readers, digital cameras, kiosks, televisions, home assistants, vending machines, photo frames, graphing calculators, ATMs, point of sale terminals, exercise equipment, video game consoles, billboards, refrigerators, virtual reality, and cars.

Who knows what devices browsers will be included with in the future, or what capabilities they’ll have? Future-proof (and, er, past-proof) yourself with an approach that accommodates it.

Thank you to to Jim Nielsen for their feedback.

“Evergreen” Does Not Mean Immediately Available originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

On Browser-Specific URL Schemes

Chris Coyier — Tue, 26 Oct 2021 20:06:29 +0000

We’ve covered URL schemes:

A URL Scheme is like “http://…” or “ftp://…”. Those seem like a very low-level concept that you don’t have much control over, but actually, you do!

I’d call it non-trivial, but developers can register new URL schemes in apps that users install. Back in 2017, Microsoft Edge did this:

microsoft-edge://

If you use that, the behavior is to open the URL in Microsoft Edge — even if you’ve chosen a different default browser. So if I, as a blogger, wanted to essentially force you to use Edge for this site, I could, by starting every single URL with this URL scheme. I won’t, but I could. And so could Microsoft.

At the time, Daniel Aleksandersen wrote a program called EdgeDefelector to circumvent that behavior and explained:

I don’t hate Microsoft Edge — maybe you do! — but I do believe users who have bothered to configure a different default web browser should be allowed to keep using that default web browser.

This has come back into the public eye a bit as the Brave browser now supports the microsoft-edge:// URL scheme. Apparently, not only does an app need to register a URL scheme, but other apps that support clicks-on-links need to honor it too. Firefox is also thinking of adding it. I think the risk of not supporting the URL scheme is that clicks on links like that could do nothing instead of actually opening the URL.

A lot of the talk is about Windows 11. But here on my Mac, I see this URL scheme do what it intends across all these browsers.

Safari

Chrome

Firefox

Brave

Daniel goes further:

So, how did we get here? Until the release of iOS version 14 in September 2020, you couldn’t change the default web browser on iPhones and iPads. Google has many apps for iOS, including a shell for its Chrome browser. To tie all its apps together, Google introduced a googlechrome: URL scheme in February 2014. It could use these links to direct you from its Search or Mail app and over to Chrome instead of Apple’s Safari browser.

Here’s my iPhone 13 opening googlechrome://css-tricks.com with and without Google Chrome installed.

iOS Safari with Google Chrome installed

iOS Safari without Google Chrome installed

Seems like that would be Google’s sin, but it is apparently Apple that allowed it on iOS. Daniel once more:

The original sin was Apple’s, but Microsoft is gulping the juice of the apple with gusto.

I’m not as boned up on all this as I should be, but I think if I made software that was involved here, I’d be tempted to intercept these URL schemes and have them open in the browser the user is already in. The web is the web, there should be no reason any given URL has to open in any specific browser.

On Browser-Specific URL Schemes originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

@supports selector()

Chris Coyier — Tue, 19 Oct 2021 21:12:18 +0000

I didn’t realize the support for @supports determining selector support was so good! I usually think of @supports as a way to test for property: value pair support. But with the selector() function, we can test for selector support as well. It looks like this:

@supports selector(:nth-child(1 of .foo)) {

}

You just drop the selector right between the parens and that’s what it tests for.

That selector above is a pretty good test, actually. It’s a “selector list argument” that works for the :nth-child ‘n’ friends selectors. As I write, it’s only supported in Safari.

So let’s say your ideal situation is that the browser supports this selector. Here’s an example. You know that with

. But also say this list needs separators, so you (and I’m not saying this is a great idea) did this kind of thing:
```
  List item
  List item
  
  /* ... */
```
Then you also want to zebra-stripe the list. And, if you want zebra striping, you need to select every other .list-item, ignoring the .separator. So…
```
li:nth-child(odd of .list-item) {
  background: lightgoldenrodyellow;
}
```
But only Safari supports that… so you can do:
```
@supports selector(:nth-child(1 of .foo)) {
  li:nth-child(odd of .list-item) {
    background: lightgoldenrodyellow;
  }
}
```
If you didn’t care what the fallback was, you wouldn’t even have to bother with the @supports at all. But say you do care about the fallback. Perhaps in the supported situation, the zebra striping does the heavy lifting of the UX you are shooting for, so all you need for the seperator is a bit of space. But for non-supporting browsers, you’ll need something beefier because you don’t have the zebra striping.

So now you can style both situations:
```
@supports selector(:nth-child(1 of .foo)) {
  li {
    padding: 0.25em;
  }
  li:nth-child(odd of .list-item) {
    background: lightgoldenrodyellow;
  }
  li.separator {
    list-style: none;
    margin: 0.25em 0;
  }
}
@supports not selector(:nth-child(1 of .foo)) {
  li.separator {
    height: 1px;
    list-style: none;
    border-top: 1px dashed purple;
    margin: 0.25em 0;
  }
}
```
If we get the @when syntax, then we can write it a little cleaner:
```
/* Maybe? */
@when supports(selector(:nth-child(1 of .foo))) {

} @else {

}
```
Anyway. The end result is…

Supported

Not Supported

There is a JavaScript API for testing support as well. I wasn’t sure if this would actually work, but it appears to! This fails in Chrome and passes in Safari as I write:
```
CSS.supports("selector(:nth-child(1 of .foo))")
```
While I was putting this together, I was thinking… hmmmmmmm — what CSS selectors are out there that have weird cross-browser support? It’s really not that many. And even of those that do have weird cross-browser support, thinking of the number of use-cases where you care to actually wrap it in an @supports (rather than just let it fail) is fairly few.

The ::marker pseudo-element would have been a great one, but it’s pretty well supported now. I was thinking the case-insensitive attribute selector, like [href$="pdf" i], would have been a good one, but nope, also well supported. Same deal with the comma-separated :not(a, .b, [c]). Maybe something like :fullscreen / :-webkit-full-screen would be interesting and useful because it’s uniquely not supported in iOS Safari?

@supports selector() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

iOS Browser Choice

Chris Coyier — Tue, 28 Sep 2021 14:26:23 +0000

Just last week I got one of those really?! 🤨 faces when this fact came up in conversation amongst smart and engaged fellow web developers: there is no browser choice on iOS. It’s all Safari. You can download apps that are named Chrome or Firefox, or anything else, but they are just veneer over Safari. If you’re viewing a website on iOS, it’s Safari.

I should probably call it what the App Store Review Guidelines call it: WebKit. I usually think it’s more clear to refer to browsers by their common names rather than the engine behind it, since each of The Big Three web browsers have distinct engines (for now anyway), but in this case, the engine is the important bit.

I’ll say how I feel: that sucks. I have this expensive computer in my pocket and it feels unfair that it is hamstrung in this very specific way of not allowing other browser engines. I also have an Apple laptop and it’s not hamstrung in that way, and I really hope it never is.

There is, of course, all sorts of nuance to this. My Apple laptop is hamstrung in that I can’t just install whatever OS I want on it unless I do it a sanctioned way. I also like the fact that there is some gatekeeping in iOS apps, and sometimes wish it was more strict. Like when I try to download simple games for my kid, and I end up downloading some game that is so laden with upsells, ads, and dark patterns that I think the developer should be in prison. I wish Apple just wouldn’t allow that garbage on the App Store at all. So that’s me wishing for more and less gatekeeping at the same time.

But what sucks about this lack of browser choice on iOS isn’t just the philosophy of gatekeeping, it’s that WebKit on iOS just isn’t that great. See Dave’s post for a rundown of just some of the problems from a day-to-day web developer perspective that I relate to. And because WebKit has literally zero competition on iOS, because Apple doesn’t allow competition, the incentive to make Safari better is much lighter than it could (should) be.

It’s not something like Google’s AMP, where if you really dislike it you can both not use it on your own sites and redirect yourself away from them on other sites. This choice is made for you.

My ability to talk intelligently about this is dwarfed by many others though, so what I really want to do is point out some of that recent writing. Allow me to pull a quote from a bunch of them…

iOS Engine Choice In Depth — Alex Russell

None of this is theoretical; needing to re-develop features through a straw, using less-secure, more poorly tested and analyzed mechanisms, has led to serious security issues in alternative iOS browsers. Apple’s policy, far from insulating responsible WebKit browsers from security issues, is a veritable bug farm for the projects wrenched between the impoverished feature set of Apple’s WebKit and the features they can securely deliver with high fidelity on every other platform.
This is, of course, a serious problem for Apple’s argument as to why it should be exclusively responsible for delivering updates to browser engines on iOS.

Chrome is the new Safari. And so are Edge and Firefox. — Niels Leenheer

The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.
Google is focussing on improving the web by making it more capable. To expand the relevance of the web, to go beyond what is possible today. And that also means allowing it to compete with native apps, with which the Android team surely does not always agree.
Safari seems to focus on improving the web as it currently is. To let it be a safer place, much faster and more beautiful. And if you want something more, you can use an app for that.

Browser choice on Apple’s iOS: privacy and security aspects ? Stuart Langridge

Alternative browsers on iOS aren’t just restricted to WebKit, they’re restricted to the version of WebKit which is in the current version of Safari. Not even different or more modern versions of WebKit itself are allowed.
Even motivated users who work hard to get out of the browser choice they’re forced into don’t actually get a choice; if they choose a different browser, they still get the same one. If there’s a requirement from people for something, the market can’t provide it because competition is not permitted.

Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps — Bruce Lawson

[…] these people at Echo Pharmacy, not only have they got a really great website, but they also have to build an app for iOS just because they want to send push notifications. And, perhaps ironically, given Apple’s insistence that they do all of this for security and privacy, is that if I did choose to install this app, I would also be giving it permission to access my health and fitness data, my contact info, my identifiers sensitive info, financial info, user content, user data and diagnostics. Whereas, if I had push notifications and I were using a PWA, I’d be leaking none of this data.
So, we can see that despite Apple’s claims, I cannot recommend a PWA as being an equal experience an iOS simply here because of push notifications. But it’s not just hurting current business, it’s also holding back future business.

I’ve heard precious few arguments defending Apple’s choice to only allow Safari on iOS. Vague Google can’t be trusted sentiment is the bulk of it, privacy-focused, performance forced, or both. All in all, nobody wants this complete lack of choice but Apple.

As far as I know, there isn’t any super clear language from Apple on why this requirement is in place. That would be nice to hear, because maybe then whatever the reasons are could be addressed.

We hear mind-blowing tech news all the time. I’d love to wake up one morning and have the news be “Apple now allows other browser engines on iOS.” You’ll hear a faint yesssssss in the air because I’ve screamed it so loud from my office in Bend, Oregon, you can hear it at your house.

iOS Browser Choice originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

System *Things

Chris Coyier — Mon, 28 Jun 2021 22:14:22 +0000

I think we’re all largely aware of colors like this:

color: OldLace;
background: rebeccapurple;

I guess you’d just call those “named colors” in CSS.

Those aren’t the only kind of named colors there are though. Some of them are a bit more fluid. Jim Nielsen was blowin’ minds the other day when he blogged about System Colors.

What I need is a way to say “hey browser, for my dropdown, use the same black (or white if in light mode) that you’re using for the background color of the document”. I need access to a variable of sorts that references the exact “black” the browser is using.

Then, via Jim referencing Thomas Steiner, I discovered there are literally CSS system colors. These aren’t colors that are (or at least attempt to be) the same across all browsers, but they are allowed to be set by “choices made by the user, the browser, or the OS.” So for example, Canvas is the “background of application content or documents.” Case in point: the background-color for dark mode is #1e1e1e in Safari and #121212 in Chrome. If you like that, meaning you’re leaning into what the browser thinks is a good color for things, then you can now access it through that Canvas keyword.

System colors! There are a bunch of them.

Canvas
CanvasText
LinkText
VisitedText
ActiveText
ButtonFace
ButtonText
ButtonBorder
Field
FieldText
Highlight
HighlightText
Mark
MarkText
GrayText

Not only do they change across browsers, they change when toggling between dark and light mode as long as you have CSS in place to support them…

html {
  color-scheme: light dark;
}

You’ll see them change when modes change. And you don’t have to use them for what they were designed for, I suppose:

CodePen Embed Fallback

So those are the system colors, but you can see right in that Pen that I’ve also used a system font: system-ui. Same vibe! It’s purposely fluid. It’s not going to be the same typeface across browsers and operating systems. Jim also covered this a while back. We used to replicate the idea with a big long stack of named fonts, but now CSS helps with it (in supporting browsers).

There are a bunch of them specced:

serif
sans-serif
monospace
system-ui
cursive
fantasy
emoji
math
fangsong
ui-serif
ui-sans-serif
ui-monospace
ui-rounded

Support seems scattered. For example, I could set this:

p {
  font-family: ui-monospace, system-ui, fantasy;
}

On my Mac, in Safari, I’d get SF Mono (ui-monospace). But in Chrome, ui-monospace doesn’t work so it would fall back to SF Pro (system-ui). In Firefox neither ui-monospace or system-ui work and I’d get Papyrus (fantasy). So font stacks are still important. It’s just funny to think about because these new system font keywords are almost like font stacks in and of themselves.

So there are system colors and system fonts — doesn’t that beg the question of what other system things there are?

Well, there are named font weights — like how font-weight: bold; is the same as 700, and bolder is just a bit more bold than the parent. But that doesn’t feel like a system-level thing where the system would want to take hold of that and do different things. But hey, maybe.

There are also named font sizes, like font-size: xx-small;. I could see systems wanting to get their hands on those values and adjust them to sizes that make sense contextually, but in a quick glance (comparing Chrome and iOS Safari), they compute to the same sizes.

Those named font size values don’t travel, either. I can’t do margin: large;. Well, I can, but it doesn’t do anything. So no real universal system sizes.

What about system icons? We do kinda have those in the form of emoji! We use the emoji knowing that different systems will render it differently and are generally fine with that as we know it will look consistent with that user’s platform.

The “Blue Book” emoji (via Emojipedia)

We could sort of think of inputs as “system inputs.” We know different browsers and platforms render input controls in very different ways, and that is how the spec intends it. To each their own.

System *Things originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Debugging iOS Safari

Chris Coyier — Wed, 02 Jun 2021 21:15:28 +0000

How do I debug Safari on iOS?

These are my general steps, starting with not even using iOS Safari.

1. Is this just a small-screen problem?

Lemme just use the device mode in Chrome quick.

Note that this does a smidge more than just display your site in a smaller area: it sends the correct User Agent String and Client Hints for that device.

2. Does it seem actually specific to Safari? Lemme check Desktop Safari first since that’s just a few clicks away.

Now you’re actually using Safari, which is way closer to iOS Safari than desktop Chrome is.

3. Problem not showing here? Then the problem is actually unique to iOS Safari. Try emulation.

I happen to have a Mac, so I can have XCode installed and thus have an iOS simulator that is pretty easy to pop open. And if you can run the iOS simulator, that means you can run desktop Safari as well, and thus even have access to DevTools that can reach into the simulator.

4. I’ve seen real-device-only bugs. Sometimes you need a real device.

If you have a Mac, doing this is pretty similar to what we just did. You have to have the phone plugged in via USB (no wireless charging connection or whatever) and then you’ll see the device in that same Develop menu. Select the real device (which must have Safari open on some website) and you’ll get a DevTools instance of that website.

5. No Mac? Use an online emulator.

I have heard of people running over to Best Buy or an Apple Store to quick debug something on a display machine. But that’s — uhhhh — not super practical. You can use something like CrossBrowserTesting to do this right on the web.

They even jack Chrome DevTools in there somehow. I just did a little testing and I found the Chrome DevTools a little janky to use (a giant left panel renders, the click-to-select element feature didn’t work, and I kept losing WebSocket connection). But hey, it’s cool that it’s possible.

6. No Mac and still need to test on a real device?

I didn’t think this was really possible, but then I saw Inspect. (This is not an ad, I’m just shouting this out as a very cool tool.) With Inspect, I can plug in my real iOS device via USB and get a Chrome DevTools instance for it.

Remember to change this iOS Safari (Advanced) Setting to make it work with Inspect (and probably the “normal” Safari debugging described above).

I’m running Inspect on my Mac there. I guess the only real reason I would do that is to use Chrome DevTools instead of Safari DevTools (which, fair play, I might). And it looks like there will be more reasons soon enough. For example, it will bundle React, Vue, and Angular DevTools so you even have those for on-device testing, plus Wi-Fi testing, meaning you don’t have to plug in at all.

But I feel like the real clutch feature here is that it runs on Windows. So now there is a really clear answer for web developers on Windows who need to test on a real iOS device.

Debugging iOS Safari originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Is Vendor Prefixing Dead?

Rob O'Leary — Wed, 05 May 2021 14:18:28 +0000

Let‘s take a quick stroll down memory-lane to revisit how vendor prefixing CSS properties came to be. I hope I don’t trigger PTSD for anyone!

It‘s not clear who started prefixing, or when it began exactly. What is clear, is that by 2006, prefixed features were in Internet Explorer and Firefox. The raison d’être of prefixes was to specify browser-specific features. It was seen as a way to implement non-standard features and offer previews of new standard features.

By 2012, the W3C CSS Working Group was issuing guidance on the use of vendor prefixes:

In CSS we use vendor prefixes for properties, values, @-rules that are: – vendor specific extensions (per CSS 2.1), or – experimental implementations (per CSS Snapshot 2010) (e.g. in Working Drafts)

It became an industry norm. The number of prefixes grew, and with it, things grew confusing. It led to partial implementations of CSS features, introduced bugs, and ultimately created a fracture in the browser ecosystem, which disgruntled developers. Developers responded by making tools to automate the problem away.

Browser vendors slowly began to move away from prefixing, favoring feature flags inside the browser settings instead. It appeared that the problems created by vendor prefixes would fade away in time. The question is: has that time come yet?

I did some analysis on the caniuse dataset and Mozilla Developer Network Compat dataset to answer this question.

Adoption trends

You can see the trend of the implementation of prefixed features across the major browsers in the chart above. I have excluded Chrome for Android because of insufficient data.

From 2007 until 2011, there was a steady increase in the numbers of prefixed features in all browsers. Internet Explorer only saw an uptick in 2011. Then, in 2012, Mozilla began to remove prefixed features — such as -moz-border-radius* and -moz-box-shadow — from Firefox. Thereafter, they consistently removed prefixed properties once the standard version of that property was fully implemented.

In 2013, Mozilla started to make features available behind feature flags (pref flags). That same year, Chrome switched its rendering engine from WebKit to Blink (part of the Chromium project). This was a big turning point in removing some prefixed features.

It was only in April 2016 that WebKit announced that it would no longer release experimental features with prefixes:

Over time this strategy has turned out not to work so well. Many websites came to depend on prefixed properties. They often used every prefixed variant of a feature, which makes CSS less maintainable and JavaScript programs trickier to write. Sites frequently used just the prefixed version of a feature, which made it hard for browsers to drop support for the prefixed variant when adding support for the unprefixed, standard version. Ultimately, browsers felt pressured by compatibility concerns to implement each other’s prefixes.

Because Safari and iOS browsers have always used the WebKit rendering engine, a consistent reduction in the number of prefixes came later to these browsers.

Microsoft was never “gung ho” on prefixing and consistently had the fewest prefixed features. In 2019, Edge switched from its own rendering engine to Blink. In a funny twist, the change actually increased the number of prefixed properties in Edge!

Feature trends

The table below contrasts the prefixed features in 2013 (the zenith of prefixing) with 2021.

	2013	2021
Browsers	Chrome 31 Firefox 26 Internet Explorer 11 Safari 11 Safari iOS 7.0-7.1	Chrome 89 Edge 89 Firefox 88 Internet Explorer 11 Safari 14 Chrome Android 89 Safari iOS 14.0-14.5
Some prefixing required	`any-link` `dir()` `focus-visible` `is()` `:placeholder` `:placeholder-shown` `read-only` `:read-write` `:selection` `appearance` `background-clip: text` `background-image: crossfade()` `background-image: image-set()` `box-decoration-break` `box-sizing` `clip-path` `color-adjust` `element()` `font-feature-settings` `font-kerning` `font-smooth` `hyphens` `image-set` `line-clamp` `position: sticky` `tab-size` `text-align-last` `text-decoration styling` `text-emphasis styling` `text-size-adjust` `user-select: none` `writing-mode` CSS Animation CSS Canvas Drawings CSS Device Adaptation CSS Cursors: `grab` and `grabbing` CSS Cursors: `zoom-in` and `zoom-out` cursors CSS Exclusions Level 1 CSS Filter Effects CSS Flexible Box Layout Module CSS Grid Layout Level 1 CSS Logical Properties CSS Masks CSS Reflections CSS Regions CSS Scroll Snap CSS Scrollbar Styling CSS3 2D Transforms CSS3 3D Transforms CSS3 Multiple Column Layout CSS Text Fill & Stroking Intrinsic & Extrinsic Sizing Media Queries: Resolution Feature	`:placeholder-shown` `appearance` `backdrop-filter` `background-clip: text` `background-image: crossfade()` `background-image: image-set()` `box-decoration-break` `clip-path` (HTML) `color-adjust` `element()` `font-smooth` `hyphens` `image-set` `initial-letter` `line-clamp` `position: sticky` `text-decoration styling` `text-emphasis-styling` `text-orientation` `text-size-adjust` `user-select: none` `font-kerning` `tab-size` CSS Canvas Drawings CSS Device Adaptation CSS Exclusions Level 1 CSS Grid Layout Level 1 CSS Masks CSS Reflections CSS Regions CSS Scroll Snap CSS Scrollbar Styling CSS Text Fill & Stroking Intrinsic & Extrinsic Sizing Media Queries: Resolution Feature
Total features	53	35

It may be surprising to see the raw numbers. The number of features that require prefixing fell by ~33% between 2013 and 2021. That number sounds quite modest to me.

Of course, it could be misleading to focus just on numbers. The impact varies. It could be a family of properties that all require prefixing, such as animation; or it could be a feature that only has one property or value that requires a prefix, such as user-select: none. Let’s explore the actual features to understand the circumstances better, beginning by looking at what changed in that intervening period.

Twenty features were unprefixed (fully implemented across the major browsers) and three prefixed features were introduced (backdrop-filter, CSS text-orientation, and CSS initial-letter).

In my opinion, the most notable features that are unprefixed now, which were significant pain points are:

CSS Flexible Box Layout Module
CSS3 Box Sizing
CSS Animation
CSS3 2D Transforms
CSS3 3D Transforms
CSS Filter Effects

The other 14 features are less prominent:

:any-link
::placeholder
::selection
:focus-visible
:is()
:read-only
:read-write
font-feature-settings
text-align-last
writing-mode
CSS grab and grabbing cursors
CSS Logical Properties (will be used a lot more in the future, now that support is better)
CSS3 zoom-in and zoom-out cursors
CSS3 Multiple Column Layout

If you choose not to support Internet Explorer 11 in 2021, then an additional seven features no longer require prefixing. That reduces the number of features that require prefixing in 2021 to 28, which is a 46% reduction since 2013.

Prefixing in 2021

Let‘s look at the properties that require prefixing. It’s a motley group!

#	Name	Properties/Values	Description	Prefix required	Unprefixed support	Prefixed support	Improvement with prefixes
1	`appearance`	`appearance`	Defines how elements (particularly form controls) appear by default. Setting the value to `none` causes in the element’s default appearance being entirely redefined using other CSS properties.	Safari (`-webkit`) Opera (`-webkit`) Android Browser 2.1-4.4.4 (`-webkit`)	69.80%	97.03%	27.23%
2	`background-clip-text`	`background-clip: text`	Non-standard method of clipping a background image to the foreground text.	Chrome (`-webkit`) Edge (`-webkit`) Safari (`-webkit`) Opera (`-webkit`) Safari iOS (`-webkit`) Android Browser (`-webkit`) Chrome for Android (`-webkit`)	3.89%	96.65%	92.76%
3	`backdrop-filter`	`backdrop-filter`	Method of applying filter effects (like `blur`, `grayscale` or `hue`) to content or elements below the target element.	Safari (`-webkit`) Safari iOS (`-webkit`)	70.20%	88.20%	18.00%
4	`background-image: crossfade()`	`background-image: crossfade()`	Image function to create a “crossfade” between images. This allows one image to transition (fade) into another based on a percentage value.	Chrome (`-webkit`) Edge (`-webkit`) Opera (`-webkit`) Android Browser (`-webkit`) Chrome for Android (`-webkit`)	17.77%	92.62%	74.85%
5	`background-image: image-set()`	`background-image: image-set()`	Method of letting the browser pick the most appropriate CSS background image from a given set, primarily for high PPI screens.	Chrome (`-webkit`) Edge (`-webkit`) Opera (`-webkit`) Android Browser (`-webkit`) Opera Mobile (`-webkit`)	17.77%	92.48%	74.71%
6	`box-decoration-break`	`box-decoration-break`	Controls whether the box’s margins, borders, padding, and other decorations wrap the broken edges of the box fragments, when the box is split by a break, like a page, column, region, or line.	Chrome (`-webkit`) Edge (`-webkit`) Safari (`-webkit`) Opera (`-webkit`) Safari iOS (`-webkit`) Android BrowserOpera Mobile (`-webkit`)	6.39%	97.17%	90.78%
7	`clip-path`	`clip-path`	Method of defining the visible region of an HTML element using SVG or a shape definition.	Safari (`-webkit`)	72.00%	96.33%	24.33%
8	`color-adjust`	`color-adjust`	A non-standard CSS extension that can be used to force background colors and images to print.	Chrome (`-webkit-print-color-adjust`) Edge (`-webkit-print-color-adjust`) Safari (`-webkit-print-color-adjust`) Opera (`-webkit-print-color-adjust`) Android Mobile (`-webkit-print-color-adjust`)	3.69%	39.77%	36.08%
9	`element()`	`background: element()`	This function renders a live image generated from an arbitrary HTML element	Firefox (`-moz`)	0.00%	4.04%	4.04%
10	`font-kerning`	`font-kerning`	Controls the usage of the spacing between lettersstored in the font. Note that this only affects OpenType fonts with kerning information, it has no effect on other fonts.	Safari iOS (`-webkit`)	81.73%	96.03%	14.30%
11	`font-smooth`	`font-smooth`	Controls how anti-aliasing is applied when fonts are rendered. Though present in early 2002 drafts of the CSS3 Fonts specification, this property has since been removed and is currently not on the standard track.	Chrome (`-webkit-font-smoothing`) Edge (`-webkit-font-smoothing`) Firefox (`-moz-osx-font-smoothing`) Safari (`-webkit-font-smoothing`) Opera (`-webkit-font-smoothing`)	0.00%	39.64%	39.64%
12	`hyphens`	`hyphens`	Method of controlling when words at the end of lines should be hyphenated.	Internet Explorer 10+ (`-ms`) Safari (`-webkit`) Safari iOS (`-webkit`)	76.49%	96.51%	20.02%
13	`initial-letter`	`initial-letter`	Method of creating an enlarged cap, including a drop or raised cap, in a robust way.	Safari (`-webkit`) Safari iOS (`-webkit`)	0.00%	18.00%	18.00%
14	`line-clamp`	`line-clamp`	Contains text to a given amount of lines when used in combination with `display: -webkit-box`. Any text that overflows the space produces anellipsis when `text-overflow: ellipsis` is included.	Chrome (`-webkit`) Edge (`-webkit`) Firefox (`-webkit`) Safari (`-webkit`) Opera (`-webkit`) Safari iOS (`-webkit`) Android Browser (`-webkit`) Chrome for Android (`-webkit`) Firefox for Android (`-webkit`) Opera Mobile (`-webkit`)	0.19%	96.28%	96.09%
15	`position: sticky`	`position: sticky`	Keeps elements positioned as”fixed” or”relative” depending on how it appears in the viewport. As a result the element is “stuck” in place while scrolling.	Safari 7.1-12.1 (`-webkit`)	93.50%	95.36%	1.86%
16	`tab-size`	`tab-size`	Method of customizing the width of the `Tab` character. Only effective alongside `white-space: pre` or `white-space: pre-wrap`.	Firefox 4+ (`-moz`) Firefox for Android (`-moz`) Opera 11.5-12-1 (`-o`)	92.33%	97.38%	5.05%
17	`text-decoration styling`	`text-decoration` `text-decoration-*` properties.	Method of defining the type, style and color of lines in the `text-decoration` property. These can be defined as a shorthand (e.g. `text-decoration: line-through dashed blue`) or as single properties (e.g. `text-decoration-color: blue`).	Firefox 6-35 (`-moz`) Safari 7.1+ (`-webkit`) Safari for iOS 8+ (`-webkit`)	80.25%	94.86%	14.61%
18	`text-emphasis styling`	`text-emphasis` `text-emphasis-*` properties	Method of using small symbols next to each glyph to emphasize a run of text, commonly used in East Asian languages. The `text-emphasis` shorthand property, and its `text-emphasis-style` and `text-emphasis-color` constituent properties can be used to apply marks to the text. The `text-emphasis-position` property, which inherits separately, allows setting theposition ofemphasis marks with respect to the text.	Chrome 25+ (`-webkit`) Edge 79+ (`-webkit`) Opera 15+ (`-webkit`) Android Browser (`-webkit`) Chrome for Android (`-webkit`) Opera Mobile (`-webkit`)	21.96%	95.99%	74.03%
19	`text-orientation`	`text-orientation`	Specifies the orientation of text within a line. Current values only have an effect in vertical typographic modes (defined with the `writing-mode` property).	Safari (`-webkit`)	90.88%	94.84%	3.96%
20	`text-size-adjust`	`text-size-adjust`	Control if and how the text-inflating algorithm is applied to the textual content of the element it is applied to.	Edge 12-18 (`-ms`) Safari iOS (`-webkit`) Firefox for Android (`-moz`)	72.75%	87.48%	14.73%
21	`user-select: none`	`user-select`	Method of preventing text or element selection.	Internet Explorer 10-11 (`-ms`) Safari (`-webkit`) Safari iOS (`-webkit`) Android Browser 2.1-4.4.4 (`-webkit`)	74.81%	96.49%	21.68%
22	CSS Canvas Drawings	`background: -webkit-canvas(mycanvas)`	Method of using HTML5 Canvas as a background image. Not currently part of any specification.	Safari (`-webkit`)	0.00%	19.40%	19.40%
23	CSS Masks	`mask mask-*` properties	Method of displaying part of an element, using a selected image as a mask.	Chrome (`-webkit`) Edge (`-webkit`) Safari (`-webkit`) Safari iOSAndroid Browser (`-webkit`) Chrome for Android (`-webkit`) Opera Mobile (`-webkit`) Partial support in WebKit/Blink browsers refers to supporting the `mask-image` and `mask-box-image` properties, but lacking support for other parts of the spec.	4.18%	96.93%	92.75%
24	CSS Reflections	`-webkit-box-reflect`	Method of displaying a reflection of an element.	Chrome (`-webkit`) Edge (`-webkit`) Safari (`-webkit`) Opera (`-webkit`) Safari iOS (`-webkit`) Android Browser (`-webkit`) Chrome for Android (`-webkit`) Opera Mobile (`-webkit`)	0.00%	91.20%	91.20%
25	CSS Scrollbar Styling	`scrollbar-color` `scollbar-width`	Methods of styling scrollbar color and width.	Chrome (`-webkit`) Edge (`-webkit`) Safari (`-webkit`) Opera (`-webkit`) Safari iOS (`-webkit`) Android Browser (`-webkit`) Chrome for Android (`-webkit`)	4.28%	96.87%	92.59%
26	CSS Text Fill & Stroking	`text-stroke` `text-stroke-*` properties	Method of declaring the outline (stroke) width and color for text.	Chrome (`-webkit`) Edge (`-webkit`) Firefox (`-webkit`) Safari (`-webkit`) Opera (`-webkit`) Safari iOS (`-webkit`) Android Browser (`-webkit`) Chrome for Android (`-webkit`) Firefox for Android (`-webkit`) Opera Mobile (`-webkit`)	0.00%	96.65%	96.65%
27	Intrinsic & Extrinsi Sizing	`max-content` `min-content` `fit-content` `stretch` (formerly `fill`).	Allows for the height and width of an element to be specified in intrinsic values rather than fixed numeric values.	Chrome 22-45 (`-webkit`) Edge 3-65 (`-webkit`) Firefox (-moz-available) Opera 15-32 (`-webkit`) Safari 6.1-10-1 (`-webkit`) Safari iOS 7-13.7 (`-webkit`) Androind Browser 4.4-4.4.4 (`-webkit`)	91.99%	96.36%	4.37%
28	Media Queries: Resolution Feature	`@media (min-resolution: 300dpi)` { … }, `@media (max-resolution: 300dpi) { … }`	Allows a media query to be set based on the device pixels used per CSS unit. While the standard uses `min-resolution` and `max-resolution`, some browsers support the older non-standard `device-pixel-ratio` media query.	Chrome 4-28 (`-webkit`) Safari 4+ (`-webkit`) Opera 10-11.5 (`-webkit`) Safari iOS (`-webkit`) Android Browser (2.3-4.3) Opera Mobile 12 (`-webkit`) Firefox 3.5-15 (`min--moz-device-pixel-ratio`) Browsers that support `-webkit` support the non-standard `-webkit-min-device-pixel-ratio` and `webkit-min-device-pixel-ratio`.	80.40%	99.16%	18.76%

After putting this list together, my initial impression was that these aren’t things that I would bump into very often. Some properties have not been — and probably will not be — fully implemented. I’d say the element() function and CSS Canvas Drawings fall into that category. Safari recently dropped prefixing for position: sticky, so that will likely drop off the list very soon.

You can winnow the list down and steer away from certain situations if you want to. You can dismiss it and say it’s not important, so why bother? The reality is that the list is still long enough that manually managing prefixes in your code is not something you want to take on. A pertinent question to answer is: do you want to improve cross-browser support to a high level? If the answer is yes, then you should consider this as part of your development effort.

It is also important to remember that it is not just about these properties and current browsers. There are still people out there using older devices with older browsers, which do not support the unprefixed versions of some features. Take the animation property, for example. Chrome was the last browser to unprefix it in 2015. Yet, today, 1.3% of the users worldwide are still using a browser that does not support the unprefixed version.

I have bumped into a couple of situations recently that required prefixed properties. For example, I was making a reading progress bar for a blog and needed to use -webkit-appearance: none; and -moz-appearance: none; to reset the default styling for the progress element. It also needed sticky positioning, so I had to prefix position: sticky to support sticky positioning in Safari.

CodePen Embed Fallback

Another example? I wanted to use a PNG image as a mask image for a Christmas-themed design and found that -webkit-mask-image is the only property that works properly. Masking is generally a bit erratic because most browsers only partially support the spec.

CodePen Embed Fallback

Here’s yet another: Flavio Copes, in “How to apply padding to multiple lines in CSS,” wrote about how he wanted to have the same padding on each line of a multi-line heading. The solution was to use box-decoration-break: clone. Most browsers require the -webkit prefixed version of this property, so you need to use this.

CodePen Embed Fallback

Tools

Some of the tools that were created to solve issues with prefixing and browser support have fallen by the wayside. I would recommend checking first to see if a tool is up-to-date before using it.

Certainly, Autoprefixer (a PostCSS plugin) is maintained and it uses data straight from caniuse to stay current.

Emmet also has great prefixing capabilities. Specifically, it has a css.autoInsertVendorPrefixes preference to automatically insert prefixes for you. I haven’t verified if it is current or not, but it is worth considering as part of your development environment.

Since most code editors support Emmet, it makes editing prefixed properties a lot easier. Emmet has a CSS reflect value command that updates the value of all prefixed versions of the same property in a rule. You can read the Emmet docs for more info about the prefixing capabilities.

Conclusion

Vendor prefixing is not dead, unfortunately. We are still living with the legacy. At the same time, we can be grateful that prefixed features are on a steady decline. Some good work has been done by browser vendors to implement unprefixed features in lieu of prefixed features. This has removed the brunt of the burden from developers.

However, you may bump into scenarios that require prefixes still from time to time. And if you want to support as many browsers as possible, you should continue with an auto-prefixing strategy.

Is Vendor Prefixing Dead? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Eliminating five top compatibility pain points on the web

Chris Coyier — Fri, 23 Apr 2021 20:55:19 +0000

Robert Nyman and Philip Jägenstedt:

Google is working with other browser vendors and industry partners to fix the top five browser compatibility pain points for web developers. The areas of focus are CSS Flexbox, CSS Grid, position: sticky, aspect-ratio, and CSS transforms.

[…] The goal in 2021 is to eliminate browser compatibility problems in five key focus areas so developers can confidently build on them as reliable foundations.

I’d say slow clap, but I don’t want to sound sarcastic. Full on, regular clapping.

Ten, fifteen years ago, the job of a web designer and developer was heavily thinking about, planning for, and dealing with cross-browser compatibility. These days, it’s still a thing, but it’s not about dealing with bugs, quirks, and frustrating implementation differences like it was then. It’s more edge-case stuff with more obvious work-arounds. And when we’re thinking about the browser and device landscape, we’re doing it through the lens of meeting our users where they are and embracing that landscape. Doing our best, anyway.

If the powers that be can keep chipping away at compatibility problems, that further cements the web as the correct place to build.

I vote for some kind of proper stab at reliable viewport units in 2022, that somehow sensibly handle scrollbars and other browser chrome.

To Shared Link — Permalink on CSS-Tricks

Eliminating five top compatibility pain points on the web originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Improving Chromium’s browser compatibility in 2020

Chris Coyier — Tue, 07 Jul 2020 14:44:19 +0000

This is exactly what I love to hear from any browser vendor:

When it comes to browser compatibility, there are still too many missing features and edge-case bugs. But it doesn’t have to be this way. Things can and will get better, if browser vendors can understand what is causing the most pain, and take action to address the causes. In Chrome we’re doing our best to listen, and we’re doing our best to address what we’re hearing. We hope it helps, and we’re looking forward to a more compatible 2021.

I love the nod to that super clever div that looks different in every browser. This is a solid list from Stephen McGruer. My favorite:

Like Flexbox, CSS Grid is an important component of modern layout. Looking at the early survey results it seems like the story for CSS Grid support in Chromium is fairly good (we have our friends from Igalia to thank for that!). There is one clear exception – Chromium still doesn’t support subgrid.
Hopefully, it won’t be an exception for much longer. It’s still early days, but I’m excited to share that a team at Microsoft Edge are working on rearchitecting Chromium’s Grid support to use the new LayoutNG engine – and as part of this are intending to add subgrid support!

Not that anyone should relax, but I think right now is probably the best level of browser compatibility we’ve ever seen.

To Shared Link — Permalink on CSS-Tricks

Improving Chromium’s browser compatibility in 2020 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A Business Case for Dropping Internet Explorer

Ollie Williams — Mon, 28 Oct 2019 14:13:14 +0000

The distance between Internet Explorer (IE) 11 and every other major browser is an increasingly gaping chasm. Adding support for a technologically obsolete browser adds an inordinate amount of time and frustration to development. Testing becomes onerous. Bug-fixing looms large. Developers have wanted to abandon IE for years, but is it now financially prudent to do so?

First off, we’re talking about a dead browser

Development of IE came to an end in 2015. Microsoft Edge was released as its replacement, with Microsoft announcing that “the latest features and platform updates will only be available in Microsoft Edge”.

Edge was a massive improvement over IE in every respect. Even so, Edge was itself so far behind in implementing web standards that Microsoft recently revealed that they were rebuilding Edge from the ground up using the same technology that powers Google Chrome.

Yet here we are, discussing whether to support Edge’s obsolete ancient relative. Internet Explorer is so bad that a Principal Program Manager at the company published a piece entitled The perils of using Internet Explorer as your default browser on the official Microsoft blog. It’s a browser frozen in time; the web has moved on.

Publications have spelled the fall of IE since 2015.

Browsers are moving faster than ever before. Consider everything that has happened since 2015. CSS Grid. Custom properties. IE11 will never implement any new features. It’s a browser frozen in time; the web has moved on.

It blocks opportunities and encourages inefficiency

The landscape of browsers has also changed dramatically since Microsoft deprecated IE in 2015. Google developer advocate Sam Thorogood has compiled a list of all the features that are supported by every browser other than IE. Once the new Chromium version of Edge is released, this list will further increase. Taken together, it’s a gargantuan feature set, comprising new HTML elements, new CSS properties and new JavaScript features. Many modern JavaScript features can be made compatible with legacy browsers through the use of polyfills and transpilation. Any CSS feature added to the web over the last four years, however, will fail to work in IE altogether.

Let’s dig a little deeper into the features we have today and how they are affected by IE11. Perhaps most notable of all, after decades of hacking layouts on the web, we finally have CSS grid, which massively simplifies responsive layout. Together with CSS custom properties, object-fit, display: contents and intrinsic sizing, they’re all examples of useful CSS features that are likely to leave a website looking broken if they’re not supported. We’ve had some major additions to CSS over the last five years. It’s the cumulative weight of so many things that undermines IE as much as one killer feature.

While many additions to the web over the last five years have been related to layout and styling, we’ve also had huge steps forwards in functionality, such as Progressive Web Apps. Not every modern API is unusable for websites that need to stay backwards compatible. Most can be wrapped in an if statement.

if ('serviceWorker' in navigator) {
// do some stuff with a service worker
} else {
  // ???
}

You will, however, be delivering a very different experience to IE users. Increasingly, support for IE will limit the choice of tools that are available as library and frameworks utilize modern features.

Take this announcement from Evan You about the release of Vue 3, for example:

The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support.

The Vue 3 codebase makes use of proxies — a JavaScript feature that cannot be transpiled. MobX is another popular framework that also relies on proxies. Both projects will continue to maintain backwards-compatible versions, but they’ll lack the performance improvements and API niceties gained from dropping IE. Pika, a great new approach to package management, requires support for JavaScript modules, which are not supported in IE. Then there is shadow DOM — a standardized part of the modern web platform that is unlikely to degrade gracefully.

Supporting it takes tremendous effort

When assessing how much extra work is required to provide backwards compatibility for a deprecated browser like IE11, the long list of unimplemented features is only part of the problem. Browsers are incredibly complex pieces of software and, despite web standards, browsers are inconsistent. IE has long been the most bug-ridden browser that is most at odds with web standards. Flexbox (a technology that developers have been using since 2013), for example, is listed on caniuse.com as having partial support on IE due to the “large amount of bugs present.”

IE also offers by far the worst debugging experience — with only a primitive version of DevTools. This makes fixing bugs in IE undoubtedly the most frustrating part of being a developer, and it can be massively time-consuming — taking time away from organizations trying to ship features.

There’s a difference between support — making sure something is functional and looks good enough — versus optimization, where you aim to provide the best experience possible. This does, however, create a potentially confusing grey area. There could be differences of opinion on what constitutes good enough for IE. This comment about IE9 from Dave Rupert is still relevant:

The line for what is considered “broken” is fuzzy. How visually broken does it have to be in order to be functionally broken? I look for cheap fixes, but this is compounded by the fact the offshore QA team doesn’t abide in that nuance, a defect is a defect, which gets logged and assigned to my inbox and pollutes the backlog…Whether it’s polyfills, rogue if-statements, phantom styles, or QA kickbacks; there are costs and technical debt associated with rendering this site on an ever-dwindling sliver of browsers.

If you’re going to take the approach of supporting IE functionally, even if it’s not to the nth degree, still confines you to polyfill, transpile, prefix and test on top of everything else.

It’s already been abandoned by many top websites

Popular websites to officially drop support for IE include Youtube, GitHub, Meetup, Slack, Zendesk, Trello, Atlassian, Discord, Spotify, Behance, Wix, Huddle, WhatsApp, Google Earth and Yahoo. Even some of Microsoft’s own product’s, like Teams, have severely reduced support for IE.

Twitter displays a banner informing IE users that they will not receive the best experience and redirects users to a much older version of the Twitter website. When we think of disruptive companies that are pushing the best in web design, Monzo, Apple Music and Stripe break horribly in IE, while foregoing a warning banner.

Stripe offers no support or warning.

Why the new Chromium-powered Edge browser matters

IE usage has been on a slower downward trend following an initial dramatic fall. There’s one primary reason the browser continues to hang on: ancient business applications that don’t work in anything else. Plenty of large companies still use applications that rely on APIs that were never standardized and are now obsolete. Thankfully, the new Edge looks set to solve this issue. In a recent post, the Microsoft Edge Team explained how these companies will finally be able to abandon IE:

The team designed Internet Explorer mode with a goal of 100% compatibility with sites that work today in IE11. Internet Explorer mode appears visually like it’s just a part of the next Microsoft Edge…By leveraging the Enterprise mode site list, IT professionals can enable users of the next Microsoft Edge to simply navigate to IE11-dependent sites and they will just work.

.@MicrosoftEdge: one browser for all web experiences. IE mode will allow you to view and access legacy sites directly in the same window. #MSBuild https://t.co/NXcDjDB5B4 pic.twitter.com/x7BtCtASNs

— Microsoft Edge Dev (@MSEdgeDev) May 6, 2019

After using the beta version for several months, I can say it’s a genuinely great browser. Dare I say, better than Google Chrome? Microsoft are already pushing it hard. Edge is the default browser for Windows 10. Hundreds of millions of devices still run earlier versions of the operating system, on which Edge has not been available. The new Chromium-powered version will bring support to both Windows 7 and 8. For users stuck on old devices with old operating systems, there is no excuse for using IE anymore. Windows 7, still one of the world’s most popular operating systems, is itself due for end-of-life in January 2020, which should also help drive adoption of Edge when individuals and businesses upgrade to Windows 10.

In other words, it’s the perfect time to drop support.

Performance costs

All current browsers support ECMAScript 2015 (the latest version of JavaScript) — and have done so for quite some time. Transpiling JavaScript down to an older (and slower) version is still common across the industry, but at this point in time is needed only for Internet Explorer. This process, allowing developers to write modern syntax that still works in IE negatively impacts performance. Philip Walton, an engineer at Google, had this to say on the subject:

Larger files take longer to download, but they also take longer to parse and evaluate. When comparing the two versions from my site, the parse/eval times were also consistently about twice as long for the legacy version. […] The cost of shipping lots of unneeded JavaScript to low-end mobile browsers can be significant! We (on the Chrome team) have seen numerous occurrences of polyfill bloat adding seconds to the total startup time of websites on low-end mobile devices.

It’s possible to take a differential serving approach to get around this issue, but it does add a small amount of complexity to build tooling. I’m not sure it’s worth bothering when looking at the entire picture of what it already takes to support IE.

Yet another example: IE requires a massive amount of polyfills if you’re going to utilize modern APIs. This normally involves sending additional, unnecessary code to other browsers in the process. An alternative approach, polyfill.io, costs an additional, blocking HTTP request — even for modern browsers that have no need for polyfills. Both of these approaches are bad for performance.

As for CSS, modern features like CSS grid decrease the need for bulky frameworks like Bootstrap. That’s lots of extra bites we’re unable to shave off if we have to support IE. Other modern CSS properties can replace what’s traditionally done with JavaScript in a way that’s less fragile and more performant. It would be a boon for both performance and cost to take advantage of them.

Let’s talk money

One (overly simplistic) calculation would be to compare the cost of developer time spent on fixing IE bugs and the amount lost productivity working around IE issues versus the revenue from IE users. Unless you’re a large company generating significant revenue from IE, it’s an easy decision. For big corporations, the stakes are much higher. Websites at the scale of Amazon, for example, may generate tens of millions of dollars from IE users, even if they represent less than 1% of total traffic.

I’d argue that any site at such scale would benefit more by dropping support, thanks to reducing load times and bounce rates which are both even more important to revenue. For large companies, the question isn’t whether it’s worth spending a bit of extra development time to assure backwards compatibility. The question is whether you risk degrading the experience for the vast majority of users by compromising performance and opportunities offered by modern features. By providing no incentive for developers to care about new browser features, they’re being held back from innovating and building the best product they can.

It’s a massively valuable asset to have developers who are so curious and inquisitive that they explore and keep up with new technology. By supporting IE, you’re effectively disengaging developers from what’s new. It’s dispiriting to attempt to keep up with what’s new only to learn about features we can’t use. But this isn’t about putting developer experience before user experience. When you improve developer experience, developers are enabled to increase their productivity and ship features — features that users want.

Web development is hard

It was reported earlier this year that the car rental company Hertz was suing Accenture for tens of millions of dollars. Accenture is a Fortune Global 500 company worth billions of dollars. Yet Hertz alleged that, despite an eye-watering price tag, they “never delivered a functional site or mobile app.”

According to The Register:

Among the most mind-boggling allegations in Hertz’s filed complaint is that Accenture didn’t incorporate a responsive design… Despite having missed the deadline by five months, with no completed elements and weighed down by buggy code, Accenture told Hertz it would cost an additional $10m – on top of the $32m it had already been paid – to finish the project.

The Accenture/Hertz affair is an example of stunning ineptitude but it was also a glaring reminder of the fact that web development is hard. Yet, most companies are failing to take advantage of things that make it easier. Microsoft, Google, Mozilla and Apple are investing massive amounts of money into developing new browser features for a reason. Improvements and innovations that have come to browsers in recent years have expanded what is possible to deliver on the web platform while making developers’ lives easier.

Move fast and ship things

The development industry loves terms — like agile and disruptive — that imply light-footed innovation. Yet rather than focusing on shipping features and creating a great experience for the vast bulk of users, we’re catering to a single outdated legacy browser. All the companies I’ve worked for have constantly talked about technical debt. The weight of legacy code is accurately perceived as something that slows down developers. By failing to take advantage of what modern browsers have to offer, the code we write today is legacy code the moment it is written. By writing for the modern web, you don’t only increase productivity today but also create code that’s easier to maintain in the future. From a long-term perspective, it’s the right decision.

Recruitment and retainment

Developer happiness won’t be viewed as important to the bottom line by some business stakeholders. However, recruiting good engineers is notoriously difficult. Average tenure is low compared to other industries. Nothing can harm developer morale more than a day of IE debugging. In a survey of 76,118 developers conducted by Mozilla “Having to support specific browsers (e.g. IE11)” was ranked as the most frustrating thing in web development. “Avoiding or removing a feature that doesn’t work across browsers” came third while testing across different browsers reached fourth place. By minimising these frustrations, deciding to end support for IE can help with engineer recruitment and retainment.

IE users can still access your website

We live in a multi-device world. Some users will be lucky enough to have a computer provided by their employer, a personal laptop and a tablet. Smartphones are ubiquitous. If an IE user runs into problems using your site, they can complete the transaction on another device. Or they could open a different browser, as Microsoft Edge comes preinstalled on Windows 10.

The reality of cross-browser testing

If you have a thorough and rigorous cross-browser testing process that always gets followed, congratulations! This is rare in my experience. Plenty of companies only test in Chrome. By making cross-browser testing less onerous, it can be made more likely that developers and stakeholders will actually do it. Eliminating all bugs in browsers that are popular is far more worthwhile monetarily than catering to IE.

When do you plan to drop IE support?

Inevitably, your own analytics will be the determining factor in whether dropping IE support is sensible for you. Browser usage varies massively around the world — from almost 10% in South Korea to well below one percent in many parts of the world. Even if you deem today as being too soon for your particular site, be sure to reassess your analytics after the new Microsoft Edge lands.

A Business Case for Dropping Internet Explorer originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Caniuse and MDN compatibility data collaboration

Chris Coyier — Tue, 10 Sep 2019 19:51:54 +0000

Second only to “silly GIFs,” I’d guess screenshots of caniuse are the most common slide graphic at web conferences. It’s become the ultimate source for looking at web compatibility data in the hearts and minds of web developers.

Can I use CSS filter in Firefox? Yes. Can I use the filter() function? No.

But of course, MDN has incredible web platform documentation that also includes compatibility data. So it’s nice to see them collaborate. And not just theoretically — it’s already happening.

Florian Scholz and Alexis Deveria:

Before we began our collaboration, the caniuse website only displayed results for features available in the caniuse database. Now all search results can include support tables for MDN compat data. This includes data types already found on caniuse, specifically the HTML, CSS, JavaScript, Web API, SVG & and HTTP categories. By adding MDN data, the caniuse support table count expands from roughly 500 to 10,500 tables! Developers’ caniuse queries on what’s supported where will now have significantly more results.

Massive upgrade, already live on the site. I absolutely love real collaboration like this when it actually happens. I remember back in 2012 when WebPlatform.org launched and every single major web company gave lip service that they were going to contribute and consolidate their documentation there. Sounded too good to be true. Launched before that work actually happened. Died unglamorously a few years later.

The caniuse database, I believe, is basically this 2MB JSON file on GitHub. We use that right here on CSS-Tricks. We pull it in and use the data in it to display our support tables, crediting caniuse while we do it.

Here’s backdrop-filter:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome	Firefox	IE	Edge	Safari
76	103	No	17	9*

Mobile / Tablet

Android Chrome	Android Firefox	Android	iOS Safari
108	107	108	9.0-9.2*

It doesn’t sound like the MDN data is going to make its way into that JSON, so I guess my big hope is that that dataset continues to be updated, or that if it is someday replaced, it is in a place that is similarly easy to access.

I totally get why they are just combining the data sources out of the gate, as MDN digs into individual features in a way that caniuse typically doesn’t. For example, the individual values for justify-content are super complicated!

I imagine that kind of detail might require a deeper architectural change that wasn’t right for a Version 1 integration.

To Shared Link — Permalink on CSS-Tricks

Caniuse and MDN compatibility data collaboration originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A Conspiracy to Kill IE6

Robin Rendle — Mon, 06 May 2019 14:22:50 +0000

Chris Zacharias published a few notes about why the team at YouTube added a banner that asked users to switch from IE6 to a more modern browser back in 2009:

The bittersweet consequence of YouTube’s incredible growth is that so many stories will be lost underneath all of the layers of new paint. This is why I wanted to tell the story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.

I do not recall the exact triggering event that led to our web development team laying out plans to kill IE6 over lunch in the YouTube cafeteria. Perhaps it was the time I pushed out a CSS stylesheet that included an attribute selector on a semi-supported HTML element. Any reasonable web developer would expect this to be ignored by browsers not up to the task. This was not the case with older flavors of IE. Under very specific conditions, an attribute selector on an unsupported HTML element in IE would create an internal recursion that would at best, cause the browser to crash and at worst, trigger a blue screen of death.

There are a lot of interesting things to consider here. IE6 was notoriously difficult for developers to work with and would cause teams to spend a great deal of time fixing game-breaking bugs for what often represented a mere slither of their overall site traffic. However, it’s important to note that as soon as you make a call like this, where do you stop? It suddenly becomes easier to make a Chrome-only website, to ignore basic accessibility principles, to ignore semantic markup, and to make a website optimized for yourself. That leads us to more sticky topics, such as browser diversity and proprietary resources that seem at odds with an open, inclusive web.

I’m reminded here of Jeremy Keith’s book, Resilient Web Design, where he writes:

If a website is built using progressive enhancement then it’s okay if a particular feature isn’t supported or fails to load: Ajax, geolocation, whatever. As long as the core functionality is still available, web designers don’t need to bend over backwards trying to crowbar support for newer features into older browsers.

And Jeremy quotes Mat Marquis, who happened to work on the responsive redesign of The Boston Globe, where he argued that:

Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.

Maybe there’s a middle ground here; maybe there’s not. But I find Mat and Jeremy’s approach to be more inspiring and kinder to the overall health of the web.

To Shared Link — Permalink on CSS-Tricks

A Conspiracy to Kill IE6 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Edge Goes Chromium: What Does it Mean for Front-End Developers?

Ollie Williams — Thu, 11 Apr 2019 14:32:05 +0000

In December 2018, Microsoft announced that Edge would adopt Chromium, the open source project that powers Google Chrome. Many within the industry reacted with sadness at the loss of browser diversity. Personally, I was jubilant. An official release date has yet to be announced, but it will be at some point this year. With its release, a whole host of HTML, JavaScript and CSS features will have achieved full cross-browser support.

The preview build is now available for Windows, and coming soon for Mac.

📣 Calling all web devs and tinkerers! 📣

The first preview builds of the next version of #MicrosoftEdge are ready for you – try it out now! https://t.co/I531hfmD3G pic.twitter.com/Tvh6OGGouO

— Microsoft Edge Dev (@MSEdgeDev) April 8, 2019

Not so long ago, I penned an article titled “The Long Slow Death of Internet Explorer.” Some of us are lucky enough have abandoned that browser already. But it wasn’t the only thing holding us back. Internet Explorer was the browser we all hated and Edge was meant to be its much-improved replacement. Unfortunately, Edge itself was quite the laggard. EdgeHTML is a fork of Trident, the engine that powered Internet Explorer. Microsoft significantly under-invested in Edge. The apple didn’t fall far from the tree. Edge’s User Voice website was a nice idea, allowing developers to vote for which features they wanted to be implemented. Unfortunately, as Dave Rupert put it, voting on the site was “like throwing coins in a wishing well.” The most requested features were left unimplemented for years.

There are a lot of features that pre-Chromium Edge doesn’t currently support but are available in other modern browsers and, once they’ve made the switch, we’ll be able to use them. Many of them can’t be polyfilled or worked around, so this release is a big deal.

Features we can look forward to using

So just what are those features, exactly? Let’s outline them right here and start to get excited about all the new things we’ll be able to do.

Custom Elements and Shadow DOM

Together, custom elements and shadow DOM allow developers to define custom, reusable and encapsulated components. A lot of people were asking for this one. People have been voting for its implementation since 2014, and we’re finally getting it.

HTML details and summary elements

The

and

elements are part of HTML5 and have been supported since 2011 in Chrome. Used together, the elements generate a simple widget to show and hide content. While it is trivial to implement something similar using JavaScript, the

and

elements work even when JavaScript is disabled or has failed to load.

See the Pen
details/summary by CSS GRID (@cssgrid)
on CodePen.

Javascript Font Loading API

This one means a lot to some people. All modern browsers now support the CSS font-display property. However, you still might want to load your fonts with JavaScript. Font-loading monomaniac Zach Leatherman has an explainer of why you might want to load fonts with JavaScript even though we now have broad support for font-display. Ditching polyfills for this API is important because this JavaScript is, according to Zach:

[…] usually inlined in the critical path. The time spent parsing and executing polyfill JavaScript is essentially wasted on browsers that support the native CSS Font Loading API.”

In an article from 2018, Zach lamented:

[…] browser-provided CSS Font Loading API has pretty broad support and has been around for a long time but is confoundedly still missing from all available versions of Microsoft Edge.”

No longer!

JavaScript flat and flatMap

Most easily explained with a code snippet, flat() is useful when you have an array nested inside another array.

const things = ['thing1', 'thing2', ['thing3', ['thing4']]]
const flattenedThings = things.flat(2); // Returns ['thing1', 'thing2', 'thing3', 'thing4']

As its name suggests, flatMap() is equivalent to using both the map() method and flat().

These methods are also supported in Node 11. 🎉

JavaScript TextEncoder and TextDecoder

TextEncoder and TextDecoder are part of the encoding spec. They look to be useful when working with streams.

JavaScript Object rest and object spread

These are just like rest and spread properties for arrays.

const obj1 = {
  a: 100,
  b: 2000
}

const obj2 = {
  c: 11000,
  d: 220
}

const combinedObj = {...obj1, ...obj2} 
// {a: 100, b: 2000, c: 11000, d: 220}

JavaScript modules: dynamic import

Using a function-like syntax, dynamic imports allow you to lazy-load ES modules when a user needs them.

button.addEventListener("click", function() {
  import("./myModule.js").then(module => module.default());
});

CSS background-blend-mode property

background-blend-mode brings Photoshop style image manipulation to the web.

CSS prefers-reduced-motion media query

I can’t help feeling that not making people feel sick should be the default of a website, particularly as not all users will be aware that this setting exists. As animation on the web becomes more common, it’s important to recognize that animation can cause causes dizziness, nausea and headaches for some users.

CSS caret-color property

Admittedly a rather trivial feature, and one that could have safely and easily been used as progressive enhancement. It lets you style the blinking cursor in text input fields.

8-digit hex color notation

It’s nice to have consistency in a codebase. This includes sticking to either
the RGB, hexadecimal or HSL color format. If your preferred format is hex, then you had a problem because it required a switch to rgba() any time you needed to define transparency. Hex can now include an alpha (transparency) value. For example, #ffffff80 is equivalent to rgba(255, 255, 255, .5). Arguably, it’s not the most intuitive color format and has no actual benefit over rgba().

Intrinsic sizing

I’ve not seen as much hype or excitement for intrinsic sizing as some other new CSS features, but it’s the one I’m personally hankering for the most. Intrinsic sizing determines sizes based on the content of an element and introduces three new keywords into CSS: min-content, max-content and fit-content(). These keywords can be used most places that you would usually use a length, like height, width, min-width, max-width, min-height, max-height, grid-template-rows, grid-template-columns, and flex-basis.

CSS text-orientation property

Used in conjunction with the writing-mode property, text-orientation, specifies the orientation of text, as you might expect.

See the Pen
text-orientation: upright by CSS GRID (@cssgrid)
on CodePen.

CSS :placeholder-shown pseudo-element

placeholder-shown was even available in Internet Explorer, yet somehow never made it into Edge… until now. UX research shows that placeholder text should generally be avoided. However, if you are using placeholder text, this is a handy way to apply styles conditionally based on whether the user has entered any text into the input.

CSS place-content property

place-content is shorthand for setting both the align-content and justify-content.

See the Pen
place-content by CSS GRID (@cssgrid)
on CodePen.

CSS will-change property

The will-change property can be used as a performance optimization, informing the browser ahead of time that an element will change. Pre-Chromium Edge was actually good at handling animations performantly without the need for this property, but it will now have full cross-browser support.

CSS all property

button { background: none; border: none; color: inherit; font: inherit; outline: none; padding: 0; }

Sadly, though, the revert keyword still hasn’t been implemented anywhere other than Safari, which somewhat limits the mileage we can get out of the all property.

CSS Shapes and Clip Path

Traditionally, the web has been rectangle-centric. It has a box model, after all. While we no longer need floats for layout, we can use them creatively for wrapping text around images and shapes with the shape-outside property. This can be combined with the clip-path property, which brings the ability to display an image inside a shape.

Clippy is an online clip-path editor

CSS :focus-within pseudo-class

If you want to apply special styles to an entire form when any one of its inputs are in focus, then :focus-within is the selector for you.

CSS contents keyword

This is pretty much essential if you’re working with CSS grid. This had been marked as “not planned” by Edge, despite 3,920 votes from developers.

For both flexbox and grid, only direct children become flex items or grid items, respectively. Anything that is nested deeper cannot be placed using flex or grid-positioning. In the words of the spec, when display: contents is applied to a parent element, “the element must be treated as if it had been replaced in the element tree by its contents,” allowing them to be laid out with a grid or with flexbox. Chris goes into a more thorough explanation that’s worth checking out.

There are, unfortunately, still some bugs with other browser implementations that affect accessibility.

The future holds so much more promise

We’ve only looked at features that will be supported by all modern browsers when Edge makes the move to Chromium. That said, the death of legacy Edge also makes a lot of other features feel a lot closer. Edge was the only browser dragging its feet on the Web Animation API and that showed no interest in any part of the Houdini specs, for example.

Credit: https://ishoudinireadyyet.com

The impact on browser testing

Testing in BrowserStack (left) and various browser apps on my iPhone (right)

Of course, the other huge plus for web developers is less testing. A lot of neglected Edge during cross-browser testing, so Edge users were more likely to have a broken experience. This was the main reason Microsoft decided to switch to Chromium. If your site is bug-free in one Chromium browser, then it’s probably fine in all of them. In the words of the Edge team, Chromium will provide “better web compatibility for our customers and less-fragmentation of the web for all web developers.” The large variety of devices and browsers makes browser testing one of the least enjoyable tasks that we’re responsible for as front-end developers. Edge will now be available for macOS users which is great for the many of us who work on a Mac. A subscription to BrowserStack will now be slightly less necessary.

Do we lose anything?

To my knowledge, the only feature that was supported everywhere except Chrome is SVG color fonts, which will no longer work in the Edge browser. Other color font formats (COLR, SBIX, CBDT/CBLC) will continue to work though.

Uh, @GoogleChrome Are you planning to support #OpenTypeSVG soon? Supported in Safari (12+), Firefox (26+) even EdgeHTML (38+) Photoshop, Illustrator – but not Chrome
/cc @colorfontswtf pic.twitter.com/tgwJ3AqHm2

— Chris Lilley (@svgeesus) February 15, 2019

What about other browsers?

Admittedly, Edge wasn’t the last subpar browser. All the features in this article are unsupported in Internet Explorer, and always will be. If you have users in Africa or India, you’ll need to support Opera Mini. If you have users in China, then UC browser will be important to test against. If you don’t have these regional considerations, there’s never been a better time to ditch support for Internet Explorer and embrace the features the modern web has to offer. Plenty of PC users have stuck with Internet Explorer purely out of habit. Hopefully, a revamped Edge will be enough to tempt them away. An official Microsoft blog entry titled “The perils of using Internet Explorer as your default browser” concluded that, “Internet Explorer is a compatibility solution…developers by and large just aren’t testing for Internet Explorer these days.” For its remaining users, the majority of the web must look increasingly broken. It’s time to let it die.

Is Google a megalomaniac?

Life is about to get easier for web developers, yet the response to the Microsoft’s announcement was far from positive. Mozilla, for one, had a stridently pessimistic response, which accused Microsoft of “officially giving up on an independent shared platform for the internet.” The statement described Google as having “almost complete control of the infrastructure of our online lives” and a “monopolistic hold on unique assets.” It concluded that “ceding control of fundamental online infrastructure to a single company is terrible.”

Many have harked back to the days of IE6, the last time a browser achieved such an overwhelming market share. Internet Explorer, having won the browser war, gave in to total stagnation. Chrome, by contrast, ceaselessly pushes new features. Google participates actively with the web standards bodies the W3C and the WHATWG. Arguably though, it has an oversized influence in these bodies and the power to dictate the future shape of the web. Google Developer Relations does have a tendency to hype features that have shipped only in Chrome.

From competition to collaboration

Rather than being the new IE, Edge can help innovate the web forward. While it fell behind in many areas, it did lead the way for CSS grid, CSS exclusions, CSS regions and the new HTML imports spec. In a radical departure from historical behavior, Microsoft have become one of the world’s largest supporters of open source projects. That means all major browsers are now open source. Microsoft have stated that they intend to become a significant contributor to Chromium — in fact, they’ve already racked up over 300 merges. This will help Edge users, but will also benefit users of Chrome, Opera, Brave, and other Chromium-based browsers.

Edge Goes Chromium: What Does it Mean for Front-End Developers? originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

A historical look at lowercase defaultstatus

Chris Coyier — Mon, 01 Apr 2019 14:19:30 +0000

Browsers, thank heavens, take backward compatibility seriously.

Ancient websites generally work just fine on modern browsers. There is a way higher chance that a website is broken because of problems with hosting, missing or altered assets, or server changes than there is with changes in how browsers deal with HTML, CSS, JavaScript, another other native web technologies.

In recent memory, #SmooshGate was all about a new JavaScript feature that conflicted with a once-popular JavaScript library. Short story, JavaScript has a proposal for Array.prototype.flatten, but in a twist of fate, it would have broken MooTools Elements.prototype.flatten if it shipped, so it had to be re-named for the health of the web.

That was the web dealing with a third-party, but sometimes the web has to deal with itself. Old APIs and names-of-things that need to continue to work even though they may feel like they are old and irrelevant. That work is, surprise surprise, done by caring humans.

Mike Taylor is one such human! The post I’m linking to here is just one example of this kind of bizarre history that needs to be tended to.

If Chrome were to remove defaultstatus the code using it as intended wouldn’t break—a new global would be set, but that’s not a huge deal. I guess the big risk is breaking UA sniffing and ended up in an unanticipated code-path, or worse, opting users into some kind of “your undetected browser isn’t supported, download Netscape 2” scenario.

If you’re into this kind of long term web API maintenance stuff, that’s the whole vibe of Mike’s blog, and something tells me it will stick around for a hot while.

To Shared Link — Permalink on CSS-Tricks

A historical look at lowercase defaultstatus originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.