>Looks like Zeldman isn't sure the proposed fixes will be sufficient:
**warning, technical stuff to follow**
I'm not sure the big Z is correct in his article on this.
He says (from his standards-based perspective, and talking about the
"The other proposed solution is much simpler and less expensive to
implement, but completely invalid: a proprietary attribute is added
to the object element . Because it is easy and inexpensive, many
developers will opt for this proprietary solution. In so doing, they
will unwittingly impede the great march toward valid, accessible,
standards-based design (although this is somewhat mitigated by the
fact that few designers who specialize in embedded media are
especially standards-aware, and few standards-based designers are
especially adept at designing with embedded rich media - Todd Dominey
being an exception)."
From my reading of M$'s doc:
"If the OBJECT element used to load the control contains PARAM
elements but none of the PARAM elements specify a source of data
external to the current Web page, then the control does not access
The OBJECT element for an ActiveX control has a new attribute:
NOEXTERNALDATA. Specify true for this attribute to indicate that the
control does not access remote data and that Internet Explorer should
not prompt the user. If a PARAM element does reference a remote
source of data and you specify true for the NOEXTERNALDATA attribute
of the OBJECT element, the value of that PARAM element is not
provided to the IPersistPropertyBag interface for the control.
The following example shows an OBJECT tag that loads a control
without a prompt from Internet Explorer because the NOEXTERNALDATA
attribute is set to true . The control does not receive the URL
I conclude that ANY data external to the WEB PAGE won't be loaded.
this 'noexternaldata' thing seems to work hand in hand with using the
base64-encoded data directly in the page.
It doesn't mention SRC param but I conclude that it means that it
won't load any URL or SRC 'coz that means it's data outside of the
actual page. I haven't tested with the new (broken) browser. So
please, if someone has a test machine or doesn't mind installing this
new (broken) ie6 and testing please let us know!
So, after reading docs from Apple and Macromedia which suggest using
THE ONLY WAY TO WORK AROUND the new ie6 limitations. unless you want
to attempt to encode the data directly into the web page, which for
obvious reasons, not many people are going to do.