wysiwyg is fundamentally flawed because the web is not wysiwyg. And HTML is a semantic description of content, not its formatting. We fought long and hard for that to be recognised, only for people to come along and try to derail that effort with wysiwyg editors.
Case in point: the markup in your final link is terrible: tables for layout, inline styles, DIVs containing nothing by BRs, etc. I could never sanction the use of an editor that produces that kind of garbage.
Don't get me wrong, Markdown is not the solution either. For the novice, it shares the same sort of cognitive barrier as HTML - confusing symbols that take time and effort to understand, the whole notion of plaintext being rendered as formatted text - without the huge benefit of flexibility - many things just can't be done in Markdown.
I don't really know what the solution is, but - in my experience - reducing the problem set from a general purpose editor to do 50% of what HTML does, to context-specific 'wysiwyg-like' editors is a step in the right direction.
The only sane solution I've yet seen is WYMeditor. All the ease and immediacy of WYSIWYG, but producing proper standards-compliant code with the classes you choose. The code's not brilliant (having Rangy mixed in to cope with legacy IE annoys me), but the concept is so far ahead of anything else that I now use it pretty much exclusively for in-browser editing; as a professional writer I could never rewire my habits to the obtrusive markup of Markdown.
"Case in point: the markup in your final link is terrible"
To be fair to Redactor, I was using an older version before its license change. It was something I quickly integrated a while back and it does introduce <BR> and some other weird things. At the moment moment of writing the tutorial, I just needed it to "Look Right" and not technically be "Right" or "Pretty". My core product doesn't revolve around document management.
"I could never sanction the use of an editor that produces that kind of garbage."
The thing is, I'm willing to bet a lot of people couldn't care less about the HTML produced. In my case, I just needed to get the document out ASAP so that I could move on to the other hundred things on my to do list. I probably used redactor to put a square into a circle, but it got the job done for me.
"Don't get me wrong, Markdown is not the solution either"
I agree and who ever comes up with the solution, will probably do quite well. My reason for posting was to point out the Markdown isn't the final solution. For now, I'm willing to bet a lot of people just want to be able to type away and have things look right, with out it being right.
"The thing is, I'm willing to bet a lot of people couldn't care less about the HTML produced."
People with disabilities, especially visual ones, rely on technologies that extract semantic meaning from your site's HTML in order to convert it to another form. If your HTML is garbage then your site is inaccessible.
To be completely fair to Redactor, I don't think that it produced the 'Divs containing nothing but BRs'. I just made a few paragraphs in redactor in it marked them appropriately as <p>. I think that, given that that site was used as an example of allowing someone to let the html by hand, the errors you point out may very well likely be errors introduced by the person writing the html by hand.
It's technically true because YAML includes an alternate "inline style" that lets you write objects in JSON syntax. Therefore any JSON object is a valid YAML object as well. But, not an idiomatically written YAML object, since writing YAML using only inline style is unusual.
To be specific, JSON syntax is a subset of YAML version 1.2.
However, I hate YAML with a passion. It is worse than XML in my books. I can usually read JSON fine. I can also read XML in many cases. For the life of me, I just can't read YAML. It has something to do with "-", line indentation and different ways of writing lists.
Of course, someone will say YAML is technically better ...
Same here, it is very difficult for me to tell levels of nested structures in yaml. Though I'm sure if I sat down and read up on it I could force it into my brain. But shouldn't it be intuitive to read without that?
Python has exactly the same problem -- control-structure nesting quickly gets confusing and hard to read beyond a certain (fairly small) size -- but at least with python, you have the option of splitting off stuff into separate functions to limit the amount of nesting and size of blocks.
Did you read the article? It's not really about the filesystem. 1 part your fault for seemingly not reading the article you're commenting about, 1 part the submitter's fault for choosing such a misleading title.
I don't quite get Linus' problem with XML for document markup (for anything else - config files, build scripts - sure, XML is horrible). Does anyone know any more details about what his specific gripe is? For me, asciidoc (which looks very similar, conceptually, to markdown) suffers from one huge problem: it's incomplete. Substituting symbols for words results in a more limited vocabulary, if that vocabulary is to remain at all memorable.
Sure, XML can be nasty, but thats very much a function of the care taken to a) format the file sensibly b) use appropriate structure (i.e. be as specific as necessary, and no more).
For those who missed it, here's what Linus wrote in the comments:
"+Aaron Traas no, XML isn't even good for document markup.
Use 'asciidoc' for document markup. Really. It's actually
readable by humans, and easier to parse and way more flexible
XML is crap. Really. There are no excuses. XML is nasty to
parse for humans, and it's a disaster to parse even for
computers. There's just no reason for that horrible crap to
As to JSON, it's certainly a better format than XML both for
humans and computers, but it ends up sharing a lot of the
same issues in the end: putting everything in one file is
just not a good idea. There's a reason people end up using
simple databases for a lot of things.
INI files are fine for simple config stuff. I still think
that "git config" is a good implementation."
Linus' adversion to XML explains also why parsing git's output is so abysmal inconsistent.
Subversion has a really good XML output for its log command which is a joy to use (and that's something to say if you work with XML) whereas with git you always have ugly format options that are most of the time underdocumented.
Just a note, pandoc (implemented in Haskell) makes it almost a joy to work with various "dialects" of ReST/AsciiDoc/Markdown etc. It feels like what python's ReST should have been (at least the last time I looked, it was pretty hard to get different html out of it - even if it is supposed to be extendible). If you have a dependency on python, staying with the python libs are probably best, but if you just want "a document system", I recommend having a look at pandoc.
Actually, i am using sphinx and latexpdf to generate project documentation and it is more then awesome to generate beautiful looking LaTeX documents with graphiz graphs in high-res but only writing rst... :)
I like that the syntax for features is illustrative, so that the raw text representation doesn't end up as a mess of ugly tags. However it looks completely inflexible. It's a mishmash of special cases. How would I implement a new feature without breaking existing implementations? Or without having to write a new parser that in all likelihood will break on some subtle edge case?
At its core XML (if you ignore all the DTD, namespace and entity rubbish) is both simpler and more powerful than this. You have text, tags and attributes. What those tags and attributes mean is up to the application, but at the very least you can be sure that the document can always be reliably parsed into a form you can work with.
Document markup is the one place XML is a no-brainer - more specifically, long-form, highly structured documents (i.e., essentially books).
Without it, publishing would be stuck in a morass of nebulous, ill-documented proprietary messes, and a great deal of current learning would be at risk of being lost to posterity. The fact that there are associated open standards such as XSLT with which to transform it is just the icing on the cake as far as publishing is concerned.
This is why there's so much distaste for XML - people try to use it for applications where it isn't ideal (and there are many more of those than there are applications where it is ideal) because they've swallowed someone else's hype, and as a consequence they have a bad time. If not for the unbelievable exaggeration a few years back (I heard people claim without irony that XML - a markup language for god's sake - would literally change the world), the divisiveness wouldn't exist, and it would be a technology used by experts quietly getting on with the jobs it's best for.
>Document markup is the one place XML is a no-brainer
That's only true for minimally formatted documents. For anything that approaches professional typesetting requirements, XML is a nightmare.
By far the biggest problem, it the requirement that inner elements must be closed before outer ones can be. This frequently means that the software must do a huge amount of read-ahead to figure out which aspect of the formatting changes first to make that formatting element innermost.
Sometimes, that's simply not possible to arrange and so you have to close a whole bunch of elements and then reopen all but one of them.
All this because a constraint of the format.
Ideal formats, such as used by typesetting systems that don't use XML, allow you to say: keep this formatting trait on until it's switched off. There is no concept of every element needing to be a subset of its encompassing element.
That's a wonderful rant - I particularly appreciate the digression into anti-bush rhetoric - but:
1. There's very little detail here; it's a nicely worded, emotionally charged piece that leaves a lot of detail unaddressed, e.g. "'I would like to hear why you think it is so bad, can you be more specific please?' If you really need more information, search the Net, please." That's not very helpful.
2. It argues for 'simpler' markup via the removal of attributes. Where possible, I totally agree, as at least hinted at in my original post. Sometimes, though, this would be impossible or unwieldy (e.g. HREF attribute on an A element).
3. Character entities vs. unicode - totally agree. Wherever possible, I use proper unicode characters rather than ugly character entities in my markup.
4. "But the one thing I would change the most from a markup language ... is to go for a binary representation." Linus would vehemently disagree on this point.
with key words being "Whather what you are really after is foo, bar, or zot, depends on your application.".
His articles on SGML are mandatory reading too.
Several years ago someone posted these links and it opened wonderful world of Lisp to me. Not the language per se (there are many languages) but whole another Universe of how things could be done. I swear I jumped on the chair reading every page of CL standard, how brilliant it is on every level to C. Eventually it led me to rethink attitude to C and Unix in general, core parts of which I despise now.
So here am I returning favor, maybe someone will follow these links too.
Where do you live? I'm fascinated by your use of the word 'drinker', as if people who ever drink any alcohol aren't in the vast majority. Where I live (UK), pretty much everyone drinks alcohol at least weekly. Most people drink socially, within healthy boundaries (3-4 units per day is the current guideline), occasionally overindulging, often detoxing for a period of time. Whilst there are social problems caused by alcohol abuse, there is no way that in our society we would 'look down' on each other for consuming alcohol, nor define anyone as a 'drinker'. In my whole life I've met 2 people who are not 'drinkers', and one of them has a very rare drink from time-to-time.
As to your point, yes, of course hardly anyone who ever drinks never drinks more than one unit of alcohol per day; that is practically impossible. But many will drink on average, no more than one unit per day.