Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Mozilla The Internet

Bringing WYSIWYG Content Editing To Mozilla 33

whythewig writes "Over the past month two open-source wysiwyg xml editors have appeared - Xopus from Q42 and the Bitflux editor. Each of these projects tries to bring true wysiwyg editing to Mozilla. From reading various mailing lists it seems that the Wyona project has been instrumental in bringing these two projects out as open source. It also appears that both of these projects will be presented next week at the open source content management conference in Berkeley, California."
This discussion has been archived. No new comments can be posted.

Bringing WYSIWYG Content Editing To Mozilla

Comments Filter:
  • ... but just because open source can do something doesn't mean it should do it.
  • Interesting but... (Score:3, Informative)

    by kawika ( 87069 ) on Tuesday September 17, 2002 @12:11PM (#4274122)
    Spend about 15 minutes editing the Bitflux demo [bitfluxeditor.org] and then navigate off the page with the back button or close the window. You will silently and efficiently lose 15 minutes of work.

    This kind of thing has always been a problem in browser data entry like form posts, but now it's getting more complex and the data is becoming more precious. You can try to mitigate the issue by having an onunload handler, but most ad blockers and other apps like Proxomitron [cjb.net] disable onunload because of its abuse by pr0n and advertising.

    Perhaps if this is only used in an app that uses Mozilla technologies embedded inside it--rather than the Mozilla browser with its standard navigational options--there won't be a problem. But it sure is a problem for the demo.
    • You will silently and efficiently lose 15 minutes of work.

      Not to mention that the 15 minutes really should have been only 2, because even on my Athlon 1.4GHz it takes almost a second for any character I type to appear on the screen. Sorry, but there are some things that Javascript just isn't supposed to do.

      And it doesn't even show a cursor. I totally agree that they should just try to use XUL and other "real" Mozilla stuff -- technology that was actually designed to provide user interfaces of this type.

      The other question is, what's wrong with Mozilla Composer? It's built into the browser, and provides WYSIWYG editing already.
      • by PEdelman ( 200362 )

        Well, as the page clearly mentions, you should turn on "Caret Browsing (hit F7)", otherwise you won't see a cursor.

        I also wonder if the fact that you lose work when hitting the "return" button is because it is only a demo version?

      • by chregu ( 70525 )
        because even on my Athlon 1.4GHz it takes almost a second for any character

        I have no idea, why on some machines it is terribly slow... On every machine i tested it until now, it was quite fast and typing stuff was certainly no problem and didn't take a second per character... (I have "only" a 700 MHz box and it is no problem, otherwise I wouldn't release this demo :) )

        and it doesn't even show a cursor.
        Hit F7...

        The other question is, what's wrong with Mozilla Composer?

        Composer is only able to produce HTML.. But we want XML, any XML. Big difference in my opinion. It gives you a lot more possibilities than just plain old HTML and takes the burden from editors to know HTML.
        • Hit F7...

          Oops, thanks. I have to admit I didn't really read the instructions or the rest of the page, I just tried it out. Besides those issues, I have to say what you have done is pretty damn nifty.

          I still don't know what's making it so slow though. Is there a Bugzilla issue about it - maybe some generic Javascript problem on some machines? Could the fact that I'm running Linux make a difference?
          • I'm developing on linux. Therefore this can't be the problem.. Although, I had the impression it's faster on Windows, but I seldom use Windows, so i can't really judge that.

            If anyone is interested, why it's mozilla only, I just updated our FAQ [bitflux.ch] about that.
    • Spend about 15 minutes editing the Bitflux demo and then navigate off the page with the back button or close the window. You will silently and efficiently lose 15 minutes of work.

      you mean you loose the edited data? Yep, this is not taken care of right now but shouldn't be much of a problem to be implemented. And if you turned of "onunload", then it's really your problem :) Another solution would be, that it saves the content every ~10 minutes to a temporary file on the server. Also not implemented yet :) But contributions are very welcome.

      chregu

  • Weblogging (Score:5, Informative)

    by seanmeister ( 156224 ) on Tuesday September 17, 2002 @12:23PM (#4274248)

    I hope this technology makes it over to weblog sites like Blogger [blogger.com] and Xanga [xanga.com]. Both of those sites have excellent tools for IE, but the Mozilla versions of the same tools completely blow goats.

    Of course, there are always XUL-based alternatives like mozBlog [mozdev.org] and LiveLizard [mozdev.org], or the very excellent Composite [mozdev.org]. Composite's great - it gives you a WYSIWYG editor for any <TEXTAREA> that Mozilla encounters... using it to make this comment :-)

  • I thought I'd ask slashdot what wysiwyg meant, but I decided to ask Google instead and found this whatis? definition. [techtarget.com]
  • If either of these is an adequate replacement for Frontpage, A lot of webmasters will finally kick Microsoft to the curb.
    • Any "webmaster" who uses Frontpage deserves a mercyless beatdown. Both Adobe GoLive and Macromedia Dreamweaver and trillions, if not bajallions, times better then Frontpage. The only WYSIWYG editor that is worse then Frontpage is NetObjects Fusion.
  • I don't understand. Mozilla already has a WYSIWYG editor, Composer. What do these do that is different?
    • Re:Composer (Score:3, Interesting)

      by Thalinor ( 4731 )
      first of all, they do have the potential to be cross-browser (ie 6 and mozilla). second, thanks to the built-in schema validation for xopus your users cannot even apply "wrong" text styles etc, because you can only apply styles that are pre-defined in the stylesheets.

      finally, xopus is arguably more "wysiwyg" than most editors who are nothing more than textareas with some formatting buttons. for instance, the NYT of switzerland, neue zürcher zeitung (nzz) [www.nzz.ch] uses xopus to enter articles. journalists see how their articles flow on the page while they are entering it. quite powerful.

      hope this helps,

      -gregor
    • Composer is just HTML. We (and xopus) on the other hand use any XML for in and output of the actual data.

      Makes it for example much easier to edit structured content... And you have a lot more possibilities to offer to your editors than with just HTML.

      chregu
  • ...and will for the foreseeable future.

    For whatever reason the Mozilla people just don't seem to see the utility in this. Reading through the forums and bugzilla, you'll see dozens of requests for a contenteditable feature, followed by a bunch of waffling about why they can't be bothered (it's usually along the lines of "we're concentrating on end user features"). Meanwhile end users by the thousands are passing Mozilla by because it can't do this.

    I wrote an in browser WYSIWYG editor which can be invoked on any block in a page. It works beautifully. It's 90% cross platform (most of the development was done in Mozilla on Linux). However, it only functions fully in IE because there isn't any good way to create a contenteditable block in Mozilla. You can hack it in (as some projects mentioned here have done, and I've done myself), but it is hackish, doesn't work reliably, and tends to break with new Moz versions. As proof of concept it's fine, but as a production feature it just ain't there.

    Mozilla could make itself the browser of choice almost overnight for potentially millions of users just by making this possible. Why they won't is beyond me, but their stubbornness on the issue is costing them users every day.

    • Unfortunately the link to the bugzilla entry about it is bookmarked on my computer at work, not here at home.

      I was thought it might make it into 1.1, and will likely make it into 1.2. It doesn't appear to be in the alpha release, but the bug still says they're targeting 1.2 for it.
      • ...bug still says they're targeting 1.2 for it

        At one time that bug said it was targeted for 0.9.7, so I don't put too much stock in that. I'd love to see it, but I'll be more surprised if it shows up than if it doesn't.

        It's a shame this has been such a PITA with them; all the pieces appear to be there, they just haven't been put together. I've set out on a number of occasions to see if I could do something myself, but when you look at the sheer amount you need to learn about Mozilla internals just to get started, I just can't justify the time. Not when I have an already working alternative which is available on the OS that the majority of my customers are running anyway.

  • Last I knew, netscape has WYSIWYG HTML editing capabilities... Maybe its time for them to share? :)

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Working...