On Wed, 20 Sep 2006 16:23:46 EDT, Todd Vierling said:
Which is just one of the reasons that the MIME type "multipart/alternative" exists. Sane MUAs that wish to send HTML also send a text/plain alternative segment in the same MIME stream.
Vernon Schreyer made a very good point years ago that multipart/alternative is fundementally busticated, because there's two options: Option 1: The actual information content of both the text/plain and text/html is identical. Sending the html is therefor superflous. Option 2: There is added crucial semantic content in the HTML (links, table formatting, etc) that is not representable in the text/plain. At that point, sending the text/plain is *also* incorrect, as it allows the receiving MUA to punt and provide an incomplete and incorrect version of the information. Sending just the text/html and requiring the receiving MUA to do the downgrading with more precise knowledge of the exact non-representable brain damage is the correct behavior here (for instance, some MUAs are able to provide clickable links after filtering to text/plain, but unable to do proper table alignment). Similar ideas are included in RFC4141, where the receiving end provides info on what can/cant be displayed. In either case, sending both plain and html versions is boneheaded and wrong. :)