http://dillerdesign.com/experiment/animate_to_moving_target/test.html

I nabbed a pair of these with some of the donations to the DD_* JS projects:

http://barmitts.com/

They look silly, but wow, they WORK.  Pretty much anything that successfully keeps you warm looks silly.  I can go without any gloves at 40 F, some thin full finger bike gloves at 32 F.  For colder stuff, I wear winter gloves, and my hands stay absolutely pleased.

Then my next week happened.  Holy crap.  The changes I’d made fixed some specific, repeated complaints various folks have left here, but it caused more harm then good.

After that happened, I straight up got burnt out.  This isn’t live journal, so I’ll keep the emo reasons out.

I find myself spending more time coding lately.  During the summer, I literally did no programming outside of work.  No freelancing, no fun coding, I basically became a “just a paycheck” programmer.  Spent time outside doing fun stuff.

The months are cold again, I find myself indoors.  A freelance gig I picked up is providing for a short term challenge, and it’s pretty fun programming.

I have motivation for this again.  A few projects to square away first.  So, library updates will happen.  Some problems aren’t solvable, as I learned earlier when I abandoned hope.  If I can’t fix them, I will strive to post guidelines / workarounds.

…

Heh, when venting to a guy at work about this, citing gripes like people who send me stupifying email, he joked, “Maybe they should ask for their money back.”  Well, a lot of people _have_ donated money, and you have my continued thanks.  I am putting it toward my bicycle winter-ization.

One bug was that disabled form fields don’t fire _any_ event at all, ever.  Even onreadystatechange, it doesn’t fire on an element that you set to disabled=true.  I changed where the VML gets inserted… which has a few ramifications I’ll cover later.

Second, I stumbled upon a solution for the problem where a roundified link ends up only being clickable on the actual text of the link (clicks wouldn’t register on the padding around the text, if it existed).  I _think_ the almost-ready code will handle the problem by itself, but it needs some testing before I go ahead and call it a fact.

With that in mind, if you’ve found a problem with either DD_roundies or DD_belatedPNG (there are many), don’t email me code snippets or anecdotes. I want a full example of the malign behavior you’re seeing, in the form of a URL or an archive (.zip, .rar, .tgz, your preference).

I try to answer all email promptly and thoughtfully, but the volume has gotten to be a bit too much to manage.

To those of you who ask, “Does belatedPNG support background-repeat?” – don’t be that guy, read the docs, see the examples, or try it yourself.

To those of you who report bugs found in some online testing suite (such as BrowserShots) or multiple-IE-versions type software, I am plainly uninterested.  I use VirtualBox with a Windows guest, and have found that approach to be very accurate.

Over email, I’ve answered inquiries about this with nothing better than using a pixel GIF workaround and moving the PNG image visibility to the parent as a background image.  Lame.

I’ve decided that 0.0.9a will simply copy all events bound to any fixed IMG nodes to the resulting visible VML, and will modify them slightly so that they fire in the scope of the IMG node as intended.  I estimate that will get around that catch-22.   One can hope, anyway.

http://dillerdesign.com/experiment/DD_belatedPNG/#release0.0.8a

AND IT ONLY TOOK ME HALF A YEAR.  (Not really.)

I’m sure I missed credits for people.  Let me know.  Way too much email for me to keep up with.

DD_roundies 0.0.3 will feature two new methods:

• DD_roundies.removeVML( HtmlDomElement );
• DD_roundies.rerender( HtmlDomElement );

The former would be used if you wanted to un-roundify an explicit DOM node that you provide as the single argument to the method.

The latter would be used (same argument as the former) if the onpropertychange events didn’t catch all the changes that you intended to see, and you want to start the whole process of evaluating appearance and location over again.  It is also useful for roundifying elements after cloning an element, which hasn’t been working correctly up to this point.

Today, I found out the hard way that DD_roundies (and by inference, I suspect DD_belatedPNG as well) really hates HTTPS traffic and will cause ‘operation aborted’ errors in some cases (even though I’m NOT doing an appendChild to an unfinished element).  I conjured a solution, nonsensical as it may be… I suppose that is fitting, given that the PNG lib in particular is nonsense to begin with.

Anyway, I’m looking for some feedback, on one idea in particular: both libs require the silent addition of invisible image elements to a given page to determine the sizes of all images that get applied to VML elements.  I, and pretty much anyone who has used DD_belatedPNG to a great degree, have noticed significant initial page load lagging when using that lib.  I suspect it is in part because of the addition of the above mentioned “size-finding” images.

How would you feel about the lib requiring you to add an object literal that would inform the lib of how big the image sizes are… sort of like a configuration object?

This would enable me to skip the whole size-finding bit.  However, it sounds like a pain in the butt.  A compromise: if no config object is detected, the lib runs the size-finding bit once, and spits out a config object in form of some javascript code that can be copied out of a textarea.

Even if it doesn’t save much CPU time, it would at least prevent the need to download a given image twice just to display it once.