Chris Hannah

Safari


Vinegar - A Safari Extension To Fix YouTube Videos

You may have heard about Vinegar, since it’s been doing the rounds recently. However, if you haven’t, It’s essentially a Safari extension that makes YouTube videos look better, and act like standard HTML videos. Which means they use Safari’s native video player, which means that you have slightly more control over the video, but at the same time you do lose some functionality that YouTube has in their player.

As you can see, the video player still lets you change the video quality, use subtitles, stream to an AirPlay device, etc. So the basic functionality is there. And it makes Picture-in-Picture a lot easier to access, as the YouTube player requires three clicks, and the native player has a button in the top-left corner.

And as much as I would say that YouTube looks better with the native player, and that it’s easier to use, there are still downsides. For example, autoplay doesn’t work, you can’t access the YouTube Miniplayer, you can’t toggle Theatre Mode, and you can’t pause/play the video using the space bar.

The downsides will have different levels of importance to different people, and I’m personally a bit in the middle. I’m definitely keeping it installed, and going to be using it by default, but there are certainly ways it can be improved.

What I can say, is that it’s definitely worth it’s £1.79 price. Which seems to be an opinion shared by others, as it’s currently sitting in second place in the Utilities category of the Mac App Store in the UK.

Some More Thoughts on the State of Safari

I wrote a tweet a few hours ago, explaining what I think Apple should do with Safari:

With the amount of tampering that Apple have done with the new Safari design in the betas, I think it would be wise for the whole redesign to be postponed for a later point release.
That way they can spend more time getting feedback instead of rushing small tweaks.

Tweet

However, since Twitter isn’t exactly the best place for anything except quick opinions and hot takes, I thought I’d go into a bit more detail here on my blog.


My thinking is that because the changes to Safari on all platforms have received such widespread criticism (with varying degrees) and that Apple has been constantly tweaking (mildly) Safari during the beta process, then it should be clear that it is not going to be widely appreciated when released to the public.

Sure, enthusiasts will always care that bit more than the average user, but the complaints that I have and that I have seen, aren’t about insignificant details, but about the fundamental usability. And you’d expect with the number of users that will eventually be using the next version of iPadOS, and iOS, and macOS, then that has the potential to cause a lot of negativity and frustration simply because Apple wanted to redesign the built-in browser.

I’m somewhat of the opinion that Apple should take a tad more risk in their designs and try some new things now and then. But then again, making the built-in web browser less usable for potentially hundreds of millions of users isn’t a good move. No matter how much “courage” you have.

I think it’s only fair to include here that at the start of the beta, I was open to a new Safari design. I think the tab groups are a good idea, the tab bar looked a bit fresher on iPadOS and macOS, and the address bar was moved to the bottom of the screen on the iPhone, making it easier to reach.

But as I used it more on all platforms, I started to spot the weaknesses. The (initial) tab design on macOS and iPadOS didn’t work well with more than 5/6 tabs (although this has been slightly improved), the address bar on the iPhone regularly got in the way of content, and there’s been the apparent massacre of buttons within Safari on all platforms. In the latest round of betas, a few buttons have returned, but overall I believe that this version of Safari is not fit for purpose.

So in my opinion, I believe the wisest thing for Apple to do would be to either revert the major design changes or at least have it as an opt-in setting for people to choose. That way, they can receive more constructive feedback, spend some real time rethinking the design, and delivering a better version of Safari in a point release.

My ideal solution would be for Safari to keep some of the new features, like the tab groups, Quick Notes, the tab overview, and possibly even the new address bar on macOS. But the new floating address bar in iOS, the tab bar in iPadOS and macOS, and the sparseness of buttons should be at most an alternative and not the default option for all users.

I’m not saying that Safari should never be changed, but it shouldn’t be changed for the sake of it. This design has been proved to already be a bad move, and I don’t believe that mailing small tweaks here and there are going to fix the major flaws.

How to Add Support for Safari’s New Customisable Tab Bar in Your Website

In the new (beta) versions of iOS, iPadOS, and macOS, a redesigned version of Safari includes a new combined address bar and tab bar. Which although, isn’t winning over everyone, it allows for a slight bit of customisation. Your website can provide a colour that will act as a background/tint colour for the new tab bar.

This colour is defined in the theme-color meta tag, and the media attribute can be used to provide different colours for Light and Dark appearances.

Here is an example of what I currently have set up for this website to provide the pink accent colour that’s used for links as the theme colour:

<meta name="theme-color" 
      content="rgb(233, 0, 94)" 
      media="(prefers-color-scheme: light)">
<meta name="theme-color" 
      content="rgb(255, 0, 103)" 
      media="(prefers-color-scheme: dark)">

And here is what it looks like:

I’m not totally in favour of the new Safari design myself, but I’m definitely a fan of added customisation.

You can read more about the other changes in the Safari 15 release notes.

Preventing Tracking Prevention Tracking

John Wilander, writing at the WebKit blog:

Any kind of tracking prevention or content blocking that treats web content differently based on its origin or URL risks being abused itself for tracking purposes if the set of origins or URLs provide some uniqueness to the browser and webpages can detect the differing treatment.

To combat this, tracking prevention features must make it hard or impossible to detect which web content and website data is treated as capable of tracking. We have devised three ITP enhancements that not only fight detection of differing treatment but also improve tracking prevention in general.

You would have thought that simply preventing tracking would stop trackers. Well it turns out that if websites can see if you are using prevention tools, then you can still be singled out. John lists a few ways in which enhancements are being made to Intelligent Tracking Prevention in WebKit to combat this.

Finally Favicons in Safari

A lot of people would like Safari to show favicons in the tab bar, just like Chrome does. And it’s been the subject on various blog posts, and podcasts. But it was a post by John Gruber, that got Timing developer Daniel Alm interested.

He then went on and made an app called Faviconographer, that doesn’t exactly add that feature to Safari, but instead analyses Safari and the current tabs, and overlays the relevant favicon where it should be.

It’s not perfect, but it does make Safari much better. I just can’t believe it’s still not an official feature.

You can download Faviconographer, and also read more about how it works, the current limitations, and also some other information on the app on the Faviconographer website.