- From: Alex Russell <notifications@github.com>
- Date: Tue, 07 May 2019 10:08:39 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/350/490167198@github.com>
There seem to be 2 separate questions around transcoding in my mind, and neither seem to have been answered to my satisfaction: 1. Why do we need to do this at all given that the same risks are exposed by file download, which we also allow on arbitrary user activation? 2. What controls (if any) does the developer have over transcode quality? The first one seems to be the more urgent to answer. If we don't need to transcode, @annevk's concern doesn't apply (not withstanding its overstatement; we've moved out of the era of closed-source browsers; you don't need to reverse engineer anything; just read some code). As to the second, this gets to a question of layering. A well-layered web platform feature builds on an ever-shrinking set of primitive operations. We have some image transcoding operations in `<canvas>` today, and the API should either be expressed in terms of them (although, again, these APIs are poorly layered and don't expose near enough developer control over encoding parameters) or, better, an off-thread-friendly, streams-based codec API whose parameters would enable developers to configure the various quality knobs and dials that are essential to make this API more than a toy for users of professional creative apps. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/350#issuecomment-490167198
Received on Tuesday, 7 May 2019 17:09:01 UTC