3 ms·
This is on purpose, because otherwise it would lead to proliferation of redundant, potentially crappy and insecure formats on the Web. You could end up with si
by pornel 4y ago
This is on purpose, because otherwise it would lead to proliferation of redundant, potentially crappy and insecure formats on the Web.
You could end up with sites using some Windows-only formats (e.g. some internal MS Office format), iPhone-centric sites would serve patented HEIC, and then browsers on other platforms would be forced to adopt these formats.
Not every plugin dumped in the local OS is as hardened as web-facing codecs. People would likely get pwned through some legacy fax codec from their scanner software.
Users seeing broken images is not a good UX, and users installing random code-running plugins, because websites tell them to, is even more annoying and dangerous.
We've got decades of experience, and scars in the User-Agent header, showing that developers can't be trusted to make sensible technical choices.
- snvzz 4y ago>This is on purpose, because otherwise it would lead to proliferation of redundant, potentially crappy and insecure formats on the Web. In a well-designed datatype system, an image datatype would, for decoding take a compressed image and return a decompressed image. Possibly with streaming support. It would not be able to do anything else, not having capabilities to anything else than necessary.