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.:
>>>
>>>   <textarea accept="text/css" editor="cssedit.js"></textarea>
>>>
>>>
>>> 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
>
>

Received on Thursday, 29 March 2007 07:08:01 UTC