bridgy
bridgy copied to clipboard
snarfed
responsive images with srcset
If I use responsive images with srcset, and the fallback, original image for src, that small image is the one that gets pushed to the silos.
Would it be possible to parse srcsets and picture source sets? It might soon be needed.
Some discussion on IRC: http://indiewebcamp.com/irc/2016-01-07#t1452160368618
This is definitely an interesting question. We'll need at minimum some way to distinguish "different resolutions of the same image" from "multiple images in the same post" in the parsed mf2.
I recently got myself a DSLR camera which takes big pictures. I was planning on doing this the other way round when I add some of the photos to my blog.
That is <img src="large_image_from_camera.jpg" srcset="{processed smaller images}">
If I do this it seems bridgy will try and POSSE the larger image. I assume currently bridgy will just fail if the image is too big for Twitter’s media API endpoint? (which my SLR pictures probably will be)
cool! yes, that's true. Twitter's size limit is 5MB, fwiw.
I've never worked with srcset before, and https://indieweb.org/srcset is a bit intimidating. i expect we'd need to HEAD all of the images and pick the one with the largest Content-Length under 5MB?
I'd happily accept a PR for this if you're interested! the first step would be to figure out (maybe with #indieweb-dev/#microformats) if and how to extract all images in a srcset into parsed mf2, since bridgy and granary convert HTML to mf2 pretty early in their code paths.
In the spirit of keeping things simple I’d have bridgy HEAD request the image linked to in src, if that can be POSSE’d then just abuse that. Even if a “better” valid image exists, in the srcset.
Then maybe we could reuse the code and do a head request even if there’s just a single conventional src and if we see the image is over 5MB not even bother hitting Twitter’s API (would save bandwidth)
(p.s. does Facebook have a photo size limit?)
I can’t edit on mobile it seems, obviously abuse should be use in the above comment.
sure! HEADing to check for size is easy. not all servers support it, sadly, but that's a separate question.
the main question here still seems whether and how to get the srcset's image URLs into the parsed mf2 that bridgy and granary use internally. that'd be great to investigate if you have time!
re facebook, i don't see a photo size limit in https://developers.facebook.com/docs/graph-api/reference/user/photos/#Creating
No longer blocked on mf2py, @angelogladding shipped this just now in v2.0.1!