cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: HTML editor widget (was Re: [proposal] Doco)
Date Thu, 30 Oct 2003 09:34:03 GMT

On Wednesday, Oct 29, 2003, at 11:40 Europe/Rome, Bruno Dumon wrote:

> I've only just started with some little javascript experiments, so it's
> not like any code has been written yet.

ok, but it's great to see you doing this

> Here are some first random thoughts:
> * different users of the widget (like the doco project vs the project
> where we need it) will likely require different subsets of HTML to be
> used.

True, even if, for XHTML, you can support different modules. For 
example, I didn't support tables in Linotype.

> * support for both Mozilla and IE is important. Other browsers should
> fall back to a textarea with raw HTML in it.


> * the HTML produced by the editor should be cleaned (i.e. not supported
> tags & attributes removed) and normalized (formatted). The goal of this
> is to deliver a nice XHTML-subset-doc for storage, and to show nice 
> to people editing it manually. Hopefully this will also make it 
> possible
> to do meaningful text-based diffs.


> My first thought was to do this cleanup stuff serverside (could be as
> simple as an XSL, which would make it easily customisable too). However
> it seems like you want to do all that on the client side?

Linotype already includes a DOM serializer, I think it already does 
some pretty formatting and already has the ability to distinguish 
between whitespace-safe elements and non.

> * Currently in e.g. Linotype the source for the editor (thus of the
> iframe) is fetched separately from the main page. This is harder to do
> with cforms since then the pipeline from which the content is fetched
> should also have access to the cforms Form which is stored somewhere in
> a variable in a flowscript. For the cforms widget it would be easier I
> think to embed the HTML directly in the page (e.g. as a Javascript
> variable). This also makes it possible to assign the content either to
> the html editor or the textarea depending on what the client supports.

I thought about that too: my solution would be to have woody draw the 
widget as an empty <iframe> and then fill it up at page load time from 
some client-side javascript.

In theory it's easy, in practice, I expect tons of bugs and 
incompatibilities between browsers (but haven't tried yet)

Another thing I wanted to try is to embed the icons right into the page 
instead of having them fetched from outside, this makes is easier since 
you don't have to mount your icons somewhere in your URI space.

> * Automatic image upload: still need to think more about this. After
> pressing the submit button (and afterwards possibly showing the form
> again), the images will need to become available in the URL space. How
> that's done will probably differ from application to application so we
> could put that behaviour behind an interface.

hmmm, what aobut giving back the uploaded "Parts" back into the object 
model that is accessible to the flowscript. the flow will handle them 
and put them in the proper place... at this point, the flow will have 
to be able to call a "link translation" on the page.

> * wiki syntax support: we have no need for this, so don't expect any
> effort from me on that.

Fair enough, but please keep in mind that the editor will have "multi 
views" and need to be defined in the description of the widget for that 
particular form.


View raw message