RE:Re: RichTextInput03

A major problem for page authors like myself today is that the javascript implementations to produce a richText controls are too buggy and produce code that do not follow W3C-standards. I think it is very important to make it easier to use a richText control and to improve it as users want it and many CMS-solutions generate html-pages based on the code from these editors. The latter can only be done by browsers either by improving the current "designMode" editor or allow for external editors. But to make it easier to present a richText control it is possible to add an attribute to the textarea input control. The end result should be text so I think textarea should be used. Adding an attribute called enhancedEditor="1" could trigger the editor with a default set of buttons (toolbar). Any other adjustments to the toolbar must be done via html, css and javascript. Another attribute could be 'type' as suggested which controls which editor the user-agents renders.

Espen Antonsen - 24SevenOffice

---- Opprinnelig melding ---- 
Fra:Alexander Graf [a.graf@aetherworld.org]
Sendt: 29.03.2007 09:07:23 
Til: raman@google.com 
Emne: Re: RichTextInput03 


I agree the need is there but it's out of scope for the html-wg.

I still don't get why we need a RichText Input control, though.
Why not let browser vendors and / or users handle this?



On 28.03.2007, at 22:48, T.V Raman wrote:

>
>
> As part of this effort, it would be nice to come up with a
> consistent WIKI markup that gets converted to HTML.
>
> Perhaps its only me, but have others here noticed that that thing
> that was supposed to be "simple" AKA Wiki Syntax, has now become
> as confusing as everything else in this space, with each Wiki
> having a slightly different ASCII notation for section headers
> and lists?
>
>
> Henrik Dvergsdal writes:
>>
>> I fully support your thoughts on this. However, from the previous
>> discussion it now seems to me that we need a control that borrows
>> aspects from
>>
>> * the textarea control (textual input and output),
>> * the file input control (HTTP transfer and security mechanisms)
>> * the object element (tool/plugin/api selection, parametrization and
>> styling)
>>
>> In addition to this, of course, we need the xml validation step and
>> related error handling mechanisms.
>>
>> --
>> Henrik
>>
>>
>> On 27. mar. 2007, at 23.01, Rene Saarsoo wrote:
>>
>>>
>>> Anne van Kesteren wrote:
>>>> Anyway, http://www.whatwg.org/specs/web-forms/current-work/#accept
>>>> should address what you ask for, although I think people will want
>>>> to have a bit more control over how such an editor works.
>>>
>>> Thanks for reminding this very relevant attribute from WHATWG spec.

>>>
>>> Which makes me think, maybe we can have the best of all worlds:
>>>
>>> * When scripting is available, then the user would be presented
>>> with UI crafted by page author.
>>>
>>> * When an appropriate editor for specified content-type is 
>>> available,
>>> then the user would be presented with that editor.
>>>
>>> * When both are available, then the user can make a choice, which 
>>> one
>>> to use.
>>>
>>> * When neither is available, then the user would be presented with
>>> a simple textarea. Additionally there should be an option for user
>>> to switch into the simplest plain-text-mode even when special
>>> editor or UI script is available.
>>>
>>> That way neither the page author is limited with the choice of
>>> publicly available editors, nor the user is limited with the
>>> editor provided by page author.
>>>
>>> Opening specialized editor for a specific content type is pretty
>>> easy to implement - OmniWeb already has a builtin way to switch from
>>> textarea to text editor [1], Elinks, w3m and lynx also support
>>> external editors, and there are is bunch of extensions to achieve
>>> the same in Firefox (WiewSourceWith [2] and Mozex [3] to name a 
>>> few).
>>>
>>> The more complex part is providing some kind of general mechanism
>>> to switch into and out of an editor created with some author-crafted
>>> script. To make this kind of switching available, the user-agent
>>> must understand which script on the page is responsible for the
>>> editor. This information could either be provided through some API
>>> or with some additional attribute on textarea, e.g.:
>>>
>>> 
>>>
>>>
>>> Rene Saarsoo
>>>
>>> [1] http://www.omnigroup.com/images/images-5/features/ZoomEditor.png
>>> [2] https://addons.mozilla.org/extensions/moreinfo.php?id=394
>>> [3] http://mozex.mozdev.org/
>>>
>>
>
> -- 
> Best Regards,
> --raman
>
> Title: Research Scientist
> Email: raman@google.com
> WWW: http://emacspeak.sf.net/raman/
> Google: tv+raman
> GTalk: raman@google.com, tv.raman.tv@gmail.com
> PGP: http://emacspeak.sf.net/raman/raman-almaden.asc
>
>