On 8/22/23 12:00, Keith Moore wrote: > On 8/22/23 12:35, Marc Petit-Huguenin wrote: > >> I am not saying that we should not have HTML in email, quite the opposite: Without it how would I be able to know which email are not worth my time? > I tend to judge competence by people's words more than by the specific tools they use. I mean, sure, I probably do respect an emacs user more than a vi user ( :) ) but I also recognize that there are competent individuals who have valuable ideas to contribute, who don't use the same tools that I prefer. > > Specifically, I don't find that use of plain text without HTML is a reliable indicator of competence, or that use of HTML is a reliable indicator of less competence. And I'm very much in favor of IETF being open to effective participation to anyone who is competent enough to contribute usefully (and even try to be tolerant of those who are behind the curve). So I think effective IETF participation needs to be open to users of a wide variety of MUAs and email providers. I also think that, at least in the near term, trying to convince every IETF participant to use either plain text or AsciiDoc or Markdown to the exclusion of HTML, will be a difficult sell. If we want people to use a special tool set for IETF, we need to demonstrate to them that it's really worth everyone using those tools. > This is not about competency. I read my incoming emails exclusively as text, which can in some cases be a conversion from HTML. If that result is ineligible or empty, I am not going to try to look at the HTML because I found that people who do not care about it's legibility as plain text correlates with people I am not interested in reading. There is very competent marketing people out there, but thanks to their exclusive usage of HTML I do not have to look at their emails. > [I still have this idea that people should be able to submit internet-drafts in HTML, such as can be produced by any word processor these days, with a few hacks to include the necessary metadata, and a few heuristics to allow good quality xml2rfc to be reliably produced from the HTML source input. If at some point down the line the xml2rfc becomes the source document, that's not the end of the world. But it should be *easy* to submit internet-drafts, far easier than it currently is. Similarly, it should be easy to effectively participate in IETF email discussions.] I think it should be the other way around. The superiority of AsciiDoc over HTML is that it is legible *without* a program to decode it. But AsciiDoc can be converted into HTML (and PDF. and DocBook. And EBook. And slides). So instead of having to badly convert HTML to plain text, the mail client can convert AsciiDoc to HTML for people who like their emails nicely presented, and do nothing for people who do not need that. As for graphics, AsciiDoc supports descriptive diagrams, with the integration of PlantUML, Mermaid, Ditaa and so on. The text version contains the description of the diagrams, and the mailer converts that into images when displaying HTML. The best of both worlds, instead of the worse of both. I wish I had the time to write a Thunderbird add-ons to demonstrate that. -- Marc Petit-Huguenin Email: marc@xxxxxxxxxxxxxxxxxx Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
