Ping me when there is something test

You bet I will. Thanks..

I've got v0.1 tagged in the repo. I'm curious to see how it works with another project, so if you care to test it out it's ready to be kicked around.

Issues
jquery.lazyload.js is licensed under MIT, this violates d.o. policies on code inclusion, please utilize https://drupal.org/project/libraries API instead for remote inclusion.
Then go to https://drupal.org/project/drupalorg_whitelist and request inclusion in the packaging whitelist. This will keep the legal experts happy

The next potential issue is that you are adding a .lazy class via array_push($element['content']['lazyload']['#attributes']['class'], 'lazy');
This is assuming from a screen-reader's perspective that all images are worthless and therefore potentially will not be rendered for those with a screenreader as they ignore display:none. A better pactice is to use the drupal core included element-invisible class which uses an approved clip method for hiding material. You can read more about it here -- http://zufelt.ca/blog/drupal-7-two-new-system-classes-improve-accessibility

Another critique is the use of js/css inclusion in the .info file which too throw it on all requests. Instead, include css / js via hook_page_build https://twitter.com/davereid/status/294554866649542657 to avoid inclusion at times when its not needed. You could also bootstrap it in only when the media field is included which probably would be even more optimal so we aren't assuming it's always in scope and loading js that's unneeded (also the css probably can go away based on the other recommendation).

Lastly, there are a ton of modules that provide lazyload support, what's this adding that's different enough to justify project status?

• https://drupal.org/project/lazyloader appears to work on all images uploaded via file upload fields.
• https://drupal.org/project/lazyloader_filter should be able to pick up things embedded via media as the input filter allows for working with ALL types of imgages no matter where they are embedded from so long as it is in filterable content.

I go off of the language on https://drupal.org/project/drupalorg_whitelist which then means that https://drupal.org/node/422996 conflicts with it at some level. That's not a major issue tho so let's debate this on twitter instead of filling up this applicants queue ;)

First off, I have no idea how anybody even found this project. This was just a very specific piece for a project I'm building at work and I figured I'd put it in a sandbox here instead of Github. I guess I'm confused about what d.o sandboxes are. I thought it was just a little semi-private area to kick around some ideas without having to worry too much about making my code too "nice", since this isn't intended for public release.

To your points -

I'm well aware of the GPL and of sites/all/libraries. If I ever want to make this into a full fledged project, it'll conform. Sounds like it might already, though, and thanks for posting that debate here so I can stay on top of it.

I'll look into the accessibility issue, but as I understand it, since one of the things that the javascript does is set the display property on the image to "inline", screenreaders wouldn't have an issue with that, since style properties on element tags take precedence over the CSS. If JS is disabled, there's a <noscript> fallback for the image - one of the points of this module.

Regarding the .info file - this issue would really only apply if JS aggregation were off. Otherwise it gets compiled into the main site JS file like all the other JS files. The alternative is to make sure that this JS only loads on applicable pages, which would require a different aggregated JS file to be generated and served on those pages. The cost of this procedure and network call vs. serving the first aggregated JS file out of the browser cache is what makes this a debatable performance enhancement to me. I was deliberately voting for the browser cache in doing that.

Lastly, this lazyloader has a <noscript> fallback, which none of the others have. This also applies only to the media filter, and not file fields.

And like I said, I haven't applied for project status, so while I appreciate the feedback I'd more expect to get that kind of analysis if I were applying.