Re: M$ REALLY sucks

>Looks like Zeldman isn't sure the proposed fixes will be sufficient:
><http://www.zeldman.com/daily/0903c.shtml#eolasfallout>
>

**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
alternative to using javascript to write the <object> tag):

"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
remote data.

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
property.
<OBJECT NOEXTERNALDATA="true"
CLASSID="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6">
<PARAM
NAME="URL"

VALUE="http://msdn.microsoft.com/workshop/samples/author/dhtml/media/drums.wav"/>
</OBJECT> "

++

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 javascript write-around, I conclude that the javascript method IS
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.




<twhid>
http://www.mteww.com
</twhid>

Comments

, Jack Stenner

On Wednesday, October 8, 2003, at 12:01 PM, t.whid wrote:

> So, after reading docs from Apple and Macromedia which suggest using
> the javascript write-around, I conclude that the javascript method IS
> 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.
>

I think you're right. At *this* point that is the only acceptable
solution. I think Zeldman's suggestion is that it might not be a good
idea to run around modifying all your websites (and from his
perspective, stirring up clients) until the "dust settles." Just
because M$ says this is an acceptable work-around does not mean that
Eolas will agree. It could be a waste of energy to modify a *bunch* of
sites, only to have to do it again when an alternative solution is
aGREED upon.

Jack