Lightweight Markup Languages

"On a programming website it is entirely possible
that someone might want to actually post some HTML
or XML. Or even run into issues with code in other
languages: e.g. "if (ab) "

True. So you have to be able to turn HTML off. Preferably, you should be able to turn it on if you want it.

"On the other hand, the only thing people really *need* is links."

"I would have thought that on a programming website
the only thing people need is the ability to post
their example source code without it getting mangled."

I'm getting pedantic here, but given a choice between posting code with no links allowed, versus posting links to code plus whatever other links I want, I'd take the second.

But there's no reason to face that choice so it's silly of me to argue which is more important.

Whatever you do, make it easy for users.

HTML is too much typing.

Stuff people have to look up is no good either.

On the other hand, the only thing people really *need* is links. Everything else they can do without if they can't figure out how to do it. If I *really* want some bold text, I'll figure out how to do it or maybe put it in CAPS or whatever. If it isn't worth finding out how to do it then I don't need it.

So if you want to make it easy for users enough to do some extra work, then:

1. Allow limited HTML, not enough to be easy to break things but enough to provide the formatting you want.

2. Allow something like Markup, notably *bold* _italics_

* bullets

And a few others. Many of these are things people were using for emphasis before.

3. Put a toolbar on your online editor that does stuff.

The more ways that work, the larger will be the minority of your users that are satisfied. Provided the different approaches don't get in each other's way. Nobody will use HTML by accident and nobody will use a toolbar by accident, so those are two good complementary approaches. I doubt Markup would be much trouble either.

Speaking for myself, Markup is best for every Markup command I remember, because it's a keystroke or two in the middle of my typing. No stopping for a mouse, and less bother than HTML. But of course people who already know HTML and don't know any Markup will find it harder. No doubt egyptian scribes who were used to hieroglyphics believed that was easier than writing in demotic.

I guess I should mention, I learned how to use Markdown in a few minutes without ever seeing its name or discussing it with anybody. Far far easier than HTML and easier to use too, though of course limited.

I'm not sure I approve of this idea that nobody should ever learn to do anything effective that's new. If we'd had this attitude and this technology when the automobile was invented, we'd probably all be driving cars now with reins. You turn by pulling one or the other, you brake by pulling both, you start up by shaking them, and the car would have voice recognition circuits to respond to Gee Haw Giddyup etc. You'd switch to high gear by kicking a spot below the saddle.

So anyway, HTML should be fine provided you can turn it off. Or better yet, have it off by default and you can turn it on. So people won't write OVER IF EXIT THEN and find out they were writing HTML and didn't know it.

Harley, I think I got what you're saying but let me spell it out at great length to make sure.

If I put malicious HTML into a message then it potentially affects everybody who sees it. So the server side has to be carefully written so it allows proper HTML but erases all malicious HTML. Anything that gets past the special server code will affect all users.

You're talking like there's no way for the server to cooperate with users who don't want that to happen and who don't fully trust the server to stop it, who would rather simply have HTML disabled in messages sent to them.

Isn't this starting to sound like a traditional problem? We have a powerful system, and then we want to let random users use some of the power, but we can't trust all of them to use it wisely. And the least trustworthy of them are good at wiggling past the safeguards we set up to stop them. Lots of complexity for a zero-sum game, where we try to provide good power but not bad power to everybody and the bad guys try to find ways to abuse it....

Are people saying that the problem with HTML is that no matter how you try you can't keep people from writing malicious HTML code that will annoy or damage other users?

If so, then you could let users turn off HTML or take their chances. And if they have HTML turned off but some other markup language turned on, then it would be good to translate a limited set of HTML to the other markup language. The malicious code that doesn't translate could be ignored or left intact for readers to puzzle over.

It makes some sense to allow a subset of HTML for people who want it, since they want it so much. But I'm starting to wonder -- people who won't spend 30 seconds to find out how to do things but insist that the layout be arranged in a complex inefficient pattern to suit what they're already used to -- would people like that actually be an asset?

Won't they tend to be the sort who do everything they can to delay progress? "We don't need any new programming languages because all real programmers already know C." Etc.

"I agree that HTML is not ideal but the best of a bad lot. The problem with all the other alternatives, nice as some of them are, is that none of them is a standard."

If HTML gave you a standard that let people do markup (bold, emphasis, maybe tabs, maybe headers, links, and code that isn't affected by the above) and didn't let people do weird malicious stuff, then this would be a different discussion.

We'd be talking about what we preferred, and developers would try to provide as many of our preferences as they reasonably could and let us choose among those. So you could have a menu: HTML Markdown Wikipedia BBCode Textile WYSIWYG vi Wordpad Applewriter. Pick your poison. Sheer personal preference, and they provide what they can.

But HTML is dangerous, and the question is how to reduce the danger. The consensus is to white out everything except a small subset of HTML that you want users to have. Another approach is to spike the guns -- turn other HTML code into something that displays and isn't executed, and people can see whether they think it's malicious. But then it looks ugly and people who cut-and-paste it might convert it back into a dangerous form. (If programmers can post sample HTML code that doesn't get executed, which we might want to do, that could also get executed later by people who copy it.)

If you don't give users direct access to HTML, that's easier and safer than trying to take it away from them after they use it.

So, if there's no direct access to HTML the choices are to provide plaintext (which is good enough for me, but some readers will go elsewhere). Or provide one or more lightweight editors like Markdown. Or maybe also provide WYSIWYG. The original author said he wouldn't do that last. Apparently he wanted to weed out people who insisted on markup but who weren't willing to use a markup language. It's one way to weed out users. If he only wanted people who knew cryptography he could require users to solve a simple cryptogram before they posted. Like that.

So, the way you get a standard is you provide the best mix of features in your opinion, and over time people will tend to agree about what should always be provided, and they'll get together and make a standard. Make your standard too early and it will standardise the wrong things. Make it too late and everybody already knows what they need. If it isn't time yet for a standard, why go with an HTML standard that doesn't fit the need?