Re: wysiwyg editors

> So I've got a monkey wrench to throw in the works:

Wondered when this was coming :)

> The browser is going to need to render whatever we do as HTML, but 
> ISTM that HTML as a destination format is a poor choice for any 
> number of reasons. Firstly, it's ambiguious. The discussion we're 
> seeing here outlines that pretty strongly. Secondly, as has also been 
> noted here, the HTML output from these tools varies from browser to 
> browser. We could spend a lot of time normalizing after the user is 
> finished editing, but then we're essentially attemping to patch-up 
> everyone's bugs, and as much as I do that all over NW, I try to do as 
> little of it as possible.

OK, you've had way more experience with this than I have. But XHTML does
have several advantages. It is machine readable. It doesn't need
transformation before sending to my most common client - browsers. If
other output formats are desired, there's lots of server-side tools for
transforming it into PDF, Word, plain text, etc. And I don't really
agree that it's ambiguous. Or at least it need not be, if suitable
constraints are placed on the editor.

Technically, the problem with browser differences appears to stem from
the editor using execCommand() to add markup. If it manipulated the DOM
directly we should get the markup we want, as Andrew's <strong>
workaround shows.

execCommand() appears to have only one advantage for adding tags: it
takes care of undo/redo for you. But since not every command can be done
with it - such as inserting a table - we'd really need our own undo/redo
stack anyway.
 
> All of which leads me to the conclusion that there needs to be another 
> intermediate format. Right now, I think that something like Textile 
> would be an almost ideal representation language. The textbox might 
> be able to work in either "WYSIWIG" or "textile" mode and allow you 
> to switch between them. The essential thing here, though, is to 
> manage the translation between HTML and Textile ourselves in 
> realtime. I know that sounds icky, nasty, and painful, but I will 
> give us output that's somewhat consistent, readable, and 
> transformable (easily).

I'll have a look at how Textpattern handles it then. 

In the meantime I'm not convinced. Lots of people have a basic grasp of
HTML. If they're allowed to go into 'source view' mode, why ask them to
learn a completely new markup language? 

Don't get me wrong, I think we're talking the same thing: limiting how
much crap users are capable of putting into the system. But I also think
that is up to whoever drops the widget on their page, not us.

In a perfect world, I'd like this to be a full-on XML editor. But AFAIK
there's no license-compatible cross-browser XML editor out there.
Bitflux/BXE and Mozile are Mozilla-only. I've still got the old GPL'd
version of Xopus kicking around, but even if I had the time to develop
it further it wouldn't fit with netWindows licensing. And boy, it's a
beast (email me off-list if you want the code).

> Otherwise, it might make a lot of sense to investigate the work 
> involved in just re-doing it.

That might be unavoidable. The reason why I wanted a wrapper, not a
complete rewrite, was for maintainability: when a new browser version
goes and breaks the thing, it's not the netWindows team having to fix
it.

But with HTMLArea, at a minimum I'm going to have to create a subclass
so the toolbar can be separated from the edit window. Not a show
stopper, but work nonetheless. And that's even before I've tried to
expose its events to netWindows - which is where I expect it all to go
horribly wrong :/

I'm going to come up with a skeleton API for the editor that can be used
whether we're wrapping, rewriting or starting from scratch with Textile
markup. Then I'll start filling in the blanks and see how far I can get.

Regards,

Matt


_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org