Midas

Netscape DevEdge sports a news about Midas, a rich-text editing feature that works with with Mozilla 1.3:

Mozilla 1.3 introduces Midas, an implementation of Microsoft Internet Explorer's designMode feature. The version of Midas in Mozilla 1.3 supports the designMode feature which turns HTML documents into rich-text editors.

I am always happy to see anything that helps content managers get a little comfort to edit texts that are supposed to go on web standards-compliant pages, especially when it works on Macs. But in this case, Midas falls short of doing the job and curiously tarnish the otherwise excellent job that DevEdge evangelists are doing to promote web standards:

It is an old-school rich text editor, i.e. it again gives the content managers the impression that they can modify font types, size and half a dozen more presentational elements that should be driven by a CSS file.

It re-introduces the content+presentation mix that web standards were supposed to suppress. For example, where the IE equivalent (and pretty much any other rich-text editors do) will use the correct semantic markup <em> and <strong>, Midas will bloat your code with this: <span style="font-style: italic;">emphasis</span> <span style="font-weight: bold;">strong</span>. How cute!

Sure, technically speaking it will produce code that validates. But can someone explain to me how I am supposed to control the presentation of an entire web site with this powerful idea of site-wise styles sheets and semantic markup, when the web is full of rich-text editors that maintain content managers in the idea that they can control both the text and the presentation and that actually produce a code mix that is anything but a validable tag soup? By getting my content managers learn XHTML? Dream on!

My plea to the DevEdge evangelists: give a crash-course on web standards with a hint on semantic markup to Midas' developers, please!

4 Comments

First of all, let's make clear that I do not work on the Mozilla code. Also, I completely agree on the concept of using STRONG and EM elements for markup. I already do that on Devedge and my other sites (http://openweb.eu.org/ and http://standblog.com/ )

The real issue behind your point, is the kind of code that should be produced when the user hits those BOLD or ITALIC buttons. BOLD button is not equivalent to STRONG. ITALIC is not EM. It happens that in many case, EM is rendered as italic. (Same for Strong rendered as bold) So binding the Italic button to the EM semantic is not semantically correct.

If you want to avoid that, how do you label (correctly) your buttons, then? Do you suggest to put "Emphasis" on the Italic button, and "Strong Emphasis" on the bold button? Who would understand what this means? What icon would you use for these EM and STRONG buttons?

Tristan, you are right on the principles, emphasis and strong are semantic values while bold and italic are presentational values. However, the [B] and [i] "buttons" are so widespread (copied) amongst every software now that everybody expect them to be here. I find it practically impossible to change that état de fait and it's easier to teach people how to use them (hit B to make something strong, hit i to emphasis something) and take care of the plumbing with strong, em and CSS behind the scenes.

I might be wrong, but I feel that teaching the whole semantic concept (bold is evil, strong is good) to marketing managers is a battle that is lost in advance. What we need is rich-text editors that look like anything they are already familiar with (e.g. Word) but does an excellent job at producing good XHTML semantic that matches each and everyone custom CSS styles.

In short:

- keep what are familiar interface must-have (the dreaded B and i icons could be decorated with tooltips that remind what they really stand for),
- remove anything that is gratuitous presentation (especially text alignements, font faces, colors, etc.),
- open the UI interface to user-defined styles and give them on a list box. Instead of having people select font faces, have them select user-defined styles (in addition to things like headings),
- cram it with all the useful semantic elements (lists, abbreviations, quotes, etc.),
- don't forget table support. Tables are good semantic elements,
- produces irreprochable code: semantic XHTML mapped to my site's CSS choices.

If you have a Mac, take a look at the weblog editor of NetNewsWire, it's a small step in the right direction. It lacks many of the above-listed things, but at least it does not screw up your content with presentation.

I have been investigating a bit this issue with the Midas developers. Actually, Midas knows nothing about buttons. You can have all the buttons you want, and have them insert the element you want. You can have an [Italic] button insert an EM element. (That's a tad problematic on the semantic side but hey, who cares to educate these marketing people anyway ;-).

Midas can be turned on to use [b] and [i] tags, as well as others, but using the "useCSS" execCommand. I don't know whether it is broken or not, but it seems that you need to use a value of "true" as an argument to that command to make it NOT use spans for everything. That seems a bit backward, and I'm not sure whether it is perhaps a bug?

Additionally, while it would seem easier to use tags such as [b], [i], and [u] than a bunch of spans, for a matter of site-specific style sheets, keep in mind that [u] was deprecated as of HTML 4.0 (Dec. 1997). Other mappings may suffer in the same manner.

Unfortunately, while Midas (and the IE WYSIWYG design mode) seems a useful tool, great care is required in its use in order to make it work with your site.

Going to the City of lights for a short stay? I have a flat to rent in Paris. Roomy (up to 6 people), comfortable, calm, fully furnished, modern, with broadband internet, private terrasse, garden and parking… You'll love it (I did when I lived there!). Visit appartement-jardin-paris.com for more information and booking.