Tag: Safari

WebKit Features in Safari 16.0

Whew boy, Safari 16 is officially out in the wild and it packs in a bunch of features, some new and exciting (Subgrid! Container Queries! Font Palettes!) and others we’ve been waiting on for better cross-browser support (Motion Path! Overscroll Behavior! AVIF!). I imagine Jen Simmons typing cheerfully writing out all of the new goodies in the roundup announcement.

A list of new WebKit features.
Source: WebKit.org

Just gonna drop in the new CSS features from the release notes:

  • Added size queries support for Container Queries. Chrome started supporting it in Version 105, so all we need is Firefox to join the party to get The Big Three™ covered.
  • Added support for Container Query Units. These units go hand-in-hand with Container Queries. Once again, we need Firefox.
  • Added support for Subgrid. Now it’s Safari and Firefox with support coverage. The good news is that Chrome is currently developing it as well.
  • Added support for animatable Grids. Very cool! Chrome has always had some implementation of this and Firefox started supporting it back in 2019.
  • Added support for Offset Path. This is also known as Motion Path, and we’ve had broad browser support since 2020. It’s nice to see Safari on board.
  • Added support for Overscroll Behavior. Now we can modify “scroll chaining” and overflow affordances with the overscroll-behavior property.
  • Added support for text-align-last. Now we’re all set with cross-browser support for this property!
  • Added support for the resolution media query. All set here as well!

There are quite a few nice updates to Safari’s developer tools, too. We’ve got a Flexbox inspector, a Timelines tab (with an experimental screenshots timeline), and Container Queries info, to name a few. There’s a full 32-minute video that walks through everything, too.

I thought Safari 15 was a pretty killer release, but 16 is pretty epic in comparison. I know there’s a “Safari is the new Internet Explorer” vibe in some circles, but I’m happy to see big jumps like this and appreciate all the forward momentum. Go Safari Team!

To Shared LinkPermalink on CSS-Tricks

WebKit Features in Safari 16.0 originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.


, , ,

Low framerate in Safari on M1 Mac

John James Jacoby:

I recently noticed that animations in Safari were stuttering pretty badly on my M1 powered 2020 MacBook Air, and dove in to figure out why.

The why:

This wasn’t a bug. This was a feature.

By default, macOS Monterey enables “Low power mode” on Battery power and disables it when using a Power Adapter. Safari, it seems, is programmed to interpret this setting to mean that it should reduce the number of times it paints to the screen to prolong battery life.

On my MacBook Air, that means from 60fps to 30fps.

To Shared LinkPermalink on CSS-Tricks



Safari 15 Opinions

It was interesting that when Safari 15 was dropping at this last WWDC, in my circles at least, I mostly heard enthusiasm. Like the colors-in-the-browser-controls stuff was a neat trick and fun to play with. And there were other more serious features, like iCloud Private Relay, which were near-universally applauded for the security innovation.

But the UX changes in Safari 15 are much more controversial in wider and more generally Apple-related circles.

Michael Tsai has a big roundup of opinions, including many serious criticisms. Like Steven Shen showing off how hard the tabs are to use on iPadOS and Saagar Jha pointing out that it’s hard to tell the difference between private browsing and not.

But I’d say most of the criticism is leveled at the browser controls themselves, regardless of the color trickery. Nick Herr went as far as calling it Chickenshit Minimalism:

Condensing the address bar into each tab is also irksome. It is a clever idea, but it means that everything moves around because tabs move. They scroll left to right; they change size as you open and close other tabs.

The small size of a browser tab also means that many controls are hidden by default, including the reload and share buttons. They are all buried into one of those vague “⋯” controls that Apple is obsessed with these days. If you share web links a lot, there is not even a way to add the button back to the toolbar in a more permanent state. This, I think, continues a worrying pattern of bad UI habits.

In other words, chucking useful buttons under a random kebab menu isn’t something that people who used those buttons are going to be fond of. There’s “Hiding buttons from popular built-in apps is a bad idea.” by Federico Viticci, which goes into similar changes in iOS Safari. Gruber also:

I think the new Safari interface is a noble experiment — intriguing ideas that were worth trying out. But I don’t know anyone who thinks, in practice, that they’re not a huge regression in usability. I’d love it if Apple just went back to the previous Safari interface for tabs and browser chrome. It’s crazy to me that even the Share button is now an extra click or tap away. If Apple ships this design for the Mac it’s going to push a lot of current Safari users to Chrome or other Chromium-based browsers.

Not popular changes. I wonder if people would really jump-ship just for this? My hunch is that Safari users are either Safari users because that’s just what ships on their Mac and they don’t care to think about it much, or are Safari users very much on purpose because of the Apple-ness of it and these changes wouldn’t be enough to force them away.

Others applaud the effort. Jason Snell calls it a self-inflicted wound, but sees the good:

Apple has tried to minimize Safari’s interface as much as possible. Its designers have looked at every single interface element, from the tabs to the URL bar to every single toolbar item, and pondered if they could afford to hide, remove, or minimize those elements to give more space on the screen for the web page itself.

I think that Apple should be applauded for making the effort, not only because the vast majority of its customers are using screens that are at most 13 inches measured diagonally, but because Apple should always be striving to find better ways of doing things. I don’t believe there’s any class of app—from web browsers to email clients to text editors—that’s a solved problem.

Jeff Kirvin thinks it’s just misunderstood:

What I see in Safari 15 is the first steps into a new design language for iOS, one prioritizing adaptive, contextual interfaces. Ever since the move to the new “all screen” iPhone X design, content has been king on iOS, and Apple has been removing more and more user chrome. This is the next step on that journey.

While I’m at the Safari 15 thing here…

The post Safari 15 Opinions appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.



Working around the viewport-based fluid typography bug in Safari

Sara digs into a bug I happened to have mentioned back in 2012 where fluid type didn’t resize when the browser window resized. Back then, it affected Chrome 20 and Safari 6, but the bug still persists today in Safari when a calc() involves viewport units.

Sara credits Martin Auswöger for a super weird and clever trick using -webkit-marquee-increment: 0vw; (here’s the documentation) to force Safari into the correct behavior. I’ll make a screencast just to document it:

I randomly happened to have Safari Technology Preview open, which at the moment is Safari 15, and I see the bug is fixed. So I wouldn’t rush out the door to implement this.

Direct Link to ArticlePermalink

The post Working around the viewport-based fluid typography bug in Safari appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Safari 15: New UI, Theme Colors, and… a CSS-Tricks Cameo!

There’s a 33-minute video (and resources) over on apple.com covering the upcoming Safari changes we saw in the WWDC keynote this year in much more detail. Look who’s got a little cameo in there:

Perhaps the most noticeable thing there in Safari 15 on iOS is URL bar at the bottom! Dave was speculating in our little Discord watch party that this probably fixes the weird issues with 100vh stuff on iOS. But I really just don’t know, we’ll have to see when it comes out and we can play with it. I’d guess the expectation is that, in order for us to do our own fixed-bottom-UI stuff, we’d be doing:

.bottom-nav {    position: fixed; /* maybe sticky is better if part of overall page layout? */   bottom: 100vh; /* fallback? */   bottom: calc(100vh - env(safe-area-inset-bottom)); /* new thing */ }

On desktop, the most noticeable visual feature is probably the theme-color meta tags.

This isn’t even a brand new Apple-only thing. This is the same <meta> tag that Chrome’s Android app has used since 2014, so you might already be sporting it on your own site. The addition is that it supports media queries.

<meta name="theme-color"        content="#ecd96f"        media="(prefers-color-scheme: light)"> <meta name="theme-color"        content="#0b3e05"        media="(prefers-color-scheme: dark)">

It’s great to see Safari get aspect-ratio and the new fancy color systems like lab() and lch() as well. Top-level await in JavaScript is great as it makes patterns like conditional imports easier.

I don’t think all this would satisfy Alex. We didn’t exactly get alternative browser engines on iOS or significant PWA enhancements (both of which would be really great to see). But I applaud it all—it’s good stuff. While I do think Google generally takes privacy more seriously than what general internet chatter would have to believe, it’s notable to compare each company’s newly-released features. If you’ll forgive a bit of cherry-picking, Google is working on FLoC, a technology very specifically designed to help targeted advertising. Apple is working on Private Relay, a technology very specifically to making web browsing untrackable.

The post Safari 15: New UI, Theme Colors, and… a CSS-Tricks Cameo! appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Debugging iOS Safari

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.

The post Debugging iOS Safari appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.



Safari 14.1 Adds Support for Flexbox Gaps

Yay, it’s here! Safari 14.1 reportedly adds support for the gap property in flexbox layouts. We’ve had grid-gap support for some time, but true to its name, it’s limited to grid layouts. Now we can use gap in either type of layout:

.container {   display: flex;   flex-flow: row wrap;   gap: 1.5rem; }

Apple’s been rather quiet about the update. I didn’t even hear about it until Eric Meyer brought it up in an email, and he only heard about it when Jen Simmons tweeted it out.

I checked the WebKit CSS Feature Status and, sure enough, it’s supported. It just wasn’t called out in the release notes. Nothing is posted to Safari’s release notes archive just yet, so maybe we’ll hear about it officially there at some point. For now, it seems that Maximiliano Firtman‘s overview of iOS 14.5 is the deepest look at what’s new.

And how timely is it that Eric recently covered how to use the gap property, not only in grid and flexbox layouts, but multi-column as well.

The post Safari 14.1 Adds Support for Flexbox Gaps appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

CSS Individual Transform Properties in Safari Technology Preview

The WebKit blog details how to use individual CSS Transform properties in the latest version of Safari Technology Preview. This brings the browser in line with the CSS Transforms Module Level 2 spec, which breaks out the translate(), rotate() and scale() functions from the transform property into their own individual properties: translate, scale, and rotate.

So, instead of chaining those three functions on the transform property:

.some-element {   transform: translate(50px 50px) rotate(15deg) scale(1.2); }

…we can write those out individually as their own properties:

.some-element {   translate(50px 50px);   rotate(15deg);   scale(1.2); }

If you’re like me, your mind immediately jumps to “why the heck would we want to write MORE lines of code?” I mean, we’re used to seeing individual properties become sub-properties of a shorthand, not the other way around, like we’ve seen with background, border, font, margin, padding, place-items, and so on.

But the WebKit team outlines some solid reasons why we’d want to do this:

  • It’s simpler to write a single property when only one function is needed, like scale: 2; instead of transform: scale(2);.
  • There’s a lot less worry about accidentally overriding other transform properties when they’re chained together.
  • It’s a heckuva lot simpler to change a keyframe animation on an individual property rather than having to “pre-compute” and “recompute” intermediate values when chaining them with transform.
  • We get more refined control over the timing and keyframes of individual properties.

The post points out some helpful tips as well. Like, the new individual transform properties are applied first — translate, rotate, and scale, in that order — before the functions in the transform property.

Oh, and we can’t overlook browser support! It’s extremely limited at the time of writing… basically to just Safari Technology Preview 117 and Firefox 72 and above for a whopping 3.9% global support:

The post suggests using @supports if you want to start using the properties:

@supports (translate: 0) {   /* Individual transform properties are supported */   div {     translate: 100px 100px;   } }  @supports not (translate: 0) {   /* Individual transform properties are NOT supported */   div {     transform: translate(100px, 100px);   } }

That’s the code example pulled straight from the post. Modifying this can help us avoid using the not operator. I’m not sure that’s an improvement to the code or not, but it feels more like progressive enhancement to do something like this:

div {   transform: translate(100px, 100px); }  @supports (translate: 0) {   /* Individual transform properties are supported */   div {     transform: none;     translate: 100px 100px;   } }

That way, we clear the shorthand functions and make way for the individual properties, but only if they’re supported.

The post CSS Individual Transform Properties in Safari Technology Preview appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , ,

Apple declined to implement 16 Web APIs in Safari due to privacy concerns

Why? Fingerprinting. Rather than these APIs being used for what they are meant for, they end up being used for gross ad tech. As in, “hey, we don’t know exactly who you are, but wait, through a script we can tell your phone stopped being idle from 8:00 am to 8:13 am and were near the Bluetooth device JBL BATHROOM, so it’s probably dad taking his morning poop! Let’s show him some ads for nicer speakers and flannel shirts ASAP.”

I’ll pull the complete list here from Catalin Cimpanu’s article:

  • Web Bluetooth – Allows websites to connect to nearby Bluetooth LE devices.
  • Web MIDI API – Allows websites to enumerate, manipulate and access MIDI devices.
  • Magnetometer API – Allows websites to access data about the local magnetic field around a user, as detected by the device’s primary magnetometer sensor.
  • Web NFC API – Allows websites to communicate with NFC tags through a device’s NFC reader.
  • Device Memory API – Allows websites to receive the approximate amount of device memory in gigabytes.
  • Network Information API – Provides information about the connection a device is using to communicate with the network and provides a means for scripts to be notified if the connection type changes
  • Battery Status API – Allows websites to receive information about the battery status of the hosting device.
  • Web Bluetooth Scanning – Allows websites to scan for nearby Bluetooth LE devices.
  • Ambient Light Sensor – Lets websites get the current light level or illuminance of the ambient light around the hosting device via the device’s native sensors.
  • HDCP Policy Check extension for EME – Allows websites to check for HDCP policies, used in media streaming/playback.
  • Proximity Sensor – Allows websites to retrieve data about the distance between a device and an object, as measured by a proximity sensor.
  • WebHID – Allows websites to retrieve information about locally connected Human Interface Device (HID) devices.
  • Serial API – Allows websites to write and read data from serial interfaces, used by devices such as microcontrollers, 3D printers, and othes.
  • Web USB – Lets websites communicate with devices via USB (Universal Serial Bus).
  • Geolocation Sensor (background geolocation) – A more modern version of the older Geolocation API that lets websites access geolocation data.
  • User Idle Detection – Lets website know when a user is idle.

I’m of mixing feelings. I do like the idea of the web being a competitive platform for building any sort of app and sometimes fancy APIs like this open those doors.

Not to mention that some of these APIs are designed to do responsible things, like knowing connections speeds through the Network Information API and sending less data if you can, and the same for the Battery Status API.

This is all a similar situation to :visited in CSS. Have you ever noticed how there are some CSS declarations you can’t use on visited links? JavaScript APIs will even literally lie about the current styling of visited links to make links always appear unvisited. Because fingerprinting.

Direct Link to ArticlePermalink

The post Apple declined to implement 16 Web APIs in Safari due to privacy concerns appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , , , ,