One of the unpublicized nuggets in macOS 10.13.4 is this little doozy in the release notes:
Enables sorting Safari bookmarks by name or URL by right-clicking and choosing ‘Sort By…’
This has been a feature request for nearly as long as Safari has existed—Safari was released in January 2003, and I found this MacRumors forum thread from April 2003 asking how to sort bookmarks. So this feature was nearly 15 years in the making!
Sure enough, right click on an entry in your Bookmarks list, and you can sort by name or URL:
I have a junk drawer in Safari where I bookmark stuff that I might someday want. Like a real junk drawer, it gets filled pretty quickly, and sorting the entries is a great way to trim the out of date entries. But when I tried to sort my junk drawer…
…there was no such option available. Stumped for a moment, it struck me that there may be a limit on the number of entries, as that was the only difference between this folder and others. I removed half the entries, leaving 546, but still, no Sort entry in the contextual menu.
After a bunch of back-and-forth moving (which takes some time, when you move hundreds of bookmarks around), I found the limit: 450 entries.
So if you have a large folder of bookmarks in Safari that you need to sort, you’ll have to split it into multiple folders, none of which can have more than 450 entries. Weird but true.
Browsers cache data whenever you load a page. In general, this is a good thing—you’ll save data transfer (very important on mobile), and increase speed on any connection if the browser can use data that it’s already cached.
But there’s one place I hate browser cache: When creating or editing web pages. I’ll edit a file, save the changes, upload the new file, load the page…and nothing. So I edit again, repeat, still nothing. Only then do I remember the cache. Argh!
Thankfully, there are ways around (most) cache issues. I do most of my web development in Chrome and Safari; here are the simple tips I use to manage cache in those browsers when developing.
Enable the Developer menu (Prefs > Advanced > Show Develop menu in menu bar).
Once enabled, use the Developer menu to easily empty the cache via the Empty Caches menu item, which is bound to the keyboard via ⌘⌥E.
Also in the Developer menu, you can completely disable the cache with the Disable Caches menu item. This is what I do when developing—just remember to enable them again when you’re done, or you’ll find browsing quite slow.
To force a single page to completely reload, hold down the Option key and click on the reload icon in the URL bar.
Between Many Tricks and this blog, I spend a lot of time in browsers. Most of the time, I use Safari, but I do occasionally work in Chrome and Firefox, too—most often to check how a page looks or functions.
I keep my “permanent” bookmarks in Safari, and don’t presently use any sort of cross-browser sync. (I used to use one, but had a lot of trouble with duplicates, so I stopped.)
I wanted a way to open a limited number of URLs in either Safari (if that’s what I was in, or if I wasn’t in a browser), or in the frontmost browser, if that browser were frontmost. I could just create the subset as bookmarks in each browser, but if I wanted to add or remove a page from the list, I’d have to do so multiple times.
In the end, I came up with a set of Keyboard Maestro macros that do exactly what I want. I access my short list of multi-browser URLs via Keyboard Maestro’s pop-up palette, as seen at right.
This appears when I press ⌃1; after that, a single digit opens the desired URL. But how does it know whether to open the URL in Safari or one of the other browsers? It takes one helper macro, then one macro for each URL that I want to open in this manner.
This is another oldie but goodie from Mac OS X Hints, explaining how to enable the Debug menu in Safari. To do that, quit Safari, open Terminal, paste the following line, and press Return:
defaults write com.apple.Safari IncludeInternalDebugMenu 1
When you relaunch Safari, you’ll have a (really long) Debug menu on the far right of Safari’s menus. And just why might you want a Debug menu in Safari? Kirk McElhearn offers up one good reason:
Auto-play videos suck. They use bandwidth, and their annoying sounds get in the way when you’re listening to music and open a web page. …
But you can stop auto-play videos from playing on a Mac. If you use Chrome or Firefox, it’s pretty simple, and the plugins below work both on macOS and Windows; if you use Safari, it’s a bit more complex, but it’s not that hard.
In Safari, they key is the Debug menu, as Kirk points out. Go to Media Flags and select (activate) Disallow Inline Video, and that should be the end of auto-playing video. See Kirk’s blog post for ways to do the same in Firefox and Chrome.
Beyond auto-play video, though, there’s lots to geek out about in the Debug menu…
When I posted my 787 takeoffs and landings video, I ran into a weird problem: When embedded here, the video would play in Safari at 4K (2160p), but when viewed on YouTube, the max resolution available was 1440p. After failing with web searches, I asked Twitter about it…
…but didn’t hear anything back. I pretty much gave up on the issue until today, when I stumbled across this article, which describes the exact problem I’m having. The summary of the article describes both the problem and the apparent cause:
What appears to be Google’s shift to the VP9 codec for delivering 4K video on the YouTube homepage is preventing Safari users from watching videos uploaded to the service since early December in full 4K resolution, but not from viewing webpage-embedded videos in the same resolution.
Bingo! Google seems to now be using the open and royalty-free VP9 codec for 4K videos viewed on its YouTube site, but reverts to the H264 codec when those same videos are embedded on other sites.
Note that this issue only affects videos uploaded after December 6, 2016:
Videos uploaded to the service prior to Dec. 6 in 4K resolution can still play back in full 4K resolution on Safari from the YouTube homepage.
I was curious about which macOS browsers this issue affects, so I thought I’d do a little experiment…
Yesterday I ranted on Twitter about CNN’s redesign:
This led to an exchange with a CNN staffer, and a couple people saying “me too!” But it felt it a bit unfair to criticize without specific data. So this morning, I gathered the data, and can now quantify my distaste for the new design.
I compared the current CNN homepage to the latest available on the Internet Archive, calculating how the space was used for each version of the site. The results were eye opening in many ways.
The new CNN design displays half as many clickable stories in the same space, with an image that takes 20% of the available screen, and sucks down over 20% of my CPU just to display its home page. Read on for the gory details.
Note: This follow-up entry details my post-CNN news sources and reading methods.
Please leave feedback for CNN
if you share my frustrations.Thanks to Raymond for posting this address in the comments.
Safari in Yosemite is a familiar yet new beast. Among the interface changes, I really didn’t like the way the URL bar behaved. In particular, these things bugged me:
- Not being able to see the full URL.
- The width of the URL entry box.
- The drop-down that appears when you click in the URL bar (when you have a page loaded).
Thankfully, the fixes for these three issues are easy, if not completely obvious.
Full URL not visible in URL bar
By default, Safari truncates URL to just the base “dot” address, regardless of where you are on a site. So if you’re reading my hint about using a dark Dock, Safari’s URL bar will display this:
But you’re really on this page:
If you prefer knowing where you are in the site hierarchy at all times, the fix is simple. Open Safari’s Preferences, go to Advanced, and add a checkmark next to “Show full website address.”
The URL box will now show the full URL of the page you’re viewing. Of course, that will lead to a second problem—the URL box isn’t large enough to display much of the extended URL. Thankfully, that too is an easy fix.