search

podpass / spec

12 stars 0 forks source link

specify image dimensions and format clearly #3

Open cqr opened 5 years ago

shahruz commented 5 years ago

Not sure if this is the right issue for it, but it'd be great if there were certain basic standards / restrictions applied for content resources attached to Podpass supporting feeds.

Requiring https links for images and audio seems like an easy one considering how quickly web browser are starting to make it the new standard, and warning users when insecure content is loaded.

It also might be good to have max image size limitations. One example I can think of is Armchair Expert (a top #50 overall podcast generally), which has 3000x3000 (2-4mb) images per episode. Since no client ever displays images at a resolution that big, I believe it's because the show uploader just wants to have a high quality image, and isn't necessarily considering the bandwidth costs for their hosts and their consumers. Ideally it'd be the host services that would offer guidance on stuff like this, but figured it's worth mentioning here too.

cqr commented 5 years ago

I'm hesitant to make any declarations about things that you might have a hard time arguing are related, but you raise a good point which is that, yes, enclosures, feeds, and images should all be served over TLS. I will file an issue for that now

cqr commented 5 years ago

Most common feedback I received is that the icons referenced in the spec should be specified as square aspect ratio SVGs.

mahemoff commented 5 years ago

Square seems like the most flexible ratio for app developers to build responsive app UIs. And should also be easier for publishers who can reuse - with some optional tweaks - existing artwork.

I am one of those who mentioned SVG, but on reflection, it's not really a suitable format for bitmaps (you can embed bitmaps in SVG, but it may as well be a bitmap if that's all you're doing). So PNG is possibly better if only one format is to be specified.

A modern format like WebP is also possible, but I'd rather see the spec optimise for broad compatibility (thinking also about tooling such as graphic editors and publishing tools) at the expense of transporting and storing a few more bytes.