This (yes Karl, this link is XFN-tagged:-) requires a detailed answer.

So Karl wrote a recent entry in his blog about Authoring. He raises a few interesting questions, and innocently pings me about it (like "... and Daniel will probably agree with me that...").

The world of Authoring Markup Languages has always been divided in two : those thinking Wysiwyg and those thinking Structure. Dreamweaver belongs to the former group, HoTMetaL and his successors to the latter one. Those two groups think the world is manichean, ie you belong to a group OR (exclusive) to the other one. But Vincent Quint's Grif and his successors have easily shown that a Wysiwyg AND structured editor is not only possible but available.

Right, Amaya's UI is... well... let's say it's not the highest priority on Amaya's authors' radar :-) But still, the engine behind Amaya is a remarkable Wysiwyg AND structured editor.

At this point, Karl scratches his head and asks "so if we can have a wysiwyg and structured HTML editor, (a) why do the gurus complain and (b) why don't we have a good wysiwyg and structured XML editor?". Both questions are excellent and I thank Karl for asking...

  1. Gurus complain because they forget what is HTML. HTML is one of the flatest markup language ever designed, where all elements can fit into the document's body. Its structuration is not weak, it's almost non-existent. Trying to use such a language with semantics in mind is just a non-sense. HTML was made for the Web and the Web is, by construction, presentational. The now famous argument saying that a more semantic-oriented HTML will help Web authors deploy and maintain information is, 90% of the time, a blurg. Only 10% of web page really deserve semantics.
    So my advice to gurus complaining about HTML editors is the following one : stop using HTML, that's not what you need... It took a long time to see XML on the Web become a reality but, thank God we have Mozilla, they can design their own document model and flood the world with their writings conformant to their own model and presented according to their own stylesheet. And they do have the knowledge to do that.
  2. XML wysiwyg editing is much harder than HTML wysiwyg editing because we're only humans. Humans tend to act looking at their previous acts. In a new situation, the past is instantaneously used to make the present, if it can.
    And the past of editing is Word Processing. People are not used to think in terms of semantics, and semantic UI design is hell. Let me give you two examples :
    1. I have added to Nvu a STRONG button. It encapsulates the selection into a STRONG element. What could be the UI for that? I used an exclamation point in a button, but 95% of our users don't understand it. On the other hand, 100% of our users understand the B button, right? We could use another metaphor, like really present the element name in a way or another. But do you really think the user wants to see "insert a STRONG element"? That's Amaya's approach, and everyone dislikes it. So, if I want my users to make semantic web pages and drop the B element in favor of STRONG, I am just going to remap the B button to create a STRONG instead of a B. Humans are humans, don't think Mr Smith is going to become a semantics guru only because you want it...
      So what I really need is a declarative way of saying that the STRONG element should be used for all B occurences. What Karl calls a "gabarit" in his prose (badly chosen word IMHO - no offense Karl. I suggest "associations élémentales") is, he is totally right, a must-have.
      I do believe we need to extract for the markup meta-language fundamental semantic elements and a few presentational hints too. Because if my document has a no stylesheet, there is no way the application can infer the fact a LIST (uppercase used here just for visibility) element *is* a list. A list is a fundamental semantic element, and LIST should be "associated" to list.
    2. I have designed my own document model (XML). The element names are in french because I am just a frog but it could in japanese, right? So I have two elements called "remarque" and "incident" and these elements appear so often in my document instances I need a UI metaphor for them. How??? How will I tell my editor I need a UI button for those two elements and only those two? How will I specify the presentation of the buttons? How will I tell my editor if the elements are inline or blocks if the editor has to know that BEFORE having to resolve a stylesheet?
      Simple conclusion: we need extensions to Schemas. XML Schemas (erk berk fyyyyyy) and Relax NG (repeat after me, Relax is relax) are not enough for editors. And that's not a recent problem: I was already discussing this issue with Jean Paoli in 1992 about SGML and Grif... 12 years later, we're still at the same point.

Wysiwyg and structured XML editors are not here because wysiwyg people are not used to think structured, and Structuration people do believe "wysiwyg" and "structured" are two antinomic words. They do believe it's impossible to be wysiwyg, simple-like-a-twenty-years-old-word-processor AND structurally correct. They believe it because... er... because... well.. because. I have never seen the beginning of the first line of a good reason why structured and wysiwyg cannot coexist, and what Karl says about it does not help.

Karl concludes there is no wysiwyg structured XML editor (and I agree with that) and there will never be. I won't suprise the reader, and I am sure I won't surprise Karl, if I write here that I strongly disagree with the second part of his conclusion... Disruptive Innovations will try to prove the contrary developing a wysiwyg RelaxNG-based editor for the Connexions Project.

Just an extra note for Karl's pleasure: XForms delenda est. And it's not a joke. It's a bad solution and I'm puzzled about the Mozilla Foundation deciding to implement XForms support into Gecko.