Hi
[deleted a lot of FUD[1] spreading...]
> I just want to start a meaningful, yet animated, discussion...
I don't think, you can start such a discussion with a ~300 line bashing
of your "oponent" :) Therefore, I won't waste my time in answering all
your allegations, but anyway, you raised certainly some weak points in
BXE, so I'll try to explain some of them below.
If someone wants to know our position on some points we don't answer
below, just let us know. We certainly don't want to hide anything from
you.
- WYSIWYG
WYSIWYG is a big word, almost like CMS :) ... We see XML not only as a
storage format which replaced some "old" database/template systems (in
perl/php terms), but as a great way to allow more formats besides HTML
like SVG, PDF, WML, RSS etc... And then "real"-html-wysiwyg is suddenly
not thaaaat important, especially not if you are editing content.
Then also, what does real Wysiwyg mean? If you style your XHTML with
CSS or your XML, what's the difference? That's what CSS was invented
for and here Mozilla is on the right track. Btw: the SlideML CSS shows
that by example.
We like sometimes looking in the future - content will be a mix of
XHTML 2.0 with some custom XML, some of your friend's XML, some of
OSCOM's etc. - and still remain conservative on our output for now. So
you could say we are maybe just conservative avantgardists.
- Why the XML/XHTML mix?
The first reason was speed. With this approach, we don't have to do an
XSLT Transformation everytime we change/append/delete a node, but let
the browser do it with it's DOM-tools. This also makes navigation and
inline-xml-stuff much easier to handle. Furthermore, if you just want
to edit your xml and give a shit about html-output, you can take a very
simple xslt, provide a proper CSS and can start editing it.
- Is MSIE really shite?
I can't really judge about DHTML performance and i'm not that excited
about some fancy special effects stuff, but I was just disappointed to
see that MSIE does not support some of the XML stuff I was used from
the W3C specs and using Mozilla. Maybe I have just the wrong impression
what a modern browser should be able to do besides just rendering HTML.
Damn Mozilla, you made me believe there is life after HTML :)
- Why Mozilla?
We really wanted a cross-platform solution and a lot of our customers
are using macs, where MSIE is really no option for something like that.
Therefore we concentrated our efforts on developing a nice, easy-to-use
editor for Mozilla. Besides that, Mozilla is free (in both senses) which
goes very well with our ideals and their developers listen to our
problems (although never tried with the MS developers..).
- Schema
We know, we do not really support schema at the moment, but we always
said, we will improve it. And the current implementation is much better
then the JS-approach before (IMHO)
- XSLT
The same goes here: More XSLT support will come. And you don't need
completely different XSLT/CSS files, they have just to be adjusted. And
after we have more XSLT support, there will be less need of adjusting
the your "standard" XSLT-file. Just give us some time. Furthermore, a
lot of CMS still don't use XSLT for the HTML output, so they have to
write a special XSLT for the Editor anyway.
- Why did we BXE?
When we started with our first Editor (some year ago), there was no
browser-based open-source cross-plattform wordlike (meaning supporting
tables/lists/etc) xml-editor around, so we started our own thing.
That's it. No other reasons...
- Competition
Competition is a Good Thing, also in the Open Source part of the world.
See Linux vs. *BSD, Gnome vs. KDE, perl vs. php vs. python, etc.. I
doubt, that both of our products would be what they are now without
this competition.
- Collaboration
We would have enjoyed a collaboration to join efforts (support both IE
and Mozilla is a tough buisness as you know and shared efforts are
always better than lonesome ones) and asked you twice some time before
the conference. We will take care not doing it again. It was maybe a
little bit vague before we were both going open source, but I really
hoped we could do some stuff together after OSCOM and be it only to try
to get some common interfaces for
plugins/"database"-drivers/api-for-cms/you-name-it on the js/xml level
together. And I agree with you, that our approaches to the solution are
too different to actually merge the two editors.
That's it.
chregu
[1] http://www.tuxedo.org/~esr/jargon/html/entry/FUD.html
--
bx-editor-dev mailing list
bx-editor-dev@xxxxxxxxxxxxxxxx
http://lists.bitflux.ch/cgi-bin/listinfo/bx-editor-dev
|
