Better than HTML emails (you're choosing).

[BasSurf]

Dear Ideas space,
thank you firstly for providing this opportunity to share my (old, untold) idea, which I like to present in this manner, to actually explain better, which is what I do best. (No judgements, I'm bad at delivery, I get that all the time. I may be understanding my own emails.) Concisely, and somewhat correct;

I'm interested to know 'why you're (all) choosing for HTML'. (Worded a bit like a magician.) That will become apparent. (Because I have an alternative, you're looking at it.)

Also, an email with 5+ MB attachments can go separate ways; mail and upload to the [password access, user specific, per user/group] place of your choice (which it is all about; standard off, like internet addresses standard off for Firefox, separate idea, "just" security patches, but you get the drift), large attachments to a separate address (such as the local machine of the recipient itself, not in the inbox file but a local map). It also 'modifies the email I sent earlier', though you don't have to know that.

(Bare in mind please, these do look like separate ideas probably maybe deserving separate threads, I must not forget to mention, but it will become apparent when these all are part of one idea, actually 'better than HTML emails'. Though it's not an HTML vs plain text discussion, I'm just bad at show and tell.)

Makes the user specific receipt requests (not for everybody) also I bit easier.

# RespectMyPref (not a product, just space to improve)

Thank you for your indulgence and your patience. I think I've not, and I shouldn't, disrespected the rules for this platform which is connect.mozilla.org. Thank you for all goodies. Thank you and thanks again. This is all about technology and giving back.

[Jon]

Thanks for submitting an idea to the Mozilla Connect community! Your idea is now open to votes (aka kudos) and comments.

[BasSurf]

Thank you Jon. For the purpose of clarity, which is not my strong suit, my idea in its current form may be considered being an email, in plain text. (Even though it's in a specific standard font linked to this site, but no bold, italic e.a.) Because then, I can show you what I mean with "you're looking at it"; it hasn't rendered anything, because that is turned off, or just not enabled or turned on, as standard. How should it have been rendered, (for the purpose of better reading obviously,) well, that is defined in the footer. Where's the footer? Hidden. Or left behind at the server stage, before it reaches your inbox. That's the beauty of it. Always plain text, render instructions with minimal markup, easily cut off to never see, (not weaved in the message like HTML,) fully HTML feature capable, but less bandwidth and the necessity for senders to let their messages be conveying in plain text, to be clear.

That would be the best thing; if you want it, you enable it (or turn it on). And, enable just the bold, italic and underline and nothing else. Enable it just for specific senders. Standard off.

A footer would be something in the form like, a unique uncommon parse begin cue, and a parse end cue, like:

%^%mdb
p1w8 b  # so the 8th word in paragraph 1 would be rendered bold, but only if the recipient wants that
%^%mdb.  # that would be it

Which would stop the parsing of instructions. I think this presentation (in a second post/comment) would best illustrate the idea. Everything is subject for improvements or other views. You could also add a password/phrase (for each recipient, to access a specific folder), or filterword/tag, or key, a hash, in the footer to be found and parsed easily.

And as a contradicting instruction, inform all correspondences to not send you 'mdb' footers (Markdown B, Markdown was taken), with something like this:

%^%mdb
/\/mdb  # no markup, no HTML, just plain text please.. (reason being bandwidth/don't bother)
%^%mdb.

Though rendering Lilypond or abcm (simple code), or syntax highlighting code, would be useful:

%^%c  # syntax highlight this is you want
import math
function () {
}
%^%c.

You can define page size, font, margins as well for your  auntie, so she would just have to press the button Print. Should be something for the open source standards IMO, but you'll be the judge of that. I won't be programming (nor deciding anything of) the project, I lack seconds management.

%^%map
# geographical coords/directions
%^%map.

Etc.