Object Patent Magic Woes

Well, it seems that Object Patent Magic is not without it’s problems. I originally intended for this to be a super tiny drop in patch that could be used on any existing site to solve the click to activate issue in IE. But while it does work on everything that I’ve deployed it with, it doesn’t work on all of everything (like the demo) in IE 6 (IE 7 seems fine). I’m not sure what is causing it, but the problem occurs when you attempt to load a large swf that hasn’t already been cached (meaning the first time someone loads your page).

Just to be sure that there wasn’t some easy solution that I could “borrow” from Karina Steffens, I tested ObjectSwap, and sadly, the problem exists there as well.

There is good news though. I don’t think this problem will turn up much, and the behavior is quite consistent, so it’s easy to test for. To test for it, clear your browser history and cache in IE 6. Then, test load up any pages that use Object Patent Magic or ObjectSwap. If the flash movies loads, you are fine. If you get the space where the movie should load, but it doesn’t load. You’ll have to use a different solution to get around the “click to activate” problem, at least for now.

On the horizon, I do have a new loader swf that I’ve been working on, which could be used to solve this problem. More on that later.

No Embedded Web Fonts?

I occasionally come across an argument against the implementation of embedded web fonts in web browsers and I wanted to comment on it.

The argument is that embedding fonts in web pages should not be allowed, because either people don’t have the rights to use fonts that way, or because it’s too easy for users to steal the fonts, or some combination of the two. It’s debilitating for those who hold that position, and they may be missing out on a lot of potential opportunity. Craig Kroeger sells a set of fonts specifically for use in Adobe Flash, and even licensed them for distribution with Adobe Flash CS3. And that’s just for Flash designers. Imagine a market the size of the whole internet.

Without proper web font embedding technology, there are too many hurdles to uses custom type faces on your website. You can use Photoshop created text graphics, and there are some tools to help make using custom typography on the net easier, like sIFR (which relies on the Adobe Flash Player). While these are creative solutions, they are pretty restrictive – limiting the use of fonts to small blocks of text, like headers. They can also be time consuming to set up, and there is no way for web page designers to use these techniques for body copy. So other than some sparse use here and there, web designers don’t even consider using – or licensing – fonts for web sites, and instead stick with the same 10 fonts that most people have on their systems already.

Just as in print, or with photos or body copy, or any other licensable content, it’s on the shoulders of designers to make sure they are abiding by their license agreements. License templates exist that give designers the right to embed fonts in PDFs and other forms of distributable electronic document, and it’s generally well understood that the rights to images found on a web site belong to the owners that web site. When there are violations, friendly notices, or nasty-grams from the layers, seem to do the trick to get things resolved. These same principles undoubtedly apply to embedded fonts, and are no more complicated. Those are the solutions to possible abuse.

If we must though, I would suggest a move to a middle ground, and follow the example of the natural restrictions placed on photos. Since photos are reduced in quality and in size when converted to jpegs, re-use is impractical for high quality output. So browser producers could consider a special, difficult for end users to install font format for embedded web fonts, something based on SVG maybe. This would probably be a good idea for a number of reasons anyway, including smaller file sizes and better cross platform compatibility. Fonts could then be converted and subsetted for use in web pages, in the same way that they are converted and subsetted for use in other web distributable formats, like Adobe Flash, Director, PDF, and Silverlight.

I hope Opera CTO Håkon Wium Lie will stand by his publicly stated desire to see embedded web fonts come to Opera, and that something like that might be the catalyst that gets the other browser makers moving on embedded fonts.

I think the time has long passed for embedded web fonts.


Embedible web fonts and the rights counter argument

Gah! I’d like to apologize to anyone who received a ping of a very early draft version of this post, or had to suffer through that unfinished thought dump or any of the hurried revisions in between.

I’ll post the finished article in a little while.

I hit the publish button accidentally on my way to click the File menu in Windows Live Writer, and the thing published without warning. Time for a feature request – either warn before posting by default, or move the publish button to a less accident prone location.

Update: I posted the finished article.

Object Patent Magic and a note about javascript defer

I’ve updated Object Patent Magic. It was broken for a while. It seems that doing the swap using a deferred script (which loads sooner than window.onload does) causes some problems with if you interrupt already loading content, then try to load it again (which is exactly what Patent Magic for swfs and some PNG transparency fixes are doing when you use a deferred script).

So that leaves us with some caveats; Using this method hides the movies until the page’s onload event fires, which includes downloading swf files (I did some testing to make sure it is not actually running the swf, and it doesn’t appear to be, as long as the object’s display style is set to “none” – if anyone could help me confirm that, that’d be awesome.). So as with the satay method, I’d recommend using a shim swf that can load itself quickly, then load the main swf file through that. This actually provides a nice opportunity for in swf flash version detection and upgrade prompting using Express Install.

Anyway, it’s updated and posted, so if anyone would like to give it a try, feel free.

The PatentMagic demo page is fully validating XHTML 1.1 as a bonus (using satay)

unFocus.History Keeper 2.0 Beta 1 – Out Now!

The official Google Code name is unfocus-history-keeper. You can find the latest source in SVN. I will be doing development from trunk for now, until I can get to the tags and branches and whatnot to keep things organized.

For now, here is a snapshot. I’ll call it History Keeper 2.0 Alpha 1 for now. Let’s see where this goes from here.

For the first bug, the last state gets lost in some browsers, if you leave the site and then come back using the back button. I know how to fix it, i just need the time to implement that fix. That is the only known bug, so please feel free to leave a report in the issue tracker at Google Code if you find any more.

Also of note, you will find the source for the Swf Tools in there too (SwfHTML, FlashPlayerInfo, etc.) but if you are using ExternalInterface and SwfObject, you can safely omit those files when using History Keeper. You will not find any Actionscript code in there just yet. I’m still in the process of cleaning that stuff up (which basically means that the Communication stuff is incomplete in this release).

For your convenience, you will find two compressed JavaScript files in the root of the archive, unFocus-History-p.js and unFocus-HistorySwf-p.js.

unFocus-History-p.js contains:

  • EventManager.js
  • History.js

unFocus-HistorySwf-p.js contains:

  • EventManager.js
  • History.js
  • FlashPlayerInfo.js
  • SwfUtilities.js
  • SwfHTML.js

These were compressed using Dean Edwards’s Packer (included in above listed order).

There is also a QuickLoader Object in there, that may or may not have a bunch of quirks. Feel free to test it out. It attempts to begin working on the DOM as soon as it’s ready instead of waiting for the body’s onload event to fire.

Enjoy! 🙂 (Download here)