A subset of HTML is still unsuited to human editing. Even more so than full HTML, because it doesn’t have the justification of being a complex and extendable syntax. A superset of markdown would be much more usable, for people writing plaintext, than a subset of HTML. Especially if, as now, the majority of posts and comments require more or less only regular markdown and no superset features like tables.
Asciidoc might be an alternative when more power is needed. I haven’t used it, but ESR once said that it does markdown’s job better than Markdown itself.
HTML is wholly unsuited to human editing or even reading. I blame it for ruining email. Well, that and top-posting.
A subset of HTML is still unsuited to human editing.
People from the 90s would disagree and rich text editors can output whatever. Of course markdown is better for specifying minor formatting while you write the content—that’s what it was explicitly designed for. However the advantage of HMTL is ubiquity.
the majority of posts and comments require more or less only regular markdown
The majority of posts and comments use only links, bold/italics, and an occasional bulleted list. Inline images are culturally disapproved of and tables are rare. At this level pretty much anything would work.
I don’t get your point here. HTML’s ubiquity is important for display, not for editing. Markdown is converted to HTML for display. As a user I prefer writing in markdown to writing in HTML. Don’t you?
At this level pretty much anything would work.
That doesn’t mean anything would be equally as comfortable as anything else.
We are talking about the acceptable format for messages as they are processed and stored by the system, right? Ease of input is a separate issue and your editor can and should allow you to write in whatever way you find most comfortable.
The format for server-side processing and storage should be the input format unless there is specific cause not to use it (3.2). Conversion to display formats should be done client-side and as late as possible. HTML, as Dan says, is a display format.
(this distinction exists even for server-side clients, e.g. web clients)
The format for server-side processing and storage should be the input format
When you say “input” here you mean “what the client sends to the server”. When DanArmak is talking about input, he is talking about the user experience, ease of writing and editing. These are obviously not the same thing.
If all users input in the same format, then it should be the storage format too. Rendering to HTML can be done when it’s actually needed. (Plus or minus caching/prerendering for performance.)
If users can choose to input in different formats, and we can’t convert between these formats (e.g. from HTML to markdown), then I think it would be easiest to just store whatever the user originally input. The main reason for original-format storage is editing, and users normally edit only their own content, so they shouldn’t mind the format it’s in.
If I write in markdown, but my editor has to send HTML to the server, then it has to implement an HTML-to-markdown conversion for editing, which raises all kinds of issues (like supporting the HTML output of an old version of the editor, never mind of different editors) and trying to solve them just doesn’t seem worth the bother. What does adopting HTML as a storage format get you?
Contemporary HTML. On the other hand the original HTML (of the early 90s vintage) is a simple page description language designed to be hand-coded.
A well-defined limited subset of HTML would probably be easier to implement than some superset of markdown.
A subset of HTML is still unsuited to human editing. Even more so than full HTML, because it doesn’t have the justification of being a complex and extendable syntax. A superset of markdown would be much more usable, for people writing plaintext, than a subset of HTML. Especially if, as now, the majority of posts and comments require more or less only regular markdown and no superset features like tables.
Asciidoc might be an alternative when more power is needed. I haven’t used it, but ESR once said that it does markdown’s job better than Markdown itself.
HTML is wholly unsuited to human editing or even reading. I blame it for ruining email. Well, that and top-posting.
People from the 90s would disagree and rich text editors can output whatever. Of course markdown is better for specifying minor formatting while you write the content—that’s what it was explicitly designed for. However the advantage of HMTL is ubiquity.
The majority of posts and comments use only links, bold/italics, and an occasional bulleted list. Inline images are culturally disapproved of and tables are rare. At this level pretty much anything would work.
I don’t get your point here. HTML’s ubiquity is important for display, not for editing. Markdown is converted to HTML for display. As a user I prefer writing in markdown to writing in HTML. Don’t you?
That doesn’t mean anything would be equally as comfortable as anything else.
We are talking about the acceptable format for messages as they are processed and stored by the system, right? Ease of input is a separate issue and your editor can and should allow you to write in whatever way you find most comfortable.
The format for server-side processing and storage should be the input format unless there is specific cause not to use it (3.2). Conversion to display formats should be done client-side and as late as possible. HTML, as Dan says, is a display format.
(this distinction exists even for server-side clients, e.g. web clients)
When you say “input” here you mean “what the client sends to the server”. When DanArmak is talking about input, he is talking about the user experience, ease of writing and editing. These are obviously not the same thing.
It is, now. When designed, it wasn’t.
If all users input in the same format, then it should be the storage format too. Rendering to HTML can be done when it’s actually needed. (Plus or minus caching/prerendering for performance.)
If users can choose to input in different formats, and we can’t convert between these formats (e.g. from HTML to markdown), then I think it would be easiest to just store whatever the user originally input. The main reason for original-format storage is editing, and users normally edit only their own content, so they shouldn’t mind the format it’s in.
If I write in markdown, but my editor has to send HTML to the server, then it has to implement an HTML-to-markdown conversion for editing, which raises all kinds of issues (like supporting the HTML output of an old version of the editor, never mind of different editors) and trying to solve them just doesn’t seem worth the bother. What does adopting HTML as a storage format get you?