On Sat, Jul 28, 2012 at 12:18 AM, Justin Dolske <dol...@mozilla.com> wrote: > I'd want to think carefully about doing so, in the name of web > compatibility... Ending up with a plethora of image formats with varying > degrees of support isn't a state we'd want to end up in. Video is a prime > example of this: codec packs for downloaded media, the obvious history of > HTML <video>, etc.
I think this is an important point. Format proliferation is something we should try to avoid. Legitimate additions to the set of image formats (or video formats or audio formats) supported by the Web Platform should be expected to be so rare and so well organized that efforts to experiment with new formats can reasonably be expected to involve compiling experimental builds of the whole browser from source and patch the experimental stuff in. Making it easy to add image formats using browser extensions to builds supplied by Mozilla has various downsides: * It makes it too easy to introduce new image formats, and introducing them shouldn't be easy in order to avoid format proliferation. Format proliferation is bad for interoperability [since new formats won't be supported immediately by all browser installations everywhere--including Firefox instances without the extension] and bad for the ongoing maintenance cost of browsers [if the format becomes popular, browser vendors will have to pick up the maintenance burden eventually as seen with PDF/PDF.js and swf/Shumway]. * It makes it easier for owners of proprietary formats to try to make Web content dependent on their patented stuff, because they can convert individual users into installing their proprietary viewer code, since each individual making the decision whether to install something knows that deciding to refuse probably won't make much difference to stop the spread of bad stuff. If purveyors of formats have to convince browser vendors instead, browser vendors at least have a better chance of making decisions that optimize the big picture. * If Web content actually start using the format, users who don't have the extension would have to install the extension, which is annoying, or may be unable to install the extension, because the extension is unavailable for the browser (including, potentially, some Mozilla products--it's conceivable for an extension to be available for Firefox for Windows and Mac while unavailable for e.g. B2G). Consider the dynamics of Flash Player availability. * If support for a new format is implemented in privileged code and users are trying to install random privileged code-extensions in order to see Web content, pretending to offer content in a format that requires an extension becomes a way to break users into installing malware. (Consider malware codec packs.) As for the specific case of JPEG 2000, even though it's needed for PDF.js, I think we shouldn't expose it to Web content in general. (I think it was a mistake to make the PDF format dependent on JPEG 2000, too.) I think JPEG 2000 doesn't deliver enough of an improvement over plain JPEG (in scenarios where visible compression artifacts are not okay; I concede that when visible compression artifacts are considered okay the artifacts of JPEG 2000 are less bad than the artifacts of old JPEG, but visible artifacts on that level are almost never considered acceptable by Web authors, so the issue is moot) to justify adding a new format to the Web Platform. (One of the supposed desirable features of JPEG 2000 is that if you decode only part of the file from the start and ignore the tail of the file, you can decode the image is smaller size. However, this feature doesn't really work in a useful way, because in order to decode one quarter of the pixels, i.e. width and height of the image held, you have treated half of the image data as opposed to one quarter of the image data. Thus, JPEG 2000 would be inappropriate as a solution to responsive images using a single file.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
