[mozilla] Rich Edit text box

[Michali]

Hoe zit het nou eigenlijk met de rich edit text functies binnen mozilla?

Op de website van mozilla zijn wel wat instruties te vinden over hoe dit te gebruiken is, maar ik kan er verder dan ook echt niets over vinden. Ik kon er hier ook verder niets over vinden dus vraag ik het zo maar even.

Ook een zoektocht op Google heeft niet mogen baten. In IE weet ik trouwens verder perfect hoe het werkt dus dat is het probleem niet echt. Wat ik ook opmerkelijk vind is dat op de website dit voorbeeld wordt gegeven:

code:

document.getElementById("edit").contentDocument.designMode="on";

Die zet voor contentDocument designMode dus op On ipv. het normale document object. Dit heb ik dus ook geprobeerd zonder enig resultaat. Het artikel is voor het laatst in November 2002 gewijzigd, dus of het nog echt toepasselijk is op de huidige versies van Mozilla vraag ik me ook af.

[Arjan A]

Had je deze link ook gevonden?

Die doet het prima bij mij (FireFox).

[kleautviool]

Ik vind onderstaande links toch duidelijk genoeg hoor. Kan jouw vraag er sowieso uithalen.

http://www.mozilla.org/editor/midas-spec.html
http://www.mozilla.org/editor/midasdemo/

[ToBe]

Hier heb ik er nog 1 tje die in IE en MOZ werkt. Ik gebruik hem zelf voor een project van mij.

[mullah]

ToBe schreef op 15 mei 2004 @ 08:27:
Hier heb ik er nog 1 tje die in IE en MOZ werkt. Ik gebruik hem zelf voor een project van mij.

Persoonlijk vind ik deze ook de makkelijkste...
Het is nog steeds zo dat de rich edit boxjes veel tweaking nodig hebben om in je site geplaatst te worden, vooral als je meerdere op een pagina wilt zetten.

[ToBe]

mullah schreef op 15 mei 2004 @ 10:53:
[...]


Persoonlijk vind ik deze ook de makkelijkste...
Het is nog steeds zo dat de rich edit boxjes veel tweaking nodig hebben om in je site geplaatst te worden, vooral als je meerdere op een pagina wilt zetten.

Ik vond deze erg goed te doen. Makkelijk aan te passen en dingen die je niet wilt eruit te slopen. Prachtig beestje. Werkt helaas niet in Opera.

[Verwijderd]

mullah schreef op 15 mei 2004 @ 10:53:
[...]


Persoonlijk vind ik deze ook de makkelijkste...
Het is nog steeds zo dat de rich edit boxjes veel tweaking nodig hebben om in je site geplaatst te worden, vooral als je meerdere op een pagina wilt zetten.

Dat is natuurlijk niet waar. Er zijn commerciele Editors op de markt die perfect in elkaar zitten met een perfecte API.

[spam]

Ik ben nu ook bezig met een editor die geschikt is voor Gecko en IE. (De functionaliteit is nog niet groot, maar dat komt omdat er nog niet veel plugins geschreven zijn. Deze editor is plugin based...) Om de editor browser compatibel te maken is het handig dat je een API maakt die de browserverschillen opheft. Zo heb je bijvoorbeeld in Mozilla niet de functie pasteHTML(); in het range object.

Voor mijn editor heb ik dat probleem als volgt opgelost:

code:

NextAvenue.prototype.insertHTML = function(html) {
  // Get the range and selection of the editor that has the focus
  var sel = this.getSelection();
  var range = this.getRange();

  if (this.browser.isIE) { // isIE 5.5+
    if ((sel.type+"").toLowerCase() == "control") {
      range(0).insertAdjacentHTML("beforeBegin", html);
      range(0).removeNode(true);
// Not done yet; pasting the HTML
    } else {
      range.pasteHTML(html);
    }
  } else {
    var o = document.createElement("div");
    o.innerHTML = html;
    range.deleteContents();
    for (var i = 0; i < o.childNodes.length; i++) {
      range.insertNode(o.childNodes[i]);
    }
  }
};

Op die manier kan je voor meer functies eigen functies maken.

[ Voor 5% gewijzigd door Bosmonster op 15-05-2004 17:33 ]

[Bosmonster]

ToBe schreef op 15 mei 2004 @ 12:55:
[...]


Ik vond deze erg goed te doen. Makkelijk aan te passen en dingen die je niet wilt eruit te slopen. Prachtig beestje. Werkt helaas niet in Opera.

Geen enkele editor zal in Opera werken aangezien die het hele gebeuren (nog) niet ondersteunen. Is ook niet zo heel belangrijk aangezien de browser bij 'normale' gebruikers zo goed als niet gebruikt wordt.

Imho is zelfs de moeite voor Mozilla te besparen in veel gevallen. Als een klant al met Mozilla werkt (ik moet ze nog tegenkomen ) dan hebben ze er vast ook wel IE naast om de site aan te passen.

Als ik al zie hoe moeilijk je moet doen voor een simpele pasteHTML heb ik het in ieder geval al gehad met Midas...

[ Voor 37% gewijzigd door Bosmonster op 15-05-2004 17:39 ]

[Verwijderd]

Bosmonster: Vergeet jij niet een heel belangrijke groep gebruikers zonder windows? De groep Mac gebruikers is aanzienlijk. Vaak krijg ik klachten van mensen met Mac computers dat ze geen gebruik kunnen maken van de wysiwyg editors.
Als je Gecko/IE compatibel werkt dan heb je die groep gebruikers iig voor je gewonnen (commercieel gezien).

Dat het ingewikkeld zou zijn ben ik ook niet met je eens, als je de browserverschillen goed kent, dan is het ook makkelijk om functies te maken die die verschillen opheffen.

[Verwijderd]

Je kunt toch ook gewoon execCommand("inserthtml", false, null); (of zoiets dergelijks) gebruiken voor Mozilla?

[mullah]

copy en paste functies zijn uitgezet in midas voorlopig, annoying, maar ctrl+c enzo werken gelukkig wel.

En leuke commerciele editors zijn leuk, maar niet altijd de oplossing, bijvoorbeeld als je geen budget hebt, of in gpl sites bezig bent.

[Verwijderd]

Verwijderd schreef op 15 mei 2004 @ 21:22:
Je kunt toch ook gewoon execCommand("inserthtml", false, null); (of zoiets dergelijks) gebruiken voor Mozilla?

Heb het in de documentatie opgezocht en nee, execCommand kan je niet gebruiken om HTML in te voegen.

/Edit

Documentatie: http://devedge.netscape.com/viewsource/2003/midas/01/

[ Voor 14% gewijzigd door Verwijderd op 15-05-2004 23:23 ]

[Verwijderd]

Mjaa, de documentatie is misschien een beetje slecht, maar hij bestaat echt wel:
http://bugzilla.mozilla.org/show_bug.cgi?id=184509
(dat wat ik deed was helemaal fout, moest iets zijn als execCommand('inserthtml', false, prompt('Enter HTML')), kijk maar naar de testcase in de bug)

[Verwijderd]

Heb het even getest in mijn editor en idd, het werkt. Schijnbaar wel geimplementeerd, maar nog niet verwerkt in de documentatie. Ik pas het overigens niet aan, omdat ik de execCommand functies zoveel mogelijk probeer te vermijden om zoveel mogelijk controle te houden over de werking van de editor.

[Bosmonster]

Verwijderd schreef op 15 mei 2004 @ 18:41:
Bosmonster: Vergeet jij niet een heel belangrijke groep gebruikers zonder windows? De groep Mac gebruikers is aanzienlijk. Vaak krijg ik klachten van mensen met Mac computers dat ze geen gebruik kunnen maken van de wysiwyg editors.
Als je Gecko/IE compatibel werkt dan heb je die groep gebruikers iig voor je gewonnen (commercieel gezien).

Dat het ingewikkeld zou zijn ben ik ook niet met je eens, als je de browserverschillen goed kent, dan is het ook makkelijk om functies te maken die die verschillen opheffen.

Misschien enigszins egocentrisch, maar in onze doelgroep zitten bar weinig Mac-gebruikers, tenzij we een reclame-bureau als klant krijgen. Bij bedrijven in de niet-grafische sfeer wordt er zelden met Macs gewerkt.

Ik ben het wel met je eens dat Mac-gebruikers een belangrijke reden zouden kunnen zijn voor Mozilla support, zeker als je doelgroep veel bij dat type gebruikers ligt. Probleem met Mac is echter wel dat slechts een zeer klein percentage met MacOSX werkt en dan ben je beperkt tot Mozilla 1.2.1, want om een of andere vreemde reden worden er voor MacOS 9 geen binaries meer aangeboden sinds die versie. Mozilla 1.2.1 heeft dus geen Midas support.

[ Voor 13% gewijzigd door Bosmonster op 15-05-2004 23:38 ]

[Verwijderd]

Maar juist de mensen in de grafische wereld willen zulke editors gebruiken. Hoevaak komt het niet voor dat klanten bakken met geld betalen voor een goed ontworpen content management systeem en dat de webdesigner als nog de wijzigingen moet maken...

Misschien zie ik het wel helemaal fout hoor, en is deze groep gebruikers toch erg klein. Maar het staat iig wel professioneler als je editor browser compatibel is.

[Bosmonster]

Verwijderd schreef op 15 mei 2004 @ 23:38:
Maar juist de mensen in de grafische wereld willen zulke editors gebruiken. Hoevaak komt het niet voor dat klanten bakken met geld betalen voor een goed ontworpen content management systeem en dat de webdesigner als nog de wijzigingen moet maken...

Ik snap je logica hier niet. Waarom zouden juist mensen in de grafische wereld zulke editors willen gebruiken? Hebben zij vaker/meer/dynamischer websites dan de rest van het bedrijfsleven?

Juist reclamebureau's (synoniem voor Mac-gebruikers) hebben zelden dynamische websites. Vaak zijn ze niet eens buiten de deur gemaakt maar door iemand door een medewerker die denkt ook websites te kunnen maken.

En ik ben het er helemaal mee eens dat het professionele staat als je editor browser-compatible is. Als je iemand tegenkomt waar het anders niet voor gewerkt had uiteraard. Iemand die IE gebruikt en daarmee het CMS gaat besturen zal er niet over vallen

De vraag is dus heel simpel. Is die minimale doelgroep de moeite van het ontwikkelen waard. Want de tijd die ik steek in het compatible maken van de editor moeten wel terugverdiend worden... en dat zijn heel wat uren. Het gaat namelijk niet alleen om de editor. Denk ook aan dingen als modalDialogs... een enorm voordeel van IE als je het mij vraagt.

[ Voor 33% gewijzigd door Bosmonster op 15-05-2004 23:48 ]

[machuidel]

Probeer deze eens:
http://www.interactivetools.com/products/htmlarea/

Hier een demo met de Tabel editor plugin:
http://www.lutherproducti...xamples/fully-loaded.html

Deze inline HTML editor werkt zowel in IE als in Mozilla (Gecko) en heeft ondersteuning voor stylesheets.

[Verwijderd]

Reclamebureau's designen de website vaak. Voor content management systemen schakelen ze vaak derde partijen in. De klant heeft contact met het reclamebureau. Nadat de website opgeleverd is, zie je vaak dat klanten een tekstuele wijziging gewoon doorgeven aan het reclamebureau, terwijl ze net bakken met geld besteed hebben aan een cm systeem inclusief webeditor. Het reclamebureau werkt op de Mac en zou het geweldig vinden als ze een editor op de Mac zouden kunnen gebruiken.

[Bosmonster]

Eh jakkie.. reclamebureau's moeten geen websites ontwerpen... Daar hebben ze helemaal geen verstand van.

[Verwijderd]

Het is toch geen misvatting dat (web)designers vaak op een Mac werken? Naja, beetje overbodige discussie, Gecko compatibel kan iig nooit kwaad...

[Verwijderd]

Verwijderd schreef op 15 mei 2004 @ 23:36:
Heb het even getest in mijn editor en idd, het werkt. Schijnbaar wel geimplementeerd, maar nog niet verwerkt in de documentatie. Ik pas het overigens niet aan, omdat ik de execCommand functies zoveel mogelijk probeer te vermijden om zoveel mogelijk controle te houden over de werking van de editor.

Dat kan ik me voorstellen, maar het probleem is wel dat execCommand functies zijn te 'undo'-en door de gebruiker en normale dom-methodes niet.

[Verwijderd]

De core van mijn editor heeft een eigen history object. Alle wijzigingen worden daarin bijgehouden. Sorry, geheim van de smit

undo en redo werkt namelijk alleen voor bewerkingen die gedaan zijn met de execCommand functie.

[Bosmonster]

Verwijderd schreef op 16 mei 2004 @ 00:14:
De core van mijn editor heeft een eigen history object. Alle wijzigingen worden daarin bijgehouden. Sorry, geheim van de smit

undo en redo werkt namelijk alleen voor bewerkingen die gedaan zijn met de execCommand functie.

Ligt er volgens mij aan welke undo/redo je aanspreekt. Blijft wel buggy overigens. Hij gaat letterlijk ieder stap undo'en wat tot vreemde taferelen kan leiden.

Wel netjes dat je het zelf opgelost hebt. Ik hoop alleen dat het ook werkt met alle normale acties die een gebruiker kan uitvoeren (toetsenbord combinaties, drag/drop, etc)

[ Voor 30% gewijzigd door Bosmonster op 16-05-2004 00:53 ]

[Verwijderd]

Zal ik het geheim van de smit dan maar gewoon verklappen? Zo geniaal is het nou ook weer niet

Bij bepaalde acties wordt gewoon de complete inhoud van het frame in een Array gepushed. Als je undo doet, dan haalt hij gewoon de vorige data op en zet hij die content weer in de editor waardoor je het undo/redo effect krijgt.
Of het werkt met drag and drop hangt er dus maar net van af wanneer je de inhoud van het frame in de Array pushed.

De undo/redo Array heeft een variabele lengte (te regelen via een xml configuratie bestand). De lengte moet je niet te groot maken aangezien het best nog wat geheugen kan vreten bij grotere pagina's

[ Voor 19% gewijzigd door Verwijderd op 16-05-2004 01:04 ]