There are a number of different ways that crops can be made including custom rectangle cropping via pixel or percentage values, provided as url string parameters. The face zoom crop is just an additional feature to save some steps for these kinds of scenarios. Ideally this feature can be built into an application providing a user with a suggested face crop, and then allow a to use the alternate custom crop that access a different set of parameters via imgix. imgix is an on demand dynamic api for these operations.
I hate to be all self promotion, but this is why imgix exists as a service. We aren't running gm or imagemagick. One of our statements is that "this cannot be built in a weekend" as many engineers are quick to claim how easy an implementation it is when coming across our service.
It is possible to easily target thr picture element using imgix's URL API directly. However, with picture you are limited to a set of image sizes and predefined dprs. This library allows the containing element to recieve an image at any size necessary with any DPR multiplier (up to 5, I believe) with the added bonus of conditional image manipulation overrides. In the example, we are baking in textual image information. Other edits like image quality and sharpening or midtone adjustments could be conditionally set as the image crops larger or smaller.
What is your definition of imaging? Our use of imaging is in reference to imaging in technology. "The production of graphic images from digitally generated data." Our service processes images on our servers and produces new image data with each request when necessary (if not cached already.) The Javascript library is just a way to interface with our infrastructure and generate these requests.
There is nothing stopping you from setting the src tag. But you are just adding another request. Our base service works perfectly with src set and picturefill. This library is for cases where a different result is desired.
Why isn't there an img-tag in the default example? Why are you promoting bad practice by not having images in img-tags? You solved one problem but created a much bigger problem. Bots, screen readers and non-javascript client should see an image, not a div with some attributes.
They're welcome to target whichever type of users they want to - it's 2014, most average internet users have javascript enabled. Besides, you can add a title/aria-* attribute for bots and screenreaders (perhaps not semantically correct but gets the job done).
