@Kyle

Thanks for the explanation.  You and I are in agreement as to what
switchOffAutoHideShow() does.  I also agree that defaulting to a hack isn't
the best practice if there is an alternative available.  And you're
absolutely right, I haven't seen it reproduced either where someone either
wraps the calls in a domready event or puts their javascript in the <HEAD>.
My concern with this FF3.5 condition (that we don't see in prior browsers)
is that it isn't something that we can control without creating some sort of
"hack" explicitly for FF3.5 or wait for the Mozilla boys to address why this
may be occurring.  (At least given some of the restrictions some publishers
face).

At this point, I think that going back to basic principles - using the
standard dynamic publishing method (and/or) static publishing method as
documented, and then modifying to utilize the domReady method of choice is
what will work here.  I am concerned that at least one forum member had
problems with the domReady event in SWF but was able to utilize the jQuery
method just fine.  Any underlying code that might be significantly different
in terms of how jQuery handles detecting and executing ondomready functions
vs. SWFObject?  Or do you think it might just be user error?

Vincent

On Wed, Jul 22, 2009 at 2:25 PM, Getify Solutions, Inc. <[email protected]>wrote:

>  switchOffAutoHideShow() was (and is, IMHO) only intended for controlling
> the behavior of swfobject during the split second (usually) between when
> alternate content appears and when the flash object replaces it. For dynamic
> publishing, it disables logic which hides the alternate content until the
> SWF is embedded. For static publishing, it disables logic which hides the
> SWF until a version check happens.
>
> In both cases, there was the possible "FUOC" (flash of unstyled content)
> problem, which some users found ugly, which was that there was a flicker of
> both pieces of content (and even a blank white space while a SWF initially
> loads) that it could create, depending on page conditions.
>
> The idea with the function was to prevent swfobject from mucking with the
> visibility of the alt-content/swf during that brief interlude of time. In
> both cases, swfobject always restores the proper visibility, unless other
> race conditions have occurred.
>
> In most cases, we see that people who do not (or cannot) put code in the
> HEAD of the document, but instead put it inline, and even usually right
> above, with the markup, see this issue, especially with FF3.5.  This (IMHO)
> is not a FF bug, but an authoring failure, as code should not be inlined
> like that.  If it must be, it should at least be wrapped in dom-ready
> detection code, as mentioned in the previous emails with
> "swfobject.addDomLoadEvent()".
>
> I have yet to see a reliable reproduceable bug referring to FF3.5 (or any
> other browser) where the author was doing one of those two things and the
> SWF was still failing to load.
>
> And even then, I wouldn't say, "hack it with switchOffAutoHideShow()". I'd
> say, let's troubleshoot what the real bug is, not just mask it with a
> function that wasn't intended for that purpose.
>
> That's just my feelings on the topic.
>
>
>
>
>  *From:* Vincent Polite <[email protected]>
> *Sent:* Wednesday, July 22, 2009 4:15 PM
> *To:* [email protected]
> *Subject:* Re: Basic question about SWFObject 2.0 and CDN
>
> @Kyle, question - I think you answered this in a different thread, but why
> do you say that the switchOffAutoHideShow method is being misused in the
> hack scenario?  It "seems" that FF3.5 has an issue with rendering using the
> default mechanism that SWFObject attempts to use to show/hide the
> appropriate flash divs.  The method where it swaps and dynamically generates
> css to make offending divs visible/invisible don't seem to work unless you
> bypass the default behavior via that method call (unless of course you put
> everything in the head, which is desirable, but not always possible)
>
> Do you know happen to know the history behind why this method was included
> in the API as a public method?  Seems like a valid use case unless it was
> just intended for testing/debugging purposes?
>
> V
>
> autoHideShow
>
>
> On Wed, Jul 22, 2009 at 2:10 PM, Getify Solutions, Inc. 
> <[email protected]>wrote:
>
>>
>> http://code.google.com/p/swfobject/wiki/api
>>
>> --Kyle
>>
>>
>>
>>
>> --------------------------------------------------
>> From: "citznfish" <[email protected]>
>> Sent: Wednesday, July 22, 2009 4:08 PM
>> To: "SWFObject" <[email protected]>
>> Subject: Re: Basic question about SWFObject 2.0 and CDN
>>
>> >
>> >
>> >
>>  > On Jul 22, 2:03 pm, "Getify Solutions, Inc." <[email protected]> wrote:
>> >> swfobject has the "addDomLoadEvent()" function, which you can use for
>> >> this. You don't need to use jquery.
>> >>
>> >> --Kyle
>> >
>> > HI Kyle,
>> >
>> > Any idea on where I can find documentation on that? I tried searching
>> > the online documentation and FAQ and got 0 results...
>> >
>> > http://code.google.com/p/swfobject/wiki/documentation
>> >
>> > Thanks!
>> > >
>> >
>>
>>
>>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"SWFObject" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/swfobject?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to