- From: Alexander Graf <a.graf@aetherworld.org>
- Date: Thu, 29 Mar 2007 09:07:23 +0200
- To: "T.V Raman" <raman@google.com>
- Cc: henrik.dvergsdal@hibo.no, public-html@w3.org
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