Re: Rich text input control (was: XML input control)

> I think we should throw aside the exact technological solution
> (XML, JavaScript, etc) and try to analyze the question in a more
> broader sense.

OK. Seems like a good idea

> I guess the main problem could be formulated as follows:
>
> * No built-in input method exists for structured text.
>
> But it's not possible to build such a generic input control that
> any website could make use of. Site A would like you to only enter
> plain paragraphs with maybe some bold and italic text, while site B
> would like you to have all the formatting abilities of modern word-
> processor. But site C would like his own special unique features.
>
> So we can't have one-size-fits-all-solution in this case.

No, but I think a lot of sites will be served well by something  
corresponding to a subset of HTML (a simplified version, excluding  
forms, frames and objects). Maybe this could be a one-size-fits-50%- 
solution. If we add a wiki editor, and a handful of more specialized  
tools, a lot would be covered.

> There has to be a way how site author can exactly specify what
> kind of input is allowed. This control could be given in two
> different ways:
>
> Imperative approach - author can use scripting languages to build
> his own input control that behaves exactly as he defines.
>
> Declarative approach - author defines the allowed input format and
> the user-agent will provide a meaningful editor for that format.
>
>
> The first approach has more-or-less worked until now. One of the
> main down-sides is, that the author needs to do a lot of careful
> programming to come up with even a modest WYSIWYG editor. But a
> better API can be provided for programmers to make the construction
> of such editors a lot simpler.

Well it has worked less rather than more I think. Nevertheless, in  
some cases this approach would probably be necessary. However, one  
editor per application is clearly not feasible. Most applications  
will rely on externally developed editors even with an improved API.

> The second approach seems to be lifting the heavy duty of programming
> a WYSIWYG editor from the sholders of site author to the shoulders
> of someone else. The question is: to who? As I stated earlier,  
> there can
> be no generic editor that would suite all sites. Who should write this
> editor that fills the requirements of site X? If it should be the site
> author himself, then I see no difference from the first approach.

Well let's say that each browser provides a built-in (simple)  
structured text editor and the wiki community provides one or more  
wiki editors. I also think that big internet companies such as ebay  
and myspace would profit from providing publicly available  
specialized editors. All these actors will have something to gain by  
letting people use and get familiar with *their* editor.

To get this working, however, I think it is imperative to have some  
kind of specification regarding what kind of output these tools  
generate. Without such a specification we will continue to have a  
chaotic situation where editors usually generate various dialects of  
more or less adequate HTML that has to be pasted into pages as raw  
text. In my view this is not good enough and needs to be replaced  
with a more formal mechanism. I also think such a mechanism will  
promote standardization and cross platform compatibility of CMS  
input, thereby facilitating competition and speeding up the  
development of tools as outlined above.

--
Henrik

Received on Tuesday, 27 March 2007 01:12:50 UTC