DJ Capelis

@djcapelis @0xabad1dea Plex/ffmpeg dev here; those answers really are the most reasonable you can have for the question

@djcapelis @0xabad1dea canPlayType's problem isn't its return values being strange; it's the concept of asking such a vague question

@11rcombs @0xabad1dea You'd think the return values mighta tipped them off to that—and yet, here we are.

@djcapelis @0xabad1dea things might've been better if they'd returned true/false and always assumed not enough information means false

@djcapelis @0xabad1dea I mean, you never really have enough information but you can make a decent educated guess from a few things

@djcapelis also, the parameter string being awkward as hell and nearly undocumented doesn't help

@11rcombs among other issues. This should never have shipped.

@djcapelis yeah anything that takes "video/mp4" and gives even a "half-hearted" affirmative answer is definitely batshit

@djcapelis @antumbral surprised that whoever worked on HTMLMediaElement didn't add "idk" and "who_cares_we_are_all_gonna_be_dead_in_the_end"

@michielsikma @djcapelis i still don't understand what problem canPlayType solved in the first place or what problem it solves now :-(

@antumbral @djcapelis like a type can be h.264 but then the file contains 10-bit color range which some browsers probably can't play

@michielsikma @djcapelis I guess this could predate keepalive so the idea of just fetching the header of every file is infeasible

@antumbral @michielsikma @djcapelis I reeeeaaaally don't think HTML5 video can possibly predate HTTP/1.1 keepalive

@nicolas09F9 @michielsikma @djcapelis html audio tags are really old though

@antumbral @michielsikma @djcapelis Firefox 3.5 (June 2009) added <audio>. HTTP 1.1 (June 1999) treats connections as keepalive by default.

@nicolas09F9 yes, but html audio predates <audio>.

@djcapelis @tha_rami why doesn't it return "no" if it's sure it can't?

@djcapelis @0xabad1dea A missed opportunity to make the last return value "¯\_(ツ)_/¯"