Rich Text Editing
From RuntimeWiki
Contents |
Title
More Standard and Consistent Rich Text Editing Support
Detailed write-up
Description
Rich text editing is supported by various browsers in various ways that are inconsistent and have all sorts of issues.
Why Is This Important?
Rich text editing is at the core of many wildly popular web applications (such as blogging and wiki) and will be at core for many more web applications going forward as the community adopts more Ajax.
Possible Workarounds
Some Ajax libraries (and commercial products) have developed some heroic JavaScript to enable rich text editing in the browser. However, text editing is a hugely complex feature, including complex internationalization issues involving arcane language-dependent issues relating to text direction (left-to-right, right-to-left, top-to-bottom, glyph selection, glyph rotation, and text wrapping. Operating systems have to implement this stuff anyway. Expose it within the browser as a native feature instead of requiring hundreds of thousands of lines of JavaScript by people who don't have full expertise.
Possible Solutions
Operating systems have to implement this stuff anyway. Expose it within the browser as a native feature instead of requiring hundreds of thousands of lines of JavaScript by people who don't have full expertise.
However, "exposing it within the browser" is much easier said than done. There are so many complexities that if attempted in a standards body, it might take years to work everything out within a committee setting. Perhaps it would be better if one of the browsers took a crack at addressing this in a way that the other browsers could implement, and then propose that approach to a standards body.
HTML5 proposes a 'contenteditable' attribute ([1]) as the markup and provides some information about the underlying functionality that needs to be supported, but text editing is a complicated technology area and the HTML5 spec probably only captures a fraction of what is needed to serve the world's editing requirements.
Background material that request this feature
to be added.
Discussion
In this section, the contributors should express their opinions about this feature request, such as providing particular technical analysis or describing in prose why this feature is important (or not). It is recommended that each contributor create his own level-3 sub-section
Coach Wei Comments
There are workarounds for this with hundreds of lines of Javascript. This is such a key feature for making the web more interactive and useful(don't we spent most of our time working on different kinds of documents?), enhanced rich text editing is key. What I'd like to see:
- more unified editing API support;
- Easy API to turn on/off a section (DIV, iFrame, etc) from "viewing mode" to "edit mode";
Jon Ferraiolo Comments
I'm not sure what is the best technical approach here, whether to define a 'contenteditable' attribute, which turns on a black-box text editing feature, and then let the browsers compete on who offers the best editing features, or to have the browsers provide a set of low-level editing APIs that will allow Ajax libraries to compete by offering better text editing at the JavaScript level. Ultimately, we probably need both.
Adrian Herscu Comments
It seems that the serialization format will be a big issue... Consider for example that Joe is editing his blog on MS-Windows. His text will be serialized using some MS-Word component (perhaps). What will happen when Sally will want to read or re-edit Joe's text on a Mac? Jon Ferraiolo: Adrian, what do you mean by serialization format? Wouldn't it just be (X)HTML? I realize that HTML isn't the best possible format for text editing, but it has the virtue of being widely supported.
@Jon: (X)HTML is about structure; the style is defined using CSS rules. Now, suppose that the rich text editor on MS-Windows/IE will support images as a bullet style, but Firefox (or Opera, Safari, etc.) will not support such a feature. The user of these browsers will not be able to manipulate these bullets correctly. Moreover, there might be an issue with the CSS rules names: some editor might call his bold rule "ms-bold" and the other one "moz-bold". What will happen when the user will put his cursor on something that is flagged as "ms-bold" in a non-MS browser? Will the bold button in the toolbar be activated? And there are many more examples... Try to export a DOC from MS-Word as (X)HTML and then import it into OO-Writer and vice-versa. There are even issues between different versions of the same software. Jon Ferraiolo: Thanks for the explanation, and I understand what you are saying and recognize the importance, but what you are asking for is not going to be easy from an industry politics perspective. We are right now in a MAJOR and expensive standards war in the editable office documents arena taking place at ISO and within various government standards bodies between companies who believe ODF should be the one and only standard and others (led by Microsoft) who want to get the standards world to approve OOXML (the Office file format) as a second official standard. This standards battle is so epic that it has been covered by the mainstream consumer press.
Brad Neuberg's comments
The web was meant to be a two-way medium. Microsoft was an early innovator here in actually getting a rich text control into the browser (thanks Microsoft!), but the amount of JavaScript to paper over the differences (and add new features) is serious black magic cross browser. I say we just see what one of the browsers is doing that has the best feature-set and does thing well, document it, and say that is the de-facto defined standard for text-editing, similar to what Ian did with the canvas tag in HTML 5 by just seeing what Safari was doing (with a few tweaks if appropriate but done with restraint).
Serialization formats are hard, and run into lots of (fun) tech industry political battles. Is there anyone who has actually hacked on this stuff who can comment? What is the best serialization format you've seen so far: basic HTML, HTML + styles, XHTML, etc. Please only comment if you've actually built rich text editor normalization code that papers over the serialization differences between the different rich text editors, whether doing the normalization on the server-side (ala Blogger I think) or on the client-side (ala FCKeditor I think). Lets just grab one that is well done and call this the standard serialization format.
Phase I Voting - Vote for Your Top 5 Features
NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:
Phase II Voting
More about this later.
