RE: should WYSIWYG be HTML based? was:...words from the other side...

This is an answer to Holger's respons regarding whether WYSIWYG should
be HTML or XML based.

I want to make one assumption: we are talking about editing XML
documents that will most likely be published on the internet to be
viewed inside of a browser.

> Let's presume that javascript-based technology is the way to 
> go if you want to connect to other free software projects.

JavaScript technology is the way to go if you want to build a WYSIWYG
editor.
Not because you want to connect to other free software.

Given my first assumption the What You See part of WYSIWYG must be
browser-displayable. An editor will always involve adding some logic to
the display. Ergo: JavaScript.

How else would you render HTML or XML/CSS to get a WYSIWYG view? Only
inside a browser you will get true WYSIWYG. You cannot let Java render
the display of you XML/CSS or DHTML. It can't. The same goes for C++ and
so on.


> Now should we work with XML structures on the client side
> or with HTML structures?   You argue that HTML is better because
> there is widespread quasi-standard support for it.  But the

HTML is the logical choice because HTML is what will ultimately be
published to your viewers.
No one is publishing XML only sites at this moment. Sure, the underlying
data can be stored in XML, but what is send to the browser is always
HTML.
HTML will be the technique for presenting content to end users for a
long time...

> real question to me is: how de we realize a user experience that
> is similar to MS's Wordpad.  The question if i transfer the content 
> using xml or html is a second issue.

Yes it is. But to be able to make it look exactly like what your end
user will see you will need to use HTML, not XML, because your end users
will not see the XML.

Making it behave like Wordpad is a second issue. If you can do that for
XML, then why shouldn't you be able to do it for (X)HTML?


> E.g. how do you handle events, how much access do you have to 
> the screen
> (selections, cursors) how *could* you do a file dialog (inserting an 
> image etc.)?  Questions like these are to be answered if you want

All of this stuff can be done using modern browsers. I don't see the
problem. Why should this be any easier using XML on the client? It's
not. DHTML gives you more possibilities to do smart, dynamic stuff than
XML does. Besides expertise in DHTML is much easier to find than XML.

> to do a client-side WYSIWYG-application that uses a server-side CMS 
> for workflow, collaboration and storage.  Please realize that we
> are talking about one of the next internet revolutions here :-)

I don't know.
I think this will be the next internet evolution. Mark the absence of
the R. It's an evolution, not a revolution.
3 years ago I build my first validating wysiwyg xml editor. People
weren't ready for it then. Nobody had heard of XSLT nor Schema let alone
they were using it.
Now, 3 years later, things have changed: everybody knows about XML, XSLT
and Schema. But still nobody really uses it.

And nobody is really interested in it either. Nobody needs the advanced
stuff BitFlux and Xopus try to do. Everybody just makes an article
containing a title, a subtitle and a body. The body is XHTML: all
structure is free.
So why would you really need a schema to validate this? You don't.

I guess we will have to wait another 3 years.

> one-issue-at-a-time'ly yours, Holger

Single-issuedness enough?

greetings Lon

-- 
bx-editor-dev mailing list
[email protected]
http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-dev