On Mon, 19 Mar 2007, Laurens Holst wrote:
> Text-based input fields which all use different codes to mark up
> anything but basic text are just so annoying. The primary
> application of WYSIWYG editors is inside web pages.
>
> ContentEditable is very nice, especially if you didn’t need 10
> pages of code to fix up the browser’s horrible output and
> dynamically create the buttons and switch out the textarea with an
> iframe, and all the related CSS issues. But maybe it could be made
> even easier by adding an ‘enctype="text/html"’ attribute of
> some sorts to textarea, which would turn it into a
> browser-provided WYSIWYG editor that submits HTML, including
> controls for headings, et cetera. That way you don’t need a big
> Javascript library with all its complications to be able to use a
> rich text area (at least, not eventually). So, although per Daniel
> I’m sure the time for this is not right, I propose we add this.
I appreciate your desire to make it easier to add WYSIWYG editors
within blogs, wikis etc. but think that the problem needs a little
bounding and this will depend on the context and target audience
etc. For very simple word processing features, there is a reasonable
body of shared experience on what to expect from wysiwyg editors,
but HTML in general offers so many opportunities that implementers
are unlikely to agree on the details. For instance, how would you
approach the UI for microformats?
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett