Browsers - Safari and WebKit

Apple's subtle anti-competitive practices and the web

Apple has a history of stunting the web’s progress on its platforms. On iOS, Apple doesn’t allow fully independent third-party browsers, requiring all apps to leverage its Safari browser when rendering web-based content. While browsers like Chrome and Opera are available in the App Store, they must use Apple’s Safari browser behind the scenes to render web pages, rather than their own. That means Apple has a monopoly on how iPhone and iPad users access the web. To push developers toward building native apps on iOS rather than using web technologies, Apple ignores popular parts of the open web specification that other browsers implement, to its own benefit.

A technology called WebRTC, for example, allows video calling in a web browser without additional software. It powers tools like Google Meet. But Apple was incredibly slow to implement the specification, leaving out key pieces of functionality, and the technology didn’t work when embedded inside apps.

Apple also handicapped an emerging standard called Progressive Web Apps (PWAs) — which, like Electron, allows developers to build native-like apps for both desktop and mobile — by partially implementing it in a way that makes it too inconsistent to rely on. PWA doesn’t have the same problem if users open apps in Chrome or Firefox, but iPhone and iPad users can’t install third-party browsers, which makes PWA-based technology a non-starter.

[…]

Apple’s subtle, anti-competitive practices don’t look terrible in isolation, but together they form a clear strategy: Make it so painful to build with web-based technology on Apple platforms that developers won’t bother. Now that the App Store is not accepting apps built using Electron, developers will likely find creative ways to work around it, but Apple is setting up for a continual cat-and-mouse game as it plans to exert more control over which apps can run on the platform in the future.

Mike Taylor - A case for browser-engine diversity... - View Source 2019

Given the recent demise of Presto and EdgeHTML rendering engines, and dominant market share growth for Chrome (and its Chromium engine), can we make a case for browser engine diversity in a decreasingly diverse browser engine world? In this talk, we’ll talk about web compatibility, interoperability, the web standards process, and hopefully conclude that we should care about these things in 2019.

Cutting the mustard with only CSS

JavaScript can be pretty brittle, so having a way to exclude browsers that don’t cut the mustard via CSS can be really useful, especially if you don’t want to serve them large amounts of CSS that they won’t properly understand. Since we can’t prevent loading a stylesheet via feature queries, the media attribute on a <link> element seems the next best thing. Andy Kirk has come up with a few combinations:

Code language: HTML

<!--
  Print (Edge doesn't apply to print otherwise)
  IE 10, 11
  Edge
  Chrome 29+, Opera 16+, Safari 6.1+, iOS 7+, Android ~4.4+
  FF 29+
-->
<link rel="stylesheet" href="your-stylesheet.css" media="
  only print,
  only all and (-ms-high-contrast: none), only all and (-ms-high-contrast: active),
  only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none),
  only all and (-webkit-min-device-pixel-ratio:0) and (min-color-index:0),
  only all and (min--moz-device-pixel-ratio:0) and (min-resolution: 3e1dpcm)
">
 
<!--
  Print (Edge doesn't apply to print otherwise)
  Edge, Chrome 39+, Opera 26+, Safari 9+, iOS 9+, Android ~5+, Android UCBrowser ~11.8+
  FF 47+
-->
<link rel="stylesheet" href="your-stylesheet.css" media="
  only print,
  only all and (pointer: fine), only all and (pointer: coarse), only all and (pointer: none),
  only all and (min--moz-device-pixel-ratio:0) and (display-mode:browser), (min--moz-device-pixel-ratio:0) and (display-mode:fullscreen)
">

Safari bug with gradients that fade to "transparent"

Say you have a gradient in CSS that goes from red to transparent. Easy, right? Like this:

Code language: CSS

.element {
  background: linear-gradient(
    to bottom,
    red, 
    transparent
  );
}

There is a pretty big gotcha here, though.

In Chrome (also Android), Firefox, and Edge, you’d be all good.

But in Safari (also iOS), you’d not be good.

The same test page as before, viewed in both the iOS simulator version of Safari, and the macOS version of Safari. The two rectangles, each with a gradient background colour are different this time. The red in the rectangle on the left fades from red to black, as it fades to transparent, which appears to be a bug. The rectangle on the right fades to transparent while still maintaining the red colour, as expected.
The element on the left in each browser demonstrates the problem.

The problem, the best I understand it, is that transparent is being interpreted (and interpolated) as “transparent black”.

To fix it, you have to set the color as a fully transparent version of that exact color. Like:

Code language: CSS

.element {
  background: linear-gradient(
    to bottom,
    red,
    rgba(255, 0, 0, 0)
  )
}

[…]

Sass can help out, if you are using that:

Code language: Sass

.element {
  background: linear-gradient(
    to bottom,
    #eb8fa9,
    rgba(#eb8fa9, 0);
  )
}