With the recent announcements that YouTube and Vimeo are both releasing HTML5-based video players, one has to wonder about the impact of those moves on Adobe. Adobe’s Flash had been (and is) THE standard for delivering multimedia content over the web, capturing something like 99% of internet users. HTML5 allows many Flash-like animations/videos/experiences without the need for a seperate plugin or buffering (that’s right – skip to a different point in that YouTube video without waiting for it to load!).
Adobe doesn’t derive much revenue from Flash – so this isn’t going to crimp their cashflow necessarily – but it is a major part of their broader brand recognition. (For the curious, Flash and other platforms generate about 6% of Adobe’s revenue, but half of that comes from Mobile solutions that likely don’t include Flash. Creative software is the bulk of the revenue stream, forming about 60% of the total.). I’m curious what indirect impact it could have on the rest of the company.
For that matter, Microsoft’s Silverlight — the Flash alternative that powers the excellent Bing Maps — doesn’t have nearly the market share of its competitor. Where does this leave it?
Flash, Silverlight and other proprietary delivery systems are essentially browser replacements. They deliver web experiences which browsers on their own can not. To the extent we can move away from plugin multimedia and incorporate it directly into the web standard, that’s a good thing in my mind. Unfortunately, browser support for HTML5 is minimal – just the latest version of Safari and the nightly Webkit builds (including non-production versions of Chrome). Plugins, by contrast, are widely supported and bring content to potentially any browser. It’s hard for me to imagine why people wouldn’t want the latest, fastest, and most secure web technology available… but then again, I’m constantly surprised by the number of TGR visitors using IE6!
And a special message for those visitors: please click here to download Google Chrome.
Google Chrome for Mac has finally been released (in beta, but who’s complaining?) and I’ve been testing it as my primary browser. It’s already my top choice on Windows (this development making it all the more sweeter) and I have to say – once you use a combined address/search bar, there’s absolutely no going back.
And while we’re comparing Safari 4 to its beta, I had also noticed various progress bars that were available in the beta. The final release has gone with none of them, choosing instead a more radically visible indicator:
My immediate reaction is that I preferred the subtlety of the beta indicator (eventually preferring it to the Safari 3 one), but it’s not a bad choice. In the Windows version of Safari, however, I think that the indicator is too bold (it has a darker color than on a Mac) and appears to float above the address bar rather than nestle inside it.
The other big change is that the tabs have moved back down below the address bar, a la Safari 3. Their temporary displacement in the beta was most likely a response to Chrome’s tab placement. One strange side effect is that the tabs appear to run into the address bar, rather than the page itself:
When the Safari 4 beta came out, I observed that having more than one tab open would break any resize bookmarklets. I can confirm that this is still the case in the stable release of Safari 4.
Cody Robbins commented on my original post and noted that the problem has been filed as a WebKit bug. This means it may be indicative of larger problems with WebKit’s JavaScript framework. Which is a shame, because Java screams in Safari 4.
Interestingly, I couldn’t get any resize bookmarklets to work in Google Chrome, which is also based on WebKit, even though I use other bookmarklets in Chrome on a daily basis. The mystery lives on…
Wordpress 2.7 was released in December 2008 and represented a milestone in the software’s development, incorporating a number of major changes in particular to the back end. One of the most visible was the inclusion of the latest TinyMCE post editor (version 3.2).
Unfrotunately, TinyMCE 3.2 doesn’t play nicely with the Safari 4 beta. Specifically, adding a hyperlink locks up the system; this has to be done from the html editor instead. This wasn’t a surprising development – TinyMCE and Safari have a long history of battles – but it is a serious one, and has led many Wordpress users to drop Safari and adopt Camino or a two-browser solution instead. Today I noticed that the second beta of Wordpress 2.8 has been released, and it upgrades the TinyMCE editor to version 3.2.4. I gambled on that extra .4 to fix my Safari problems and installed the beta.
And there was much rejoicing: in Wordpress 2.8, you can create hyperlinks in Safari. That’s reason enough to upgrade, in my opinion. Additionally, the back-end seems a bit snappier, which is always a plus. There has been one casualty, however. I was getting an error message which read:
Fatal error: Call to undefined method SearchSpider::_weak_escape()
It turns out this was due to a problem with the otherwise-excellent Search Unleashed plugin, and it interfered with drafting, saving, and publishing posts – so obviously the plugin had to go.
That’s right, dear readers, I traded your ease of search for my ease of links. Until compatibility is restored, please accept this video in apology:
Update 6/8/09: The release version of Safari 4 went with none of these.
One of my favorite Safari features is that the address bar doubles as a progress bar, whereas most browsers place a progress bar at the bottom of the screen, taking up real estate. This is how mobile Safari works on the iPhone and it is how the current release version of Safari 3 works.
The Safari 4 beta, however, gets rid of this behavior in favor of a little “spinning wheel” that tells you that a page is loading but gives no indication of how much has been loaded. It sits at the far right of the address bar:
It turns out that there are actually three different progress indicators available in the Safari 4 beta. The first is the default choice of the spinning wheel. The second is the old Safari 3 progress bar, which looks like this:
To enable this throwback indicator, load up Terminal and execute these two commands (while these two lines of code are harmless on their own, use caution while messing around in Terminal — you can easily damage your computer from the command line). To restore the original settings, just replace NO with YES. defaults write com.apple.Safari DebugSafari4LoadProgressStyle -boolean NO
defaults write com.apple.Safari DebugSafari4IncludeToolbarRedesign -boolean NO
As you might expect, the first line turns the new Safari 4 progress indicator off. The second line restores the entire address bar to its Safari 3 look – meaning the new bookmark button and other embedded controls disappear. You need to revert both parameters to get the old progress bar back.
What happens if you only turn off one setting? That depends on which one you choose. If you disable the LoadProgressStyle parameter but leave IncludeToolbarRedesign on, nothing happens as far as I can tell and the default Safari 4 behavior persists. If you leave LoadProgresStyle on and turn IncludeToolbarRedesign off, however, you get a third, hidden progress indicator:
This little “progress icon” is my personal favorite – it gives complete information with minimal real estate use and distraction. Unfortunately, I like the new address bar in Safari 4 more than I miss a useful progress indicator, so I’m leaving the default settings turned on. Which do you prefer?
Update 6/8/09: This still happens in the release version of Safari 4.
Update 6/13/09: More details available at Sakuzaku.
I have been unable to verify if this is a widespread problem or just my luck, but my Java bookmarklets are no longer working in the Safari 4 beta. Bookmarklets are mini-applications that can be run by a web browser.
Specifically, I use two bookmarklets to quickly resize my browser window in an attempt to solve my frustration with Mac OS X not having a proper “maximize” button. One bookmarklet makes the window take up the whole screen, the other makes the window smaller and recenters it. They sit in my bookmarks bar, and so resizing/recentering is just a click away (or, a command-1 or command-2 away — the only time I’ve ever appreciated that Safari chooses bookmarks, not tabs, in that manner). But suddenly in Safari 4, neither is working!
The maximize bookmarklet is: javascript:self.moveTo(0, 0); self.resizeTo(screen.availWidth, screen.availHeight);
The small window bookmarklet is: javascript:self.resizeTo(1024, screen.availHeight * .9);self.moveTo((screen.availWidth - 1024) / 2, screen.availHeight - screen.availHeight * .95);
Is anyone else having problems executing this code?
Edit (5 minutes later): And now it’s working again! Never mind! Maybe it was related to some hacking I was doing in Safari’s developer settings… more on that later if it turns out interesting.
Edit (10 pm): The problem is related to multiple tabs being open. Bookmarklets work fine with just one tab.
I am really happy with my WordPress installation, and I love my Mac, so I was rather disappointed to find that they don’t play nicely together in one regard. The TinyMCE editor has a devilish tendency to strip line breaks if accessed in Safari 3+, both in the visual and code views. The prospect of running around entering <p> and <br> all over my posts… not pleasant. There seems to be a massive debate raging about whose fault this is — Apple, TinyMCE, WordPress, and I frankly don’t care as long as there is a way to fix it. I find other browsers slow, clunky and (yes) ugly compared to Safari, so I have absolutely no desire to adopt a two-browser solution.
Fluid is a program that creates a single-site browser (the cool kids say SSB). Essentially, you give it a web address and it creates a completely native Mac OS application which has one purpose — to run that website. The classic examples are running it with GMail, Facebook, etc. etc. so you can keep those sites in your dock or whatever. It is fast, nice to look at, and – most critically – its engine is for one reason or another compatible with TinyMCE.
So I basically run a 1.5 browser solution — a native app called “This is the Green Room” for site admin and Safari for everything else (well, and Cyberduck for FTP, Textmate for coding and a yet undetermined CSS editor for design, but you know what I mean). It isn’t as slow or jarring as jumping off to Camino or Firefox, and until Safari comes around I’m sticking to it. In fact I like it so much I may keep it for quite a while even after…
