<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>bunnyhero dev &#187; MySpace</title>
	<atom:link href="http://www.bunnyhero.org/category/myspace/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.bunnyhero.org</link>
	<description>Notes on iPhone, Flash and Web development</description>
	<lastBuildDate>Fri, 23 Jul 2010 18:00:10 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>MySpace layouts are a pain</title>
		<link>http://www.bunnyhero.org/2007/03/02/myspace-layouts-are-a-pain/</link>
		<comments>http://www.bunnyhero.org/2007/03/02/myspace-layouts-are-a-pain/#comments</comments>
		<pubDate>Fri, 02 Mar 2007 19:37:01 +0000</pubDate>
		<dc:creator>bunnyhero</dc:creator>
				<category><![CDATA[CSS]]></category>
		<category><![CDATA[MySpace]]></category>

		<guid isPermaLink="false">http://www.bunnyhero.org/2007/03/02/myspace-layouts-are-a-pain/</guid>
		<description><![CDATA[It seems that my new div-based pet codes are sometimes not showing up on some people&#8217;s layouts. Why not? Due to MySpace&#8217;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&#8217;re targetting with display: none or visibility: hidden. This means that my pets turn invisible too! Argh. I&#8217;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]]></description>
			<content:encoded><![CDATA[<p>It seems that my new div-based pet codes are sometimes not showing up on some people&#8217;s layouts. Why not?</p>
<p>Due to MySpace&#8217;s generally crappy HTML, any CSS layouts have to use stupid selectors like <code>table table table td.text table table div { whatever }</code>. Insanity! See <a href="http://www.mikeindustries.com/blog/archive/2006/04/hacking-myspace-layouts">this great post for more insight on MySpace layout nuttiness</a>.</p>
<p>Anyway, it appears that some MySpace layouts are targetting <em>something</em> inside some <code>div</code> that happens to also match my pet code, which itself lives inside a <code>div</code>. These selectors tend to aim to hide whatever it is they&#8217;re targetting with <code>display: none</code> or <code>visibility: hidden</code>. This means that <strong>my pets turn invisible too</strong>! Argh.</p>
<p>I&#8217;m not sure what to do about this exactly, except maybe go back to table-based code, or pepper inline <code>style</code> attributes everywhere. Or put everything inside a <code>form</code>, just to be perverse :P</p>
]]></content:encoded>
			<wfw:commentRss>http://www.bunnyhero.org/2007/03/02/myspace-layouts-are-a-pain/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>New MySpace embed rewriting &#8220;breaks&#8221; Flash preloaders</title>
		<link>http://www.bunnyhero.org/2007/01/26/following-up-on-myspace-embed-filters/</link>
		<comments>http://www.bunnyhero.org/2007/01/26/following-up-on-myspace-embed-filters/#comments</comments>
		<pubDate>Sat, 27 Jan 2007 00:48:38 +0000</pubDate>
		<dc:creator>bunnyhero</dc:creator>
				<category><![CDATA[Browsers]]></category>
		<category><![CDATA[Flash]]></category>
		<category><![CDATA[MySpace]]></category>

		<guid isPermaLink="false">http://www.bunnyhero.org/2007/01/26/following-up-on-myspace-embed-filters/</guid>
		<description><![CDATA[I did a very quick test, and it does appear that the way MySpace uses the &#60;object&#62; 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&#8217;s preferred object tag is used). After This is the way Flash [...]]]></description>
			<content:encoded><![CDATA[<p>I did a very quick test, and it does appear that the way MySpace uses the <code>&lt;object&gt;</code> tag <strong>prevents Flash preloaders from appearing as expected in Internet Explorer</strong> (tested versions 6 and 7 for Windows). This is the issue that the <a href="http://alistapart.com/articles/flashsatay">Flash Satay article</a> reports on. I will attempt to explain it below, as well, and how it applies to MySpace in particular:</p>
<p>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.</p>
<p>On MySpace, Flash movies now only <strong>show a generic graphic icon until the entire Flash movie is loaded</strong>, 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).</p>
<h4>Before</h4>
<p><img src="/static/myspace-object/firefox.png" alt="how it used to work" style="float: left"/> This is the way it is expected to look, and how it does work in Firefox (or in IE when <code>embed</code> or IE&#8217;s <a href="#myspace-object-appendix">preferred <code>object</code> tag</a> is used).</p>
<h4 style="clear: both">After</h4>
<p><img src="/static/myspace-object/ie.png" alt="how it looks now" style="float: left"/> 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.</p>
<p>If MySpace wants to rewrite <code>embed</code>s so drastically, I wish they would just use <a href="http://blog.deconcept.com/swfobject/">Geoff Stearns&#8217; SWFObject</a> instead. Not only would that solve the preloading problem above, but it would also fix the Eolas &#8220;click-to-active&#8221; issue that is still present when viewing user-embedded Flash movies on MySpace with IE.</p>
<h4><a name="myspace-object-appendix">Appendix</a></h4>
<p>Here is the way Internet Explorer &#8220;prefers&#8221; to see the <code>object</code> tag, and is the way that the Flash IDE by default writes out the <code>object</code> tag. However, I believe it is not W3C-standards-compliant (and is also not compatible with Firefox, Safari, etc). When this form of the <code>object</code> tag is used, Flash preloaders work as expected:</p>
<p><code style="text-align: left">&lt;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"&gt;<br />
&lt;param name="movie" value="http://bunnyherolabs.com/misc/objectloadingtest.swf" /&gt;<br />
...</code></p>
<p>This is the way MySpace rewrites the <code>object</code> tag, and causes the preload problem. It is (I believe) W3C-standards-compliant.</p>
<p><code style="text-align: left">&lt;object type="application/x-shockwave-flash" data="http://bunnyherolabs.com/misc/objectloadingtest.swf" height="200" width="320" align="middle"&gt;<br />
&lt;param name="movie" value="http://bunnyherolabs.com/misc/objectloadingtest.swf" /&gt;<br />
...</code></p>
]]></content:encoded>
			<wfw:commentRss>http://www.bunnyhero.org/2007/01/26/following-up-on-myspace-embed-filters/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>MySpace changes their Flash/embed filtering again</title>
		<link>http://www.bunnyhero.org/2007/01/18/myspace-changes-their-flashembed-filtering-again/</link>
		<comments>http://www.bunnyhero.org/2007/01/18/myspace-changes-their-flashembed-filtering-again/#comments</comments>
		<pubDate>Fri, 19 Jan 2007 02:43:11 +0000</pubDate>
		<dc:creator>bunnyhero</dc:creator>
				<category><![CDATA[Browsers]]></category>
		<category><![CDATA[Flash]]></category>
		<category><![CDATA[MySpace]]></category>

		<guid isPermaLink="false">http://www.bunnyhero.org/2007/01/18/myspace-changes-their-flashembed-filtering-again/</guid>
		<description><![CDATA[Mashable reports on MySpace&#8217;s new &#60;embed&#62; tag changes. It looked like MySpace was disabling all embed tags, but it seems that they were rolling out this big change. It&#8217;s explained better in Chris Bennet&#8217;s comment to that post, which I reproduce below (I hope he doesn&#8217;t mind): 14. Chris Bennett &#8211; 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 [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://mashable.com/">Mashable</a> reports on <a href="http://mashable.com/2007/01/18/myspace-disables-flash/">MySpace&#8217;s new <code>&lt;embed&gt;</code> tag changes.</a> It looked like MySpace was disabling all <code>embed</code> tags, but it seems that they were rolling out this big change. It&#8217;s explained better in <a href="http://chrisrbennett.com/">Chris Bennet&#8217;s</a> <a href="http://mashable.com/2007/01/18/myspace-disables-flash/#comment-158136">comment to that post</a>, which I reproduce below (I hope he doesn&#8217;t mind):</p>
<blockquote><p>
14. Chris Bennett &#8211; January 18, 2007</p>
<p>Before:<br />
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.</p>
<p>This morning:<br />
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.”</p>
<p>This morning + n hours:<br />
MySpace finished the change that converted a user’s embed tags to properly formatted object tags and therefore allowed.</p>
<p>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.</p>
<p>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).
</p></blockquote>
<p>I wrote about some of MySpace&#8217;s previous changes to embedding code <a href="http://bunnyherolabs.com/tech/?cat=12">in my old tech blog</a>.</p>
<p>I am wondering about the possible technical implications of this change. According to Drew McLennan&#8217;s <a href="http://alistapart.com/articles/flashsatay">Flash Satay article</a>, the form of the <code>&lt;object&gt;</code> tag that MySpace is using does not stream large Flash movies! To quote the article:</p>
<blockquote><p>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.</p></blockquote>
<p>I haven&#8217;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 &#8220;satayed&#8221; as described in McLennan&#8217;s article.</p>
<p>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.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.bunnyhero.org/2007/01/18/myspace-changes-their-flashembed-filtering-again/feed/</wfw:commentRss>
		<slash:comments>15</slash:comments>
		</item>
	</channel>
</rss>
