jQuery SWFObject Plugin

[Jonathan]

Hey all,

I've been working on a jQuery port of the SWFObject library. The goal
is thus far:

What is the jQuery SWFObject plugin?
The jQuery SWFObject plugin is an addon for jQuery that offers all the
unique functionality of SWFObject while replacing and upgrading the
internal functionality with those already available through jQuery.

And what is SWFObject?
SWFObject is an easy-to-use and standards-friendly method to embed
Flash content.

And what is jQuery?
jQuery is a small but power-packed bundle of javascript functions that
make writing javascript quick and simple. Selecting elements on your
page is like using CSS, learning and using functions requires minimal
fuss, and the learning curve is sometimes described as "zero".

What's difference between this plugin and regular SWFObject?
First, it's smaller. Where SWFObject needs to create its own
selectors / DOM loaders / and the like, that functionality has been
removed and replaced with jQuery's pre-existing ones. Then, it's
faster. There's little argument that jQuery's functionality is about
as fast as complaint javascript can get, so now you get these same
performance benefits in SWFObject. Finally, it's easier. Code looks
cleaner with jQuery, and it's almost always easier to read and get
what's going on. Having the power of SWFObject and the environment of
jQuery is a best-of-both-worlds scenario.

The project page is currently @ http://jquery.thewikies.com/swfobject/

I pass the entire swfobject test suite @ http://jquery.thewikies.com/swfobject/testsuite/
but there are still many jQuery optimizations that I would like to
make within the script.

[Bobby]

Hi Jonathan,

Great work,we're happy to see that you've picked up SWFObject and
created a jQuery plugin :-)

While browsing through your project and documentation there are a few
things that I noticed, and while it is a big list, please regard it as
positive feedback to improve your project.

First and most important. Although probably unconsciously, you are
currently violating our copyright. SWFObject 2 use the MIT license
[ http://www.opensource.org/licenses/mit-license.php ], which clearly
states: "Copyright (c) <year> <copyright holders>" and "The above
copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software."

This means both your minified and uncompressed versions of jQuery
SWFObject need to include the exact following copright header:
/*
SWFObject v2.1 <http://code.google.com/p/swfobject/>
Copyright (c) 2007-2008 Geoff Stearns, Michael Williams, and Bobby van
der Sluis
This software is released under the MIT License <http://
www.opensource.org/licenses/mit-license.php>
*/

The SWFObject version number will tell your users which version of
SWFObject your derived software maps to. We do take copyright
infringements very seriously, so please update this as soon as
possible.

Regarding your documentation, it's currently incorrect and rather
misleading:

> What's difference between this plugin and regular SWFObject?
> First, it's smaller. Where SWFObject needs to create its own
> selectors / DOM loaders / and the like, that functionality has been
> removed and replaced with jQuery's pre-existing ones.

For existing jQuery users it is smaller. It's the opposite for non-
jQuery users. Now, looking at execution, currently your minified
version of jQuery SWFObject plugin is 10.9K (without the required
copyright header), while SWFObject only is 9.7K. Now, you should be
able to create a smaller version using a better compression tool, so
you might want to check that out. Please also read:
http://code.google.com/p/swfobject/wiki/how_to_compress

> Then, it's
> faster. There's little argument that jQuery's functionality is about
> as fast as complaint javascript can get, so now you get these same
> performance benefits in SWFObject.

Incorrect. SWFObject's DomContentLoaded or document.getElementById
will just fire as fast jQuery's (the main way to get references in
SWFObject).

I think that you are mixing up different things here. From what I've
read John Resig has gone through great lengths to improve jQuery's own
performance and has done some benchmarks regarding selectors, however
as explained above SWFObject primarily uses direct references, so no
speed optimizations will be possible here. Also, you can only make
statements like this if you can quantify them, e.g. with an objective
benchmark (if they exist). So this line is misleading and should be
omitted.

> Finally, it's easier. Code looks
> cleaner with jQuery, and it's almost always easier to read and get
> what's going on. Having the power of SWFObject and the environment of
> jQuery is a best-of-both-worlds scenario.

Again, this only counts for existing jQuery users.

To summarize the benefits of jQuery SWFObject over SWFObject:
- For existing jQuery users it can offer a file size improvement if
done correctly (and I am positive you will get there)
- For existing jQuery users it uses the jQuery style of authoring

The downside of jQuery SWFObject over SWFObject:
- Not officially supported by the SWFObject team and functionality may
differ from the original (I speak from experience, e.g. the old UFO
jQuery plugin suffered from incompatibilities). This means that it is
up to the author and jQuery community to test, update and maintain the
plug-in.
- Not interesting for non-jQuery users

Another thing I would like to see changed is that on your project's
website you currently only name 1 SWFObject author, while there are 3
authors, so please update this.

Again, this is all positive feedback to improve your project, which by
itself is great work, however still work in progress. You do need to
add the copyright header to all your jQuery SWFObject files. The rest
I leave up to your discretion. Please let us know when updates are
made. Furthernmore, if we think the updated information on your
project is correct, we are happy to add a link to it in the near
future.

[Getify Solutions, Inc.]

I like the idea that others are going out and trying to find ways to
integrate the goodness of SWFObject into other frameworks and
usage-scenarios. That's good for everyone all around.

However, I think (in my humble opinion) that re-implementing SWFObject
behavior wholesale entirely is perhaps not a good idea, because as Bobby
points out, you'll have support and compatibility problems as SWFObject
moves forward and diverges from the branch you created with your own
implementation.

CheckPlayer (http://checkplayer.flensed.com/) is a project I started that
attempts to augment some of SWFObject's functionality. The strategy I took
was to include the entire SWFObject distribution, as-is, and then provide an
additional API-set that wraps up some of SWFObjects methods to accomplish
various tasks. Granted, there were a few non-public-API parts of SWFObject
that I had to duplicate, such as the browser/plugin detection code, and the
expressInstall logic. But even still, 100% of SWFObject official release is
used behind the scenes (nothing hacked or replaced), which makes things much
more reliable, not only for myself, but for any authors that use my code.
They get the benefit of my library, with the additional flexibility to use
the core SWFObject API (the rock-solid, tested distribution) in various
cases where it makes more sense to them (static publishing, for instance).

I say all that to suggest, perhaps your strategy with your jQuery plugin
could be to provide a jQuery'esque API, but under the covers, still call
SWFObject API functions. In doing so, I think you could get the best of
both worlds (like I tried to do), and I think you'll end up having the two
projects play more nicely with each other, especially as each project
advances with new releases down the road.

Also, I think your plugin will be significantly more simple to implement, as
your only goal would be to provide jQuery style function calls that match up
to the various SWFObject API functions, not having to re-invent the
SWFObject wheel. :)

Just some thoughts.

--Kyle

--------------------------------------------------
From: "Jonathan" <jonath...@gmail.com>
Sent: Monday, October 13, 2008 3:17 PM
To: "SWFObject" <swfo...@googlegroups.com>
Subject: jQuery SWFObject Plugin

[Jonathan]

Hi Bobby,

Thank you for positive feedback and also for bringing these legal
concerns to my attention generously.

The legal concerns and authors. I've updated all of the plugin JS
files to include the proper legal nods, and I took an extra
precautionary measure of adding jQuery's licenseing to the mix as
well. I've been using SWFObject in the SWFObject edition of the
jQuery sIFR Plugin @ http://jquery.thewikies.com/swfobjectsifr/ and
will add the copyrights there as well. I would like to state that I
*found* the "author" by SWFObject googling my way over to deconcept
and then clicking the "About" link; contrary to the rumors that I'm a
Vatican 1 Geoffolic.

The phrasing. Yes yes yes , I read it again, and then again with a
palm to my face. I wrote it on the fly, and in an attempt to sound
exciting I think my descriptions were zealous and kinda jerkish
(sorry). It's been updated to hopefully better reflect the benefits
to the user while keeping an excited and homebrew tone. Your
corrections and suggestions really helped and I predict that I'll be
rewriting that one a few times over.

YUI Compressor. Amazing. Thank you. Later tonight I'll have more
time to start updating all of my script to take advantage of this.

The most difficult task ahead of me technically is to now fully break
apart SWFObject and best leverage jQuery's built-in functionality,
while maintaining a reasonable delta between SWFObject and it's jQuery
counterpart.

Two looming questions.

I have a sandbox @ http://jquery.thewikies.com/swfobject/sandbox/
where I've been twisting and torturing certain features of SWFObject
to determine the best course of action. I noticed that SWFObject
attaches objects to the DOM versus generating a string to inject via
inner or outer HTML. Is there a performance reason for this?

How do any community members and certainly SWFObject authors here feel
about me adding functionality to the jQuery port that allows users to
generate and return the flash embedding without forcibly attaching it
to the DOM, e.g: returning the virtual elements to be used later.
Maybe SWFObject already does this? Does what I'm suggesting make
sense?

[Bobby]

Hi Jonathan,

Thanks for making the updates, we're all happy now :-)

> Two looming questions.
>
> I have a sandbox @http://jquery.thewikies.com/swfobject/sandbox/

> where I've been twisting and torturing certain features of SWFObject
> to determine the best course of action.  I noticed that SWFObject
> attaches objects to the DOM versus generating a string to inject via
> inner or outer HTML.  Is there a performance reason for this?

This is only used for Internet Explorer. IE is a plain pain when it
comes to the DOM and the HTML object element, because for some odd
reason they've only partially integrated it in the DOM, with the
result that we can only fully control it with innerHTML/outerHTML.

> How do any community members and certainly SWFObject authors here feel
> about me adding functionality to the jQuery port that allows users to
> generate and return the flash embedding without forcibly attaching it
> to the DOM, e.g: returning the virtual elements to be used later.
> Maybe SWFObject already does this?  Does what I'm suggesting make
> sense?

Chaining is a very powerful and important concept in jQuery, so I
think that your audience (jQuery authors) expect this behavior.
swfobject.createSWF already returns the newly created object element
(see: http://code.google.com/p/swfobject/wiki/api ), however
swfobject.embedSWF doesn't (why is partially discussed in issue report
126: http://code.google.com/p/swfobject/issues/detail?id=126 ).

Hope this answers your questions,

Bobby

[Jonathan]

Hi Bobby and all,

I've updated the sandbox @ http://jquery.thewikies.com/swfobject/sandbox/
which demonstrates 2 important pieces of progress that I've made.
$.createSWF and $.flashVersion.

1. You can use $.createSWF traditionally or in the modern jQuery
chaining sense. To return a jQuery element, just neglect to specify
the optional ID parameter. Should you specify the ID, $.createSWF
will act traditionally. Also, flashvars can be passed in as a string
or also as an object, since jQuery has native functionality to convert
objects into proper params.

2. $.flashVersion has been successfully tested on IE6, IE7, Opera,
Safari, Chrome, and Firefox 3 running the latest version of Flash. It
still has some work ahead of it to account for the older releases.

The toughest road ahead really sits with expressInstall, because I
have nearly no idea what it actually does.

Jonathan

> This is only used for Internet Explorer. IE is a plain pain when it
> comes to the DOM and the HTML object element, because for some odd
> reason they've only partially integrated it in the DOM, with the
> result that we can only fully control it with innerHTML/outerHTML.

> Chaining is a very powerful and important concept in jQuery, so I
> think that your audience (jQuery authors) expect this behavior.
> swfobject.createSWF already returns the newly created object element

> (see:http://code.google.com/p/swfobject/wiki/api), however