4 ms·

What is needing then, is adding the "type" attribute in <plaintext> command, that browsers with their own implementation can optionally use it instead in order

What is needing then, is adding the "type" attribute in <plaintext> command, that browsers with their own implementation can optionally use it instead in order to render with the user's settings if desired. However, that still forces you to serve HTML, so it is not good. My idea is adding a "Interpreter" response header, which indicates which files can be used to render files (documents, audio, video, pictures, etc) that the client implementation does not understand already. The end user can also specify their own overrides, if desired.

chrismorgan 4y ago
Fun related fact people may not be aware of: you can do basically this with arbitrary XML files, defining a stylesheet which transforms the XML into HTML however you like using XSLT. As an example, Atom feeds on my website (such as <https://chrismorgan.info/blog/tags/meta/feed.xml https://chrismorgan.info/blog/tags/meta/feed.xml>) render just fine in all mainstream browsers, thanks to this processing instruction at the start of the file: <?xml-stylesheet type="text/xsl" href="/atom.xsl"?> (Mind you, XML is hard to work with in browsers, because it’s been only minimally maintained for the last twenty or so years. Error handling is atrocious (e.g. largely not giving you any stack trace or equivalent, or emitting errors only to stdout), documentation is lousy, some features you’d have expected from what the specs say are simply unsupported, and there are behavioural bugs all over the place, e.g. in Firefox loading any of my feeds that also fetch resources from other origins will occasionally just hang, and you’ll have to reload the page to get it to render; and if you reload the page, you’ll have to close and reopen the dev tools for them to continue working.)