Symphony.

You’re welcome!

I put in a plea for a number of other elements that are extremely helpful for editors setting out professionally formatted text. A few inline elements – abbr, dfn, i*, q, sub, sup and a select box for special characters for things like en and em dashes, would be terrific. To get these set up in most text editors is a cumbersome business and removing things you absolutely don’t want editors to have, text colours, font changes etc. is awkward.

• The i element still part of the spec and useful for tagging information that is not emphasized which are normally in italic, text in a foreign language, book titles, art objects, ship names etc.

Basic XHTML editor that outputs valid XML and gives the user only the following options:

* formatting: paragraphs, headlines, blockquotes, code blocks

and custom classes for these block elements * styles: strong, em * lists: ordered/unordered * insertation tool for links and images * tools: undo, redo and view source

abbr, dfn, i*, q, sub, sup

Well, these might be helpful in some cases but I don’t think these should be part of a simple editor. It should be easily possible to add own tags but core should only provide the needed basics. And if we start talking about the semantic differences between an book title that is italic or emphasized we’ll certainly end up with a solution like this: fckeditor.net/demo.

Please don’t get me wrong - I think the list of elements needs to be discussed. Could you give more input why you think these inline elements are important for basic editor?

Both fckeditor and tinyMCE out of the box, allow the content editor to do too much – nobody should be able to apply underline!

Italized text traditionally conveys lots of different useful information.

It can be used to add emphasis.

“Frankly, my dear, I don’t give a damn.” Reg Butler declared stepping out the door.

Also, denote a larger significant work like a book or a film.

The famous line above comes from the 1939 film Gone with the Wind starring Clark Gable and Vivien Leigh.

It can be used to highlight the first use of a foreign word, usually with a definition.

In Eritrea, despite continually dodging bullets, Charlotte developed a defining passion for ingeria, a local flat bread.

In HTML, we have more granularity than print. The last example could wrapped in a dfn element with a title tag. The middle one would be best in an i tag. Neither is really like the first example, which denotes emphasis. I would like to have surrounded the first example with a q but it is not on the toolbar, and maybe ‘Reg Butler’ with a cite tag. I just I couldn’t be bothered to figure out how.

Along with tags like code and var, which are only useful to the programmers who developed the specification, HTML provides tags which are of general semantic use. The trouble is, in rich text editors, they usually come with lots of other cruft.

If you’re thinking about your markup at that level of semantic detail, and working with that range of tags, you should probably just be hand-coding it anyway. No canned solution is going to meet every need. I’d think having a button to view/edit the source HTML would be enough.

If you’re thinking about your markup at that level of semantic detail, and working with that range of tags, you should probably just be hand-coding it anyway.

Here is where I get a little titchy.

I am happy hand-coding, I can spell out html tags with Alphabits at breakfast. However, in the organization I work for like most, the content creation is not handled by me, the designer, or me, the programmer. It is, at the best of times, handled by trained writers, editors and in lesser cases secretaries and admin assistants. In the small organizations I freelance for, the content creation is handled by the owners.

In the organization I work for there are four writers, they are familiar with Associated Press style guides and our own organizational style guides, they can tell the difference between an abbreviation and an acronym, they know what a citation is, they understand quotes and block quotes and could make sense of defining instance notations and most know when something should go into italics and why. But should they have to learn a whole new language where italics is <i> or [i] or *i* in order to use that knowledge?

We all define what is necessary differently. The toolbar above this text field has a a means of tagging something as code, how useful is that for 90% of the content editors putting content on the Web? It also as the ability of putting a ruled line into text, when should that be useful or even semantic?

As I designer, I am continually faced with either taking a rich text editor (like tinyMCE) that is trying to replicate the dogs dinner that is Word and awkwardly trying to strip it down as much as possible, or expecting content providers to learn some kind of code, which they will never use in any other part of their life.

There, rant over. What I salivate for is a semantic editor that empowers content providers to harness the semantic power of html without having to learn a whole new coding language. Sort of mini xml editor, they can understand.

Sure, but generally I think developers here are working with a version of the Pareto Principle in mind. Build the 20% that matters to 80% of people. As Nils says above:

I[t] should be easily possible to add own tags but core should only provide the needed basics.

It sounds like what’s ideal is not necessarily to have all these other elements added by default to an editor (since they’d be overkill in the vast majority of use cases), but to have one that’s extensible enough that you could customize your installation by adding all the specific bits that you need for your users… Does that make sense?

It sounds like what’s ideal is not necessarily to have all these other elements added by default to an editor (since they’d be overkill in the vast majority of use cases), but to have one that’s extensible enough that you could customize your installation by adding all the specific bits that you need for your users…

That’s exactly what I’m thinking of: having a minimal editor core but giving the user an easy way to add custom tags.

Sounds good Nils. All of the phrase elements share the same set of attributes and characteristic (text contained in an opening and closing tag) you could almost have the same modality work for all of them. Eg if you have a routine for a strong tag it could also work for of any of the other phrase elements. Would it be possible to be able to add the title, class or lang attributes to any of them?

having a minimal editor core but giving the user an easy way to add custom tags.

Wondering what the status of this is… Does it just need more testing? Are there specific bits that need work?

I have been testing it in extenso on a website that will go online soon and I have to say that WYMEditor is far from perfect (some fundamental things used in this extension do not work properly in Firefox - damn!). I was thinking about starting again from scratch using CKEditor as a base.

@Nils CKEditor looks great but what problems are you getting?

CKEditor looks nice. That would be cool.

Ugh, it’s just a tarted-up FCKEditor, on of the worst editors I’ve used. :(

I’d much prefer WYMEditor. Still looks as though CKEditor can’t be forced to produce decent output.

@FredD I’ve had good luck with TinyMCE. I always edit its config so it only shows the buttons I want and allow people to only use tags/classes I define. I even comment out bits of the pop-up window templates for link/image properties so they can’t add things like “target=_”. It’s a hassle, but once you set one up, you can reuse the modified extension over and over again.

I do agree that it’s important for editors to be able to apply whatever style, like AP Style, to whatever they are writing. Also, a special characters pallet is crucial since using your keyboard or pasting from Word (barf) to get them doesn’t always encode correctly. The ability to use good typography should be a goal even if a lot of people don’t use it.

That said, any tag that requires a extra properties and some code work, like abbr, cite or dfn, I could live without. Those who know what they are and how to use can simply add in the HTML view.

Speaking of Word, has anyone figured out how to make a text editor NOT take all that <span class="mso:normal blah blah blah">? People pasting from Word is always a huge thorn in my side. >:-(

@MrBlank We (@bzerangue) and our staff use a free service called WordOff. I noticed it has an API that perhaps could be employed in one of the editors Symphony uses.

Heather Floyd also in her Cleaning Up Word article lists several sources that I haven’t checked out exhaustively; however, one or more of them, perhaps, may be openSource and available for assimilation into one of the text editors for Symphony.

I’m using TinyMCE for our Intranet. The other editors I’ve tested (WYMEditor, YUIEditor, FCK Editor plus a few more) just don’t cut it. They all had flaws, were buggy or very hard to configure. TinyMCE was the least bad of the available choices.

It takes a bit of work but with TinyMCE I’ve mangaged to:

• force it to output valid XHTML,
• automatic clean-up of common bad authoring (such as adding <strong> to h2 - h4 titles),
• remove most of the bloated button interface (this part is really easy),
• adjust the CSS to make it display p, h2, h3, dl, ul etc. the exact same way WYMEditor does it (you know the little ‘p’ in the top left corner for a paragraph etc.) and
• build a custom plugin for adding inline code.

My main goal with this was to force the authors to think more about the structure of their content than the looks. Here is a sample of how it looks:

You can configure TinyMCE to only accept XHTML valid elements and structure using this doc page: http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/valid_elements

WYMEditor does more than it should and less than it could. I have the problem that it does not always wrap new lines in paragraphs when using Safari on a Mac.

@Nils: All of the editors I’ve tested has this problem in various ways. YUIEditor even had problems with the exact same thing in Firefox in version 2.x but Yahoo! has said it would be “fixed” until the 3.x version.

Looking forward to see the progress of your work with this. Keep the updates coming! :)

Looking forward to see the progress of your work with this. Keep the updates coming! :)

Well, my wish is to have a simple editor that does not try to mimic a real word processor. It should be extensible, fit into Symphony’s design and coding standards and should return valid XHTML (in a reliable, cross-browser way). None of the mentioned editors really seem to match this idea.

I’m not sure if all this is possible without starting from scratch. And I’m not sure if I’ll find the time for such a huge task as my coding skills are “experimental”. So I’m not sure about future updates …

http://code.google.com/intl/pt-BR/webtoolkit/doc/1.6/RefWidgetGallery.html http://gwt.google.com/samples/Showcase/Showcase.html#CwRichText

RichTextArea looks great. Why not give it a try? :)