Re: RichTextInput03

Agreed on both counts, i.e. "wiki syntax not in scope" and "you
dont need specialized rich-text controls".

There are two ways you can approach the need for specialized
controls; design a new one everytime someone asks for one, and
have a ragbag of controls that over time become unmanageable; or
you can sit down and so some actual design based on requirements
and use cases --- which is the approach we took in the XForms WG.
The net of that work was that we discovered that by factoring the
data model from the view, and attaching type information to the
data, we could get away with a small number of generic controls
 and leave it to browsers to pick the right user experience. 

As an example, this is why XForms did not need to define an
explicit date-picker control, or have to wrestle with what that
user interface should look like on different devices. Instead,
that design binds a generic input control 
<input ref="birthdate"><label>Enter Birthdate</label></input>

and leaves it to the UA to pick the best possible end-user
experience; the UA figures out that you need a date picker
because the input control binds to a data node of type "date".

We could do rich controls and many other specialized controls the
same way --- notice that as far as "edit UI" goes, all one needs
to standardize is how the user generated content gets serialized
and submitted.

So for instance, if you're creating a "Web Forum" webapp --- and
 want to store the user generated cotnent as HTML,
you should not have to force your users to type the kind of HTML
 you expect. Instead, you should be able to specify that what you
 accept is a given vocabulary -- e.g. XHTML-1.0,
and leave it to the browser to generate that from wiki-like input
 if the browser thinks that to be a useful feature.

Alexander Graf writes:
 > 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
 > >
 > >

-- 
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 15:04:03 UTC