More succinct markup to aid with page weight and complexity

[GoogleCodeExporter]

Hi,

As a possible enhancement the markup for the static publishing method could
be considerably shortened to aid with page weight and complexity. This may
also apply to the markup generated by the dynamic method.

Full details can be found at the following discussion:
http://groups.google.com/group/swfobject/browse_thread/thread/8f071313edb37df6

Tests and results can be found at:
http://dl.dropbox.com/u/3417104/swfobject/browsers.zip 

Cheers,

SJ

Original issue reported on code.google.com by raid...@hotmail.co.uk on 10 Dec 2009 at 10:41

[GoogleCodeExporter]

This has been investigated and (with a few modifications) looks like it may be 
used
in the next release.

Changing type from "defect" to "enhancement"

Original comment by platelu...@gmail.com on 13 Jan 2010 at 4:30

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi,

Out of curiosity what are the "few modifications"? and what are the reasons for 
them?
It would be good to know as we're currently using the suggested markup and if 
you
have found problems with it we'll need to make some changes.

Thanks,

SJ

Original comment by raid...@hotmail.co.uk on 23 Feb 2010 at 5:49

[GoogleCodeExporter]

First of all, thank you for your submission and suggestions.

We haven't found any problems with the current SWFObject syntax, but we all 
agree
we'd like to simplify where possible. Bobby had tried a number of variations 
when he
initially developed SWFObject 2's static embed syntax, including one similar to 
your
proposal. He mentioned he had run into an error someplace when using that 
syntax, but
can't remember where. Thus he wound up with the current syntax.

I've personally tried a slew of syntax approaches in an effort to simplify the
existing code, and always wind up with syntax close to your proposal. It makes 
the
most sense and is the easiest to work with (except maybe for the tricky second
conditional comment).

We haven't made an official determination yet -- more testing is required, esp. 
in
light of Bobby's earlier troubles with similar syntax -- but we're looking at
implementing the following syntax:

------------------

<!--[if IE]>
<object id='mySWF' classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' 
width='550px'
height='400px'>
<param name='movie' value='file.swf'>
<![endif]-->

<!--[if !IE]>-->
<object id='mySWF' type='application/x-shockwave-flash' data='file.swf' 
width='550px'
height='400px'>
<!--<![endif]-->

<param name='allowfullscreen' value='true'>
<param name='allowscriptaccess' value='sameDomain'>

<p>Fallback HTML</p>

</object>

------------------

This syntax is almost identical to the syntax you proposed in your last Google 
Groups
post. The biggest change from your proposal is the inclusion of the same ID in 
both
objects; in theory, the two objects will never co-exist, therefore the ID will 
always
be unique. This would eliminate the need for the swfobject.getObjectById method.

We're not using any nested <div>s, though developers are free to add them if 
they
choose. All <param> elements are being nested inside the inner <object>, except 
the
'movie' param, which is required by the IE-specific <object> but not the other 
one.

We're placing the conditional comments on their own lines for readability and 
have
used a single closing </object> tag instead of two (I believe you touched on 
this in
one of your later examples, too).

To summarize, the current static embed code works great and has no errors. It's 
the
most proven bulletproof solution so far. However, we're interested in making the
syntax simpler, hence the research on this updated syntax. The addition of the 
dual
IDs would allow us to eventually simplify the JavaScript library, as well.

Original comment by platelu...@gmail.com on 23 Feb 2010 at 7:19

[GoogleCodeExporter]

Update: the newer syntax causes event.ref to fail in Firefox (3.6) when using
callbacks in swfobject.registerObject.

It appears to be a DOM load timing issue; if an alert is thrown into the code 
before
the event.ref object is referenced, the DOM finishes updating and event.ref 
returns
the proper HTML element as expected.

The same page(s) work fine in Safari 4 and Opera 10.10

Original comment by platelu...@gmail.com on 26 Feb 2010 at 7:28

[GoogleCodeExporter]

Tested fine in:
 * IE6 (WinXP)
 * Safari 4 (OSX 10.6)
 * Opera 10.10 (OSX 10.6)

Failed in:
 * Firefox 3.6 (OSX 10.6)
 * Firefox 3.0.17 (WinXP)

Original comment by platelu...@gmail.com on 26 Feb 2010 at 8:05

[GoogleCodeExporter]

I have modified getObjectById to include logic that supports both the 
simplified and classic static publishing markup.

Note: Testing has revealed that the simplified markup works fine in every 
browser, but Firefox sometimes returns null when checking for SetVariable in 
the getObjectById function (via the matchVersions function that gets invoked on 
page load). Subsequent use of getObjectById works without issue. This is most 
likely a timing issue, where Flash Player hasn't completely initialized when 
SetVariable is checked, returning a premature null.

Original comment by platelu...@gmail.com on 25 May 2011 at 5:19

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by ilyaifa...@gmail.com on 26 Sep 2011 at 11:27

Attachments:

• bintang.putih.js

[GoogleCodeExporter]

Original comment by ilyaifa...@gmail.com on 26 Sep 2011 at 11:39

Attachments:

• JavascriptCursorAnimasiNagaTerbang.txt