It seems that my new div-based pet codes are sometimes not showing up on some people’s layouts. Why not?
Due to MySpace’s generally crappy HTML, any CSS layouts have to use stupid selectors like table table table td.text table table div { whatever }. Insanity! See this great post for more insight on MySpace layout nuttiness.
Anyway, it appears that some MySpace layouts are targetting something inside some div that happens to also match my pet code, which itself lives inside a div. These selectors tend to aim to hide whatever it is they’re targetting with display: none or visibility: hidden. This means that my pets turn invisible too! Argh.
I’m not sure what to do about this exactly, except maybe go back to table-based code, or pepper inline style attributes everywhere. Or put everything inside a form, just to be perverse :P
I did a very quick test, and it does appear that the way MySpace uses the <object> tag prevents Flash preloaders from appearing as expected in Internet Explorer (tested versions 6 and 7 for Windows). This is the issue that the Flash Satay article reports on. I will attempt to explain it below, as well, and how it applies to MySpace in particular:
In normal situations, the Flash plugin or ActiveX control will start playing a Flash movie as soon as it has loaded the first frame. Flash movies often put up a progress bar that lets the user now how much longer they will have to wait for the movie to finish loading.
On MySpace, Flash movies now only show a generic graphic icon until the entire Flash movie is loaded, instead of starting immediately. This means that the Flash movie has no opportunity to display its own progress bar to indicate loading status (or to just start playing if preloading is not necessary).
Before
This is the way it is expected to look, and how it does work in Firefox (or in IE when embed or IE’s preferred object tag is used).
After
This is the way Flash movies look on MySpace in IE now, before they have finished loading. Obviously, this is much less attractive and gives no feedback to the user. Worse, if a movie does not require a preloader and expects to be able to stream and play its content as it loads, it is unable to do so.
If MySpace wants to rewrite embeds so drastically, I wish they would just use Geoff Stearns’ SWFObject instead. Not only would that solve the preloading problem above, but it would also fix the Eolas “click-to-active” issue that is still present when viewing user-embedded Flash movies on MySpace with IE.
Here is the way Internet Explorer “prefers” to see the object tag, and is the way that the Flash IDE by default writes out the object tag. However, I believe it is not W3C-standards-compliant (and is also not compatible with Firefox, Safari, etc). When this form of the object tag is used, Flash preloaders work as expected:
<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="320" height="200" id="objectloadingtest" align="middle">
<param name="movie" value="http://bunnyherolabs.com/misc/objectloadingtest.swf" />
...
This is the way MySpace rewrites the object tag, and causes the preload problem. It is (I believe) W3C-standards-compliant.
<object type="application/x-shockwave-flash" data="http://bunnyherolabs.com/misc/objectloadingtest.swf" height="200" width="320" align="middle">
<param name="movie" value="http://bunnyherolabs.com/misc/objectloadingtest.swf" />
...
Mashable reports on MySpace’s new <embed> tag changes. It looked like MySpace was disabling all embed tags, but it seems that they were rolling out this big change. It’s explained better in Chris Bennet’s comment to that post, which I reproduce below (I hope he doesn’t mind):
14. Chris Bennett – January 18, 2007
Before:
MySpace required embed tags to embed Flash content. The preferred method was to embed via the object tag, but that was completely stripped out by MySpace.
This morning:
MySpace began rolling out a change that would block embed tags, but allow object tags for embedded content. This caused some users to report stickers as “not working.”
This morning + n hours:
MySpace finished the change that converted a user’s embed tags to properly formatted object tags and therefore allowed.
Soon, all embedded objects on MySpace will be using object instead of embed. The previous restrictions such as “allownetworking = internal”, “allowScriptAccess = never”, “enableJSURL = false”, and “enableHREF = false” all remain. One new FlashVar I do not recognize is “saveEmbedTags = true” which is probably an internal flag to MySpace.
This is probably part of a larger, more-intelligent Flash filtering solution that would lend itself to a situation where MySpace acts as a gatekeeper to Flash stickers (as discussed).
I wrote about some of MySpace’s previous changes to embedding code in my old tech blog.
I am wondering about the possible technical implications of this change. According to Drew McLennan’s Flash Satay article, the form of the <object> tag that MySpace is using does not stream large Flash movies! To quote the article:
After testing with some largish movies, I noticed something amiss. While every other browser was getting it right, IE/Windows was not streaming—it was waiting for the entire movie to download before playing it. This is fine for small movies, but for anything serious, the lack of streaming is unacceptable.
I haven’t tested this to see if this is still true with the latest versions of IE6 and IE7. If so, this kind of sucks :( Progress bars will not work in such a world, unless everything is “satayed” as described in McLennan’s article.
I guess we shall see what other effects this might have, and what other changes MySpace might make in the near future. If the past is any indication, there will be zero official word from MySpace about this.