html is presentation, not content. You should be using Xml
I’m only half joking. I thought this new site was supposed to be about the content. Better to have a DSL (Domain Specific Language) to handle this.
You’ve got to ask yourself, what do users NEED to write about? What is ‘good enough’ to satisfy the needs of the most. We don’t care about the 1% who want to write their doctoral thesis on the site. We want people to post things quickly, easily, and be nice to read. If you look at the abhorrent mess of websites, you might soon rethink the ‘all coders can do html just fine’ line of reasoning. MySpace anyone? For popularity, I reckon more people are better at BBCode from boards than they are used to writing raw html, but I still don’t want BBCode
Also. because of the already overused angle bracket tax, are we going to have to escape all and or risk that being interpreted as html also?
For coders, by coders.
Headings, only 2 levels necessary
Code blocks - necessity
optional ability to indicate language. pretty printing is not a ‘nice to have’.
Links. external and cross-referencing.
Basic markup (bold, italic, highlighted?)
We don’t need colors, div’s, margins, padding, javascript, alternate fonts (or do we), different size fonts, etc. You don’t even need lists or bullets. Than can be done well enough manually. Simple tables might be nice.
Otherwise the postings will look like a big pile of dog crap, and in web 2.0 nobody likes crappy looking websites.
Wikipedia is a good example because they can take their DSL and convert it to anything. In my mind, what you’re writing is wikipedia’ish, so look to the leaders, follow their example, and improve where they have made mistakes.
Why does it have to be just one method? Let them choose html-lite, or Textile, or whatever they prefer. That way, you don’t have to create a new markup method. Just let the user select one from a (hopefully short)list.
I’d prefer it if you left the choice of markup up to me for each individual submission. Sometimes I need full HTML to format something properly, often I just want to use plain text. Obviously this doesn’t work for a wiki page where there are many contributors, but for individual submissions, choice of markup would allow everyone to write in a format they are familiar with.
The official implementation of Markdown supports HTML in the input, so you can use Markdown, and your users will still be able to use HTML if they want to.
What kind of complex visual structure do you want to appear in your site that cannot be expressed in those simple markup languages?
Besides, the fact that I can program HTML, doesn’t mean I don’t prefer something simpler if it’s available. So, I’d go with some of the other markup languages if you asked me.
The biggest feature I can see in wikipedia that would seem to be missing in basic HTML is the automatic cross referencing functionality. A user shouldn’t have to look up the URL to type [a href=“http://en.wikipedia.org/Markup_Languages#Light_Weight”] when the server can figure it out for them from [[lightweight markup language]].
I guess you’ll be adding some special syntax to html for those sorts of issues?
We opted for Markdown in our CMS, because clients in combination with visual editors invariably screwed things up horribly. Although the output would be well-formed, it was inevitably nonsense, and it was far too easy to copy and paste the wrong bits of formatting from Word or somesuch (and lo, if we disabled that bit of functionality, there’d be complaints that they could no longer copy and paste other bits of formatting from Word).
Markdown has a double-pronged advantage for us:
It’s simple for clients to learn how to mark stuff up properly. Because they have to think at least a tiny bit about the separation between content and formatting, it’s easier for them to retrospectively tweak the markup to match what the content’s supposed to convey as opposed to what Word made it look like
We can stick raw HTML into posts where a client’s asked us to do something more complicated than they can manage themselves—Markdown’s smart enough to leave the HTML as-is. Our clients, not being programmers, aren’t likely to ever put in HTML themselves (and are aware that if they do, they stand a greater risk of screwing up their pages and so caveat emptor).
Html is harder to learn then the others when it comes to people without any experience. It has tags and attributes, which can be hard to wrap your mind around. These Lightweight types are easier to use for a beginner. Wikipedia is not a wiki for developers, it is for users who have never made a website before.
Think about your audience, if it’s developers, they would be able to use html and have no problems with that. Although, they might then be able to interfere with your site code, which can be quite damaging. Leaving an a tag open, table open, javascript(!) etc.
Though, I have to say that it is a lot easer to do simple styling like bold and italic in bb code than html (specially if you are to make it xhtml strict valid)
I really think you ought to provide a simple wysiwyg editor, with the ability to edit code by hand. There’s plenty of free, cross-browser applications available that you simply need to drop in and tell it what tags to allow.
Why make people do the markup by hand just because they can? That’s like making a user edit a config file instead of providing them options within the program, just because they can.
I’m glad you at least went with HTML though, so no need to learn a new markup syntax. Especially with the completely unintuitive underscore to mean italics. I can’t think of a worse choice. I mean, there’s the slash which is s/anted like italics, or the underscore, which looks much like an underline. Ugh. =)
At Pendant’s corner over here I have noticed than none of the markup examples would produce the HTML above. Replace “Some examples” with “A Few examples” at first glance.
We had the same discussion when we developed a wiki-like interface in our application.
It seemed that Markdown was easier for users to understand than Textile after initial tests.
I would not go the HTML way since it allows users to break any semantic value you could find in their entry.
I would neither create my own language based on both Markdown and Textile, since users, especially blog users, are very used to one of them. You would just create confusion and mistakes.
Amen. I curse every second that I have to think about (or, God forbid, actually look up) the correct markup to link something or make whitespace non-wrapping or whatever. I already know HTML. You already know HTML. And you, over there, who doesn’t already know HTML: the time you spend learning the tiny subset of HTML that you need to post a comment to a web site will be much more worthwhile than spending that same time learning one of the umpteen subtly different “lightweight” markup systems out there.
Technically, wiki syntax should be
"[http://is.gd/gns lightweight markup language]", not [[lightweight markup language]]]. But that’s because I’m anal. :]
I personally disagree with you, html markup, while easy to understand for us coders, is quite harder to type than Textile or Wikimarkup. (and less pleasing to the eye, imho)
Isn’t the point to be able to let people express their ideas quickly and easily? Why not let us use the GUI editor buttons, it’s not like we’re trying to prove our l33tne55 to anyone; we just want to push text into the computer efficiently.
Failing that, BBCode since it’s simple and doesn’t create tons of visual clutter - we’re writing human readable text with markup, not Perl - unless we’re writing about Perl, of course.
Whatver you choose, please let it handle code in a sane way - what I mean is a little scrolling box with the code in rather than a five-screen scrolling mess, not decorated with line numbers, and in a format that can be easily copy and pasted (so no random blank lines or loss of indenting). Oh, it should handle non-wrapping lines of code correctly too without destroying your page template or making the browser have a horizontal scrollbar.
In the last sentence it sounds like you were going to write your own markup language, perhaps inspired by some of the above.
If you invent a new markup language, or one which uses a combination of features from other ones, you are doing it wrong.
No matter how clever you think you are, no matter how frustrated you are with existing standards, the world does not need a new markup language. I don’t care about the conventions on your site. Unless you expect that I will be using your site more than any other, I want it to work with conventions I learned elsewhere.
Nor do they want to deal with the inevitable bugs your new markup language parser will have. Use an existing standard or don’t use any at all. I suggest: Wikipedia, a subset of HTML, or plain old text. These are the only reasonable choices.
Perhaps I misunderstood you, because you seemed to understand this fact, but in the last sentence your “BUT I’M SO MUCH CLEVERER THAN ANYONE ELSE” brain took over.
I’ve recently been mulling over this very subject, because my company uses a CMS with a horrible GUI that completely mangles input, produces invalid markup, etc.
Markdown certainly looks the ‘easiest’ to learn, although I’m suspecting there’s a lot more to it than presented here (off to research later …)
In my experience, though, however simple the HTML subset, and however much training you give re: elements, attributes, valid nesting, etc., people will always struggle with that most fundamental of beasts: the humble hyperlink. Let’s be fair, to a non-developer, a URL is a pretty complex string of syntax. And editors simply resort to copy+pasting. If I were adressing a ‘low-tech’ audience, I’d seriously consider one of:
a) Denying any out-bound links + clever wiki-style auto-linking
b) Auto-linking allowing out-bound links via a search engine (or similar)
c) Robsust URL parsing looking for obvious errors
- unless we’re writing about Perl, of course.