Re: RichTextInput03

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 Wednesday, 28 March 2007 20:49:22 UTC