Posts tagged with "WebKit"

“Introducing Adaptive Dark Mode”→

As part of the 27.3 betas released yesterday, Apple also introduced a new Safari feature:

We’re excited to announce Adaptive Dark Mode in Safari 27.3 beta. When enabled by a user, Safari adapts light websites and presents them as dark.

In the spring of 2019, Safari 12.1 became the first browser to support dark mode on the web. A lot of people love using dark mode, but not every website has a dark version. Almost 40% of web page loads are from users in dark mode, and yet only 10% of page loads support it. If you love dark mode, you’ve probably hit a site that felt particularly bright. Adaptive Dark Mode is designed to close that gap, providing a consistent dark experience across the web.

If this sounds familiar, it’s because so many third-party Safari extensions for this very task already exist, including the very popular (and a MacStories favorite) Noir. The difference, of course, is that Adaptive Dark Mode is built deep into the WebKit engine itself now, ships for free in Safari, and offers greater speed and performance since it’s not limited by an extension. It sounds like Apple thought of a lot of details here:

At the core of Adaptive Dark Mode is the transformation of color. Sometimes colors are simply decorative, while other times they have semantic meaning. Adaptive Dark Mode determines when to invert colors so elements remain visible or when to leave colors unchanged.

While creating Adaptive Dark Mode, we developed a color matrix to invert the luminosity of colors while preserving hue. It’s used to make light backgrounds dark, and dark text light. When transforming text color, Adaptive Dark Mode aims for sufficient contrast as defined by the WCAG 4.5:1 contrast ratio. Light CSS gradients are also transformed to dark.

And:

It takes the same care with images. Most are left unchanged, preserving their integrity. But many icons and logos can lose contrast when the background color behind them is inverted. So Adaptive Dark Mode inspects SVG images and transforms colors when needed. For bitmap images, it analyzes the pixel histograms and inverts simple black-and-white logos.

Noir and similar extensions had a great run. Between this, the MCP server added earlier this year, and vertical tabs in 27.3, it’s time for me to go back to Safari everywhere.

Permalink

Apple Investigating Options for Extending Web Content Under iPhone Duo’s Safari Controls→

Jen Simmons, writing at the official WebKit blog:

Safari 27.1 does bring one change to users. Now, when someone holds iPhone Duo partially folded like a book while looking at a PDF on the web, Safari 27.1 automatically shows PDFs as two pages side by side. When they open the screen flat or close it fully, Safari switches back to one page.

I didn’t know about that, likely because I prefer saving and reading PDFs offline. The most interesting tidbit from this otherwise (very) technical blog post, however, is the fact that Apple is actively looking into ways to let web developers extend their websites’ content underneath the Safari controls shown on the right side of the iPhone Duo’s screen:

You might have noticed the outer display of iPhone Duo is wider and shorter than other iPhone displays. To give content more vertical space, iOS moves controls to the side.

In Safari 27.1, web content does not currently extend to fill the space behind these controls. Just like on other platforms, Safari looks at the web page and extends its background color to fill the space.

We would like to give web designers and developers the ability to design and use that space in more creative ways. Perhaps you want to extend your header background across the full width of the display, for example. It might seem like there’s just one obvious way to make this possible, but really there are many possibilities.

Since getting my iPhone Duo review unit yesterday, this is what has annoyed me the most. I dislike how all kinds of websites are simply cut off on the right side of Safari on the outer display. You can see this in action on MacStories itself: while we have fully updated our website to take advantage of the iPhone Duo’s new viewport sizes, there’s nothing we can do to extend the toolbar and other elements under Safari’s controls on the right side of the display. The result looks like a poor implementation on our end, but it isn’t.

MacStories on the iPhone Duo's outer display.

MacStories on the iPhone Duo’s outer display.

I hope Apple’s Safari and WebKit teams can figure this out; once they do, we’ll update MacStories for the iPhone Duo again.

Permalink

Safari’s New MCP Server Is Great for Agents→

Saron Yitbarek, writing on the WebKit blog:

In Safari Technology Preview 247, we’re introducing the Safari MCP server — a Model Context Protocol server for web developers that makes your web development and debugging workflow faster and more powerful. We know agents are increasingly integral to the coding process and the Safari MCP server gives your agent the ability to know how your code actually renders in the browser by connecting it to a Safari browser window.

Any MCP-compatible client can connect to the Safari MCP server. By connecting your agent to a Safari browser window, your agent can emulate what your users experience, giving it the information it needs to debug more autonomously, like access to the DOM, network requests, screenshots, and console output.

Importantly:

The Safari MCP server runs entirely on your local machine and makes no network calls of its own. It also does not have access to your personal information in Safari (e.g. AutoFill or other browser activity). When it captures page content, screenshots, or console logs, that data goes directly to the agent you’re running — not to Apple. What happens to that data from there depends on the agent and model you’re using. As with any agent you give access to your browser, only use ones you trust.

For the past few months, I’ve been using Google Chrome on my MacBook Pro and Mac Studio not because I like the browser (in fact, I really dislike Chrome’s text rendering and UI), but simply because it was the best option for agents. In Codex specifically, between Playwright, Chrome Dev Tools, and OpenAI’s own Chrome extension, I could kick off research tasks (such as vacation planning and booking a hotel) that involved a browser directly from my iPhone, letting Codex drive the research on my remote Mac.

Safari in Codex.

Safari in Codex.

Now, thanks to Safari’s new MCP server, I no longer have to use Chrome on desktop and can return to a unified browser setup across all my devices. Even better: it actually looks like Apple shipped the most ergonomic browser MCP for agents to date. The MCP server has dedicated tools for page extraction (including getting webpages as Markdown, based on WebKit’s own conversion pipeline), evaluating JavaScript, DOM interactions (clicking, scrolling, resizing the viewport for mobile screens, etc.), taking screenshots, and more. I set this up immediately in Codex, and I also asked Codex about comparing Safari’s MCP to its own Chrome extension and the older Playwright. The verdict: although Chrome has a richer API with Chrome Dev Tools when it comes to network requests, Codex actually preferred Apple’s leaner, more direct approach for letting an agent drive and debug a browser.

I’m really happy to see folks at Apple embrace agentic tools: between the new MCP capabilities of Xcode and now this, it looks like Apple’s software (on the Mac, of course) is becoming more and more approachable by people who are working in new ways thanks to agents. Whether you’re a web developer or tinkerer, I highly recommend checking out what Apple has released in Safari Technology Preview. More of this, please.

Permalink

Web Advocates Challenge Apple’s EU Browser Policies→

The EU’s Digital Markets Act requires Apple to allow third parties to offer web browsers with their own browser engines. However, more than a year later, there are no browsers built with Chromium, Gecko, or any other engine in the EU.

At a recent EU workshop on Apple’s compliance with the DMA’s browser requirements, Apple representatives were asked some pointed questions by Open Web Advocacy (OWA), and others about its browser engine policies. OWA, a non-profit that advocates for the open web, raised multiple issues with Apple’s approach to browser engines in the EU that they believe are holding back third-party engines.

One issue is that versions of the same browser with different engines can’t be part of the same app bundle. According to OWA, that effectively means vendors like Google and Mozilla would need to release a new EU-only version of their browsers, starting the process of acquiring users from scratch, which I can’t imagine any browser company would sign up to do voluntarily.

Another issue OWA raised is that there is currently no way for web developers outside the EU who are not associated with the browser makers to obtain browsers with competing engines for testing purposes. That’s a problem that’s been solved with other apps by allowing test versions to be distributed outside the EU. However, as things stand today, OWA says that web developers couldn’t use EU-only browsers for testing even if there were any available.

Other issues were raised, too, but these two strike me as practical impediments to third-party browser engines that can and should be resolved. Apple’s responses to OWA’s challenges focused on privacy and security, which are legitimate factors to consider, but it’s disappointing that more than a year after the DMA took effect, the practical problems raised by OWA and others still haven’t been solved.

Permalink