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/RaggettReceived on Sunday, 18 March 2007 20:52:40 UTC
This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:21:34 UTC