fractalnavel

things i had to do to make mozilla behavior binding work with my old htc's:

• added the -moz-binding properties to my css (as per the article)
• move the implementation script into the interface xml (as per the article)
• add commented cdata wrapper to the script (as per the article)
• removed the urlscan isapi filter from iis.  this seemed to have been preventing the ability of xmlhttprequest to access an htc file.
• add xmlns:public="[bullshit]" to the root element.  the absence of a namespace declaration was causing the xml not to parse.
• add get/put functions & references for properties previously only exposed as fields.  the xbl wrapper doesn't handle fields.
• work around "sourceindex" usage.  this is an ie-only thing in my earlier implementation, used as an index in document.all().
• work around #text nodes.  this is a mozilla thing not seen in an ie-only implementation.
• work around a dynamically attached handler.  onpropertychange seemed not to work.

note that there only needs to be one moz-behaviors.xml file and that this can be referenced by absolute or relative paths in the bindings.xml file(s).  the latter, however, must exist in the same location as the htc's that it's used to reference, since the wrapper parses the css -moz-binding url(...) value to come up with the location of the htc.

while i was at all this, i noticed that community server was modifying the contents of script tags used in the blog news setting.  it was escaping quotes - !  yuk.  so then i moved that script into a separate file, and sure enough ran into racing conditions.  *sigh*

got all that figured out.  pain in the ass, let me tell ya, when all these different - and different kinds of - issues are happpening all at once.

another thing i noticed early on was that some sort of severe error was causing the elements referenced by the bindings not to render at all.  i don't have this pinned down quite yet as to exactly what sort of breakage does this.  maybe it was the urlscan return...

anywho, that was htc #1.  got a bunch more to go, and then, even worse, a shitload of javascript to remedy.  one lesson learned: debugging usage with an app only hosted remotely just intensified the pain.  silly me.

why go through all this ?  i dunno; ... "why not" ?  not good enough, given all the new tech.  and then there's the server side stuff that can be done.  bottom line is that this has been a bit of a thorn for years, and i just wanted to see if it could be done, and how painful it would be if it could.

as for the ie / ff debate, well, everyone's shit is broke, in one way or another.  and there's good points on both sides too.  the discriminator is market share.  if i'm going to code for only one thing, better make it the biggest thing out there.  what do we really gain from having more than one browser or other technology ?  don't we share the same roads, the same internet ?

and on that final note, i heard someone saying their employer doesn't want them using soap - !  (beware the intentionally ambiguous here)

gonads.

more:

---

From: service@laptopgiving.org
Sent: 2008.01.24 02:30:26 Eastern Standard Time
Subj: Your XO Laptop

Dear Donor,

We wrote you several days ago to let you know that your donation is in our shipping queue for the shipment of your XO laptop.

We are awaiting the arrival of new inventory so that we may ship your laptop to you. We will send you another update in the next few days when we have specific shipping information.

We appreciate your generosity and patience.

Sincerely,

OLPC Donor Services

kind of what i thought.  not a problem.  shouldn't the kids come first anyway ?