Feeds

El Reg user forum opens to public, HTML for all (mostly)

Why we rejected BBCode

Site news As of now all commentards with five or more posts accepted for publication can create topics in our new El Reg forums. We have made this easier to find: the signpost link is in the secondary nav bar on the front page.

At the same time we've opened simple HTML formatting to all commentards who have had five posts accepted for publication. It takes up to one hour for the new permission to take effect.

You can play with <b>, <strong>, <em>, <i> and <strike>. We intend to add a few more formatting tools in due course. But the emphasis is on a few.

We have also enabled HTML linkage for all commentards who have had 100 or more posts accepted for publication. We have set the bar deliberately high to deter spammers as well as to reward long-standing active commentards. We'll revisit this figure at some point, but let's see how this pans out.

While testing our user forums, some commentards asked us why we plumped for HTML as opposed to BBCode. Here's why:

Executive summary

HTML is the open standard of the web. Deal with it, bitches.

Slightly longer answer

We’re a techie site. If you can’t handle using simple HTML, then in our house you don’t get to use the basic formatting tools. We started with the basics. We are open to revisiting this, but we think it could be easy to create a mess.

Even longer answer

There is HTML, and then there is a bunch of “simple” alternatives: Markdown, BBCode, MediaWiki and so on. The only need we can see for the “simple” markup languages is for things that are too hard to pull off in raw HTML.

For the foreseeable future we’re likely to support a subset of the basic and obvious HTML tags. Why spend time and effort supporting a “simplifying” tool that adds complexity and doesn’t, in our case, actually simplify much?

If we support BBCode, we need to consider the implications of supporting BBCode forever more - or dealing with the conversion costs down the line.

Using a widely used open standard (hello, HTML) mitigates this as much as possible. BBCode might be popular, but we think there are more people in the world that know HTML. And if you’re going to have to learn one, learning HTML is the more useful.

Our allowed HTML is so simple, with the possible exception of hot-linking, that the “simple” alternatives are not much simpler.

HTML BBCode Markdown MediaWiki
<b>text</b> [b]text[/b] **text** ‘’’text’’’
<i>text</i> [i]text[/i] *text* ''text''

This is a minor point, but we want to avoid a holy war about “BBCode is better/worse than Markdown”. The alternative is that we have to support some or all of them. That’s more work for us and more complexity in the user interface.

Supporting more than one increases the scope for bugs, which could be (for example) exploited by hackers for cross-site-scripting attacks. Even Google, Facebook and Twitter occasionally screw this stuff up dealing with one markup style.

Given this, if you’re arguing for non-HTML markup - BBCode may be more popular on forums, but Markdown is clearly shorter'n'simpler in the above two (common) cases, and MediaWiki (because of Wikipedia) is perhaps the most widely known. Flame on. ®

Whitepapers

5 things you didn’t know about cloud backup
IT departments are embracing cloud backup, but there’s a lot you need to know before choosing a service provider. Learn all the critical things you need to know.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.