Hacker News new | ask | show | jobs
by TazeTSchnitzel 3566 days ago
This is mostly a distraction, but I still wish text/enriched had won instead of HTML email: https://en.wikipedia.org/wiki/Enriched_text

If only because it's simpler, so it might have been more fully and consistently supported (and it's not a security nightmare).

3 comments

I was expecting something significantly different from HTML but this is really just pre-CSS HTML with different tags. At this point, I can't imagine another SGML based language for formatting is necessary.

If everyone could just agree on a safe subset of HTML for email then that's all we would need.

Thunderbird literally implements it by rewriting it into HTML: https://dxr.mozilla.org/comm-central/source/mailnews/mime/sr...

text/enriched was basically proposed as an interim result for richer text than plain text back when HTML email was controversial.

There is a more-or-less defunct community group at the W3C about building an HTML email specification. In practice, the elephant in the room remains Outlook, which uses the same HTML engine built into MS Word, which, IIRC, is built on IE 5.5.

Unlike HTML, the the syntax is minimal and trivial to parse (there's no attributes or implicitly-closed tags, and there's only a single character entity (<<)), and it's limited to a very small set of clearly-defined formatting options.

In lacking most of HTML's complexity and features, it lacks its security issues, too. And in being very small, you can reasonably expect the whole spec to be implemented.

But yes, with a very strictly validated, very small HTML subset you could get a similar effect. At that point, though, why use HTML?

Regarding the example in the Wiki page: Is it possible to use hex colors codes or rgb color codes? The example uses color name.
It is indeed!

     Color
          causes the affected text to be displayed in a specified
          color. The "color" command requires a parameter that is
          specified by using the "param" command. The parameter
          data can be one of the following:

               red
               blue
               green
               yellow
               cyan
               magenta
               black
               white

          or an RGB color value in the form:

               ####,####,####

          where '#' is a hexadecimal digit '0' through '9', 'A'
          through 'F', or 'a' through 'f'. The three 4-digit
          hexadecimal values are the RGB values for red, green, and
          blue respectively, where each component is expressed as
          an unsigned value between 0 (0000) and 65535 (FFFF). The
          default color for the message is unspecified, though
          black is a common choice in many environments. When
          nested, the inner "color" command takes precedence.
(https://tools.ietf.org/html/rfc1896#page-5)

Odd that it's 96bpp colour, of all things.

In fact, you have even more options, not just two:

1) RGB: #rrggbb (rgb hex) / rgb(r,g,b) (rgb int 0-255) / rgba(r,g,b,a) (as before, plus alpha). In addition, rgb/rgba support percentage values instead of 0-255.

2) red (color names)

3) hsl(h,s,l)

4) cmyk(c,m,y,k)

For compatibility with anything except Thunderbird (which supports all four formats IIRC), stick with #rrggbb or plaintext names. Webmailers are especially prone to filtering by regex (ugh), and stripping out everything they don't know.

I'm not seeing that on the text/enriched spec? You might be thinking of HTML email.
I'm writing a text-rendered board games by email service and this would have been a perfect format for me. If only.