WYSIWYG Editors in Javascript

[Verwijderd]

Even ter verduidelijking: dit topic is niet bedoelt als grote opsomming van bestaande web-editors. Een lijst kan je vinden op www.htmlarea.com. Wil je geadviseerd worden over een bepaalde editor, dan kan je prima terecht op hun website. Dit topic is bedoelt voor mensen die *zelf* een editor ontwikkelen.

Grondslagen van WYSIWYG Editors in Javascript

Doel van dit topic

Om de week wordt er hier in Webdesign & Graphics wel een vraag gesteld over WYSIWYG Editors. Dit topic zal gaan over veel voorkomende problemen. Bugs in IE en Gecko en hoe je die moet omzeilen. Er zijn testcases te vinden, verschillen tussen Gecko en IE. Kortom hét topic over WYSIWYG editors. Ik wil wel even benadrukken dat dit topic bedoeld is al verzamelplaats van informatie en niet als vraagbaak. Als je een probleem hebt, kan je hier eerst kijken of het een bekend probleem is. Je kan hier teven ook links vinden naar resources omtrent wysiwyg editors. Het is niet de bedoeling om hier vragen te posten.

Wat een WYSIWYG Editor zou moeten kunnen

Wat moet een goede html editor kunnen? Om deze vraag te kunnen beantwoorden, moet je eerst vaststellen welke mogelijkheden de eindgebruiker moet hebben. Een online HTML Editor is bedoeld om content te bewerken. In onderstaand stuk ga ik uit van twee verschillende paradigma's; 1.) De gebruiker wil alleen content bewerken. Het design ligt in CSS vast en de editor moet semantisch correcte HTML opleveren. 2.) De gebruiker wil alles kunnen bewerken, van lettertypes tot achtergrond kleuren. Hij wil een editor die lijkt op Macromedia Dreamweaver. Paradigma 1 Volgens het eerste paradigma moet de gebruiker volledig aan banden gelegd worden. De presentatie van de content ligt vast in de CSS. Deze presentatie is door de designer gekozen met een doel; het weergeven van de content in de huisstijl van het bedrijf. Het is onwenselijk dat gebruikers de vrije hand hebben en de stylesheet naast zich neer kunnen leggen. Dit zou betekenen dat gebruikers van je editor de mogelijkheid hebben om het design naar hun eigen hand te zetten. Bijna iedere editor verkrijgbaar, voldoet niet aan dit paradigma. Wat zou een editor volgens dit paradigma dus concreet moeten kunnen? De editor werkt volgens semantiek. De gebruiker kan uit een dropdown menu de stijl bepalen; Heading, Paragraphs, Blockquote, Quote, Definition Lists, Definition Terms etc. Dat dropdown menu stuurt de gebruiken er legt hem aan banden. De content zal niet verklooid kunnen worden en ziet er altijd uit zoals de designer het bedoeld heeft. Om dit te kunnen realiseren moet de gebruiker een nieuwe manier van denken ontwikkelen. Gebruikers zijn gewend tekst te typen, een lettertype te kiezen, en een lettergrootte. Bijna elke editor werkt immers op deze manier. Gebruikers moeten overstappen op een manier van denken, waarbij ze nadenken over de content die ze willen weergeven. De klant typt een paragraaf, besluit dat hij een titel wil invoegen. De gebruiker moet dan via de GUI kunnen aangeven dat hij een nieuwe titel wilt. De editor moet vervolgens de juiste Hx tag invoegen, eventueel met een standaard tekst die geselecteerd is. Op deze manier dwing je gebruikers na te denken over de content die ze willen presenteren. De layout zal niet meer verklooid kunnen worden en de content zal semantisch correct zijn. Paradigma 2 Volgens het tweede paradigma moet de eindgebruiker veel losser gelaten worden. Bijna elke editor die op de markt is voldoet aan dit paradigma. De gebruiker moet zelfs de achtergrond kleur van een tabel cell kunnen instellen. Semantiek is in dit paradigma van ondergeschikt belang. De gebruiker weet waar hij mee bezig is en zo nodig kan hij in de HTML de nodige aanpassingen maken. De voorbeelden van editors als deze zijn legio, dus verdere uitleg zal niet echt nodig zijn. Welk paradigma is de goede? Dat ligt er maar net aan wat je behoeftes zijn. Er kan niet strak aangegeven worden wat beter is. mening: Mijn voorkeur gaat uit naar editors van het eerste paradigma. Ik bekijk dat dan vanuit commercieel oogpunt; een klant heeft niet genoeg kennis van computers om hem helemaal vrij te laten. Ik wil hem z'n content laten bewerken, maar op een nette manier, zoals dat ook bedoelt is in de standaarden. Ik ben en blijf een semantiekridder. Dat mijn voorkeur uitgaat naar semantiek, wil natuurlijk niet zeggen dat jij ook zo'n editor wil maken. Je moet voor jezelf nagaan wat je behoeftes zijn. Ik kan me best voorstellen dat je voor een hobbyproject liever een editor maakt volgens het tweede paradigma. Ik zou zelf echter nooit in een commerciele toepassing zo'n editor implementeren omdat het gewoon wachten is op problemen.

Verschillen tussen Gecko en Internet Explorer

Ik zou hier een grote opsomming kunnen geven van alle verschillen tussen Gecko en Internet Explorer. Dat doe ik echter niet. Op de website van Mozilla staat perfect uitgelegd wat de verschillen tussen Gecko en Internet Explorer zijn. Een groot verschil is de manier van het benaderen van je Frame document. In IE kan je je frame benaderen met: JavaScript: window.frames["frame_name"].document; frame_name.document; Dit werkt niet in Gecko. In Gecko moet je het contentWindow object gebruiken; JavaScript: document.getElementById("frame_name").contentWindow.document; Deze manier van benaderen werkt in zowel Gecko als IE. Voor de overige verschillen verwijs ik je naar bovenstaand document.

Bugs, problemen, tips en truuks!!!!1111oneoneone

Zowel IE en Gecko hebben hun bugs en problemen. Het is soms handig om te weten wanneer iets fout gaat, wat je wel moet doen en wat je vooral niet moet doen. In de aankomende tijd zal ik hier bugs plaatsen die ik tegenkom. Hopelijk ook met een workaround. Mocht je zelf een bug zijn tegengekomen; laat het dan niet om hem hier te melden. Maak een minimale testcase en plaats het.

Links

The MSHTML Editing Platform in Internet Explorer 5.5 HTML Editing Platform in Gecko Verschillen tussen Gecko en Internet Explorer Using the range in Mozilla Using the range in Internet Explorer

[ Voor 3% gewijzigd door Verwijderd op 06-04-2005 23:37 ]

[Verwijderd]

Om maar ook meteen af te trappen... Probleem, en meteen ook een begin framework...

Probleem
In Gecko heb ik in het verleden problemen gehad om eventlisteners aan het Iframe document
te koppelen. Ze werden gewoon niet uitgevoerd. Ik zag door de bomen het bos niet meer, maar
heb een - ietwat rare/ranzige - oplossing gevonden voor dit probleem.

De HTML bij dit probleem

code:

<html>
  <head>
    <title>Testcase</title>
    <script>

    function addEvent(el, evname, func) {
      try {
        if (el.attachEvent) {
          el.attachEvent("on" + evname, func);
        } else if (el.addEventListener) {
          el.addEventListener(evname, func, false);
        }
      } catch (e) {}
    }

    function rte(name, append) {
      this.init(name, append);
    }

    rte.prototype = {
      // Zullen we een klein beetje OO achtig doen?
      getEditorName:function() {
        return this.name;
      },
      setEditorName:function(name) {
        this.name = name;
      },
      getHiddenName:function() {
        return this.hidden;
      },
      setHiddenName:function() {
        this.hidden = 'editor_data_' + this.getEditorName();
      },
      getWindow:function() {
        return this.window;
      },
      setWindow:function() {
        this.window = document.getElementById(this.getEditorName()).contentWindow;
      },
      getDocument:function() {
        return this.document;
      },
      setDocument:function() {
        this.document = this.getWindow().document;
      },
      update:function() {
        document.getElementById(this.getHiddenName()).value = this.getDocument().body.innerHTML;
      },
      init:function(name, append) {
        this.setEditorName(name);
        this.setHiddenName();
        this.createGui(append);
        this.setWindow();
        this.setDocument();
        this.setEvents();
      },
      createGui:function(append) {
        var hidden = document.createElement("INPUT");
        hidden.type = 'hidden';
        hidden.id = hidden.name = this.getHiddenName();
        append.appendChild(hidden);

        var frame  = document.createElement("IFRAME");
        frame.style.width = frame.style.height = "400px";
        frame.id = this.getEditorName();
        append.appendChild(frame);
      },
      setEvents:function() {
        var d = this.getDocument();
        d.designMode = "On";

        ///*
        d.open();
        d.write("");
        d.close();
        //*/
        addEvent(d, "keyup", function (e) {
          alert("Woei");
        }); 
      }
    };

    window.onload = function () {
      var editor = new rte("editor", document.body);
    }

    </script>
  </head>
  <body>
  </body>
</html>

Oplossing

De oplossing die ik gevonden heb is een lege write uit te voeren naar het document. Wanneer
je de write weghaalt in setEvents methode, dan zal je event niet uitgevoerd worden.

[Clay]

In het rijtje obscure bugs;
Mozilla doet een of andere interne text wrapping als je innerHTML opvraagt/schrijft. Hier kan je b.v. last van krijgen als je in je editor een switch bouwt tussen wysiwyg en source mode. Testcase:

code:

<html>
<head>
    <title> huh? </title>
    <script type="text/javascript">

    window.onload = function() {
        alert('observe ...');
        document.body.innerHTML = document.body.innerHTML; // :?
    }

    </script>
</head>
<body style="white-space:pre;">
    <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. consectetuer adipiscing elit. Suspendisse lobortis iaculis metus. In lacinia.</p>
</body>
</html>

Wat boeit het? nou heel veel, dit eet potentieel namelijk spaties tussen woorden op, en dat wil je niet. Gelukkig zal je dit niet altijd tegen gaan komen, alleen als je teveel met die innerHTML doet. Oplossing is er niet, gewoon uitkijken, testen en workarounds bedenken.

[ Voor 19% gewijzigd door Clay op 05-04-2005 12:52 ]

[Michali]

Verwijderd schreef op dinsdag 05 april 2005 @ 12:35:
Oplossing

De oplossing die ik gevonden heb is een lege write uit te voeren naar het document. Wanneer
je de write weghaalt in setEvents methode, dan zal je event niet uitgevoerd worden.

Deze actie is ook de oplossing voor het bewerkbaar maken van het document en body element in nieuw aangemaakte iframe. Let wel op dat designMode gezet moet worden voordat deze actie wordt uitgevoerd. Internet Explorer maakt anders de iframe leeg op moment dat designMode aan gezet wordt.

[ Voor 3% gewijzigd door Michali op 05-04-2005 13:07 ]

[Wacky]

Is het wellicht mooi/slim om een overzicht te maken van bestaande javascript WYSISYG editors met daarbij aangegeven of ze aan paradigma 1 of 2 voldoen en of ze bijvoorbeeld freeware zijn en welke browsers goed worden ondersteund?

Toevallig, maar ben al een tijdje op zoek naar een (freeware) editor met een eis vergelijkbaar aan paradigma 1 voor in een (commercieel) CMS . Wat me een beetje tegenzit op dit moment is de tijd die gaat zitten in het goed configureren van zo'n editor (o.a. afbeeldingen uploaden e.d.).

[Johnny]

Ik wil ook zoiets als die eerste. Ik ben er wel eens mee bezig geweest met het maken van zoiets, maar echt ver ben ik niet gekomen.

[Vinzzz243]

Wat me handig lijkt is inderdaad een aantal basic functies die je zult gaan gebruiken (ik neem aan dat we ExecCommand gaan vermijden voor meer controle?) opsommen, zonder daarbij te kijken naar meerdere contenteditable frames etc.
Voor startende javascripters is het dan makkelijk om zich een weg te banen door het bos, zonder nevenfuncties (die uiteindelijk veel handiger zijn) te moeten doorspitten

[Reveller]

Wacky schreef op dinsdag 05 april 2005 @ 13:54:
Is het wellicht mooi/slim om een overzicht te maken van bestaande javascript WYSISYG editors met daarbij aangegeven of ze aan paradigma 1 of 2 voldoen en of ze bijvoorbeeld freeware zijn en welke browsers goed worden ondersteund?

Ik zal hier een centraal lijstje maken en gaandeweg uitbreiden. Aan- of opmerkingen? Tik een reply en ik zal de lijst hier updaten

Wellicht zijn de volgende criteria een idee:

• alleen open-source / downloadbare demo editors toevoegen, zodat van de code te leren is
• alleen cross-browser editors toe te voegen

Naam	Paradigma	Opmerkingen	Prijs
FCKeditor	2	Cross-browser. Vanaf versie 2.0 ook (gedeeltelijk) CSS support (dus: type 2)	GPL
QWebEditor	1	Cross-browser	Vanaf $50
SPAW Editor	1	Volgende versie moet ook Gecko gaan ondersteunen	Vanaf € 20
Kupu	1	Kupu is gebouwd om hele documenten te editten	GPL
TinyMCE	2	Nog geen	GPL

[ Voor 25% gewijzigd door Reveller op 05-04-2005 15:11 ]

[Woudloper]

Voor wat betreft het lijstje met editors kan je je nog afvragen of fckeditor niet in beide paradigma's thuis hoort. In de basisvariant is fckeditor wellicht paradigma 2, maar als je gaat werken met custom toolbars e.d. dan kan je er (naar mijn mening) voor zorgen dat hij voldoet aan paradigma 1.

[FendtVario]

@Reveller; hier nog een editor: TinyMCE. cross-browser, GPL.

Laat maar, te laat

[ Voor 24% gewijzigd door FendtVario op 05-04-2005 15:07 ]

[Vinzzz243]

wil toch nog even opmerken wat we dan verstaan onder semantiek. Het gebruik van ExecCommand levert bv <span style="font-weight: bold;"> op, waar <strong> of <b> al beter was geweest.

Voldoen ze dan toch nog aan paradigma 1?

[Wacky]

Kupu ziet er leuk uit, maar mist helaas weer de optie om een map met afbeeldingen door te browsen en zo visueel een afbeelding te kunnen kiezen (zoals SPAW dat wel kan).

[Clay]

Vinzzz schreef op dinsdag 05 april 2005 @ 15:57:
wil toch nog even opmerken wat we dan verstaan onder semantiek. Het gebruik van ExecCommand levert bv <span style="font-weight: bold;"> op, waar <strong> of <b> al beter was geweest.

Voldoen ze dan toch nog aan paradigma 1?

ExecCommand in IE levert naar mijn weten gewoon strong/b etc op. In Mozilla mag je zelf kiezen wat je liever wil door een execCommand met "useCSS" uit te voeren (en wat booleans).

[Vinzzz243]

Clay schreef op dinsdag 05 april 2005 @ 16:08:
[...]


ExecCommand in IE levert naar mijn weten gewoon strong/b etc op. In Mozilla mag je zelf kiezen wat je liever wil door een execCommand met "useCSS" uit te voeren (en wat booleans).

ok true maar geen vervangingen voor execcommand dus...

[ Voor 12% gewijzigd door Vinzzz243 op 05-04-2005 16:12 ]

[Reveller]

Zomaar wat losse gedachten / vragen over (problemen bij het maken van) Paradigma 1 editors:

Als ik het goed begrijp, is een "ultieme" Paradigma 1-editor, een editor die alle stylesheets doorloopt op opmaak classes en deze in een (of meerdere) dropdowns stopt. Naast het kiezen van een stijl kan de gebruiker niet veel meer dan tabellen aanmaken (zonder cellpadding, etc - want staat in stylesheet), plaatjes, links en symbolen invoegen. Alle andere opmaak functies (vet, italic, text-align etc.) staat immers in de stijlen gedefinieerd?

Op het eerste gezicht lijkt me dit eenvoudiger dan een Paradigma 2 editor maken. Immers - de hoofdfunctie van de editor is <span>'s met de goede stijl om te tekst heen te zetten. Of zit ik er nu ver naast?

In het meest ideale geval hoef je geen aparte stylesheets voor de editor aan te maken, maar leest deze de standaard stylesheets van de website in. Mijn belangrijkste vraag is hoe je een script zou moeten bouwen dat een complexe stylesheet doorloopt, bijvoorbeeld:

Cascading Stylesheet:

ul#menu_tabs li#producten a, ul#menu li#producten a {
  color: #cccccc;
}

Hoe voeg je die info toe aan een dropdown waarin de gebruiker een stijl kan selecteren? Of denk ik nu verkeerd? Heeft iemand hier ervaring mee?

[ Voor 9% gewijzigd door Reveller op 05-04-2005 16:42 ]

[Mithrandir]

Reveller schreef op dinsdag 05 april 2005 @ 16:40:
Zomaar wat losse gedachten / vragen over (problemen bij het maken van) Paradigma 1 editors:

[...]

Hoe voeg je die info toe aan een dropdown waarin de gebruiker een stijl kan selecteren? Of denk ik nu verkeerd? Heeft iemand hier ervaring mee?

Je moet het anders zien:

een gebruiker kan allerlei (van te voren ingestelde) elementen aanmaken: <h1>...<h7>, <hr>, tables, misschien nog wat aparte kleur-classes en bold/strong/italic dingetjes.

Als designer moet je er dan voro zorgen dat je de goede stylesheets klaar hebt liggen.

[Verwijderd]

Ik heb bewust geen lijst met editors hier opgenomen omdat het in de devschuur gaat om zelf programmeren. Voor een lijst met editors verwijs ik je naar www.htmlarea.com. Daar staan alle, commerciele en gratis editors opgenoemd. Ik zie niet in waarom we hier nog zo'n lijst zouden moeten plaatsen.

Ik wou van dit topic een topic maken waarin tips en truuks vermeld staan, in plaats van een groot discussie topic. Wanneer we hier gaan discusieren zal het overzicht snel verloren gaan. En dat is het eerste doel van dit topic; gemakkelijk een overzicht van alle problemen rondom editors.

[Verwijderd]

Reveller, je gaat een stap te ver. Volgens het eerste paradigma moet een gebruiker niet alles kunnen. Jij laat een stylesheet zien waarmee je het complete design wil aanpassen, van menu tot producten. Een editor volgens het semantiek paradigma zal alleen content bewerken en zal dus beperkt blijven tot Hx, P, Quotes en eventueel wat DIVs.

Reveller schreef op dinsdag 05 april 2005 @ 16:40:
Als ik het goed begrijp, is een "ultieme" Paradigma 1-editor, een editor die alle stylesheets doorloopt op opmaak classes en deze in een (of meerdere) dropdowns stopt. Naast het kiezen van een stijl kan de gebruiker niet veel meer dan tabellen aanmaken (zonder cellpadding, etc - want staat in stylesheet), plaatjes, links en symbolen invoegen. Alle andere opmaak functies (vet, italic, text-align etc.) staat immers in de stijlen gedefinieerd?

De ultieme editor in mijn ogen weet wat mag en wat niet mag. Wanneer je in een Hx staat moet je daar een P van kunnen maken, maar geen Blockquote. In een Blockquote moet namelijk verplicht een block element staan, terwijl in een P geen block elementen mogen staan.
Van een DT moet je een DD kunnen maken, maar geen Blockquote, Hx, P of whatever. Etc. etc.

Een wysiwyg editor volgens het eerste paradigma is bedoelt om *content* mee te bewerken, en niet het complete design.

[ Voor 61% gewijzigd door Verwijderd op 05-04-2005 17:21 ]

[Verwijderd]

Ikzelf heb een vervanger geschreven voor veel execCommand functies. Ben nu bezig een wrapper te schrijven voor Inline elementen, zodat ik custom semantische elementen kan toevoegen aan m'n editor, die ik niet kan toevoegen met execCommand; ins, del, whatever...
Voor veel mensen is zoiets overkill, maar wil je volledig semantiek gebaseerd te werk gaan, dan moet je wel. Zo behoud je gewoon controle over je editor en ben je niet afhankelijk van de browser zoals Vinzz al terecht opmerkte.

edit:

Hoezo ik weet de edit knop niet te vinden mensen lezen nu eenmaal liever 3 korte berichten, dan 1 lange

[ Voor 14% gewijzigd door Verwijderd op 05-04-2005 17:28 ]

[Vinzzz243]

quist, als je nou eens daar wat code van kon posten (of de gedachtengang die je hebt uitgepluist, dan hebben we hier aan dit topic tenminste nog wat aan ).

Iedereen kan nu toch wel een gratis webeditor beetje kaalplukken en met execcommand de basic stuff doen. Het is juist de uitdaging om daarom heen te kunnen scripten en zelf alles onder controle te hebben (denk/vind ik)

[Verwijderd]

Vinzzz schreef op woensdag 06 april 2005 @ 00:34:
quist, als je nou eens daar wat code van kon posten (of de gedachtengang die je hebt uitgepluist, dan hebben we hier aan dit topic tenminste nog wat aan ).

Iedereen kan nu toch wel een gratis webeditor beetje kaalplukken en met execcommand de basic stuff doen. Het is juist de uitdaging om daarom heen te kunnen scripten en zelf alles onder controle te hebben (denk/vind ik)

Ik vind het geen probleem om ideeen te delen, ik ben alleen niet van plan om al mijn stukken code op straat te gooien. Ik heb ook nog een commercieel belang. Je vraagt de jongens van Parse ook niet of ze react even compleet op straat willen gooien

Ik maak gewoon veel testcases. Probeer veer. Er gaat veel fout, maar soms zit er iets goeds tussen. Bij het ontwikkelen krijg ik ook vaak tips van gebruikers. Let ook gewoon eens goed op de standaarden. Denk bij jezelf; wat hebben de andere editors nog niet en hoe kan ik dat verbeteren?

voorbeeld:
Wanneer je volgens de semantiek werkt, sta je voor een probleem. Je moet de start en end container van de range weten om te kunnen bepalen welke node je moet aanpassen of waar je het nieuwe element moet toevoegen. Internet Explorer kent dat niet. Oplossing? Zelf iets schrijven;

Onderstaande code ben ik niet erg tevreden over. Ik vraag me erg af in hoeverre deze code werkt. Het testen en fine-tunen kost veel tijd. Zal ook nog wel een tijd duren voordat ik helemaal tevreden ben over de code. In princiepe is deze code niet hetzelfde als startContainer en endContainer. Deze code levert de parentNode op van de start- en endContainer. Maar dat is vaak geen probleem. Kopieer de code naar IE en selecteer wat tekst en zie wat er gebeurt.

Deze code is dus een onderdeel om er voor te zorgen dat je het Formatblock ExecCommand kan omzeilen en zo ook custom elementen in kan voegen. Je ziet al dat het erg veel code is, voor een klein beetje functionaliteit. Ik ben alleen van mening dat je er veel tijd in moet steken als je je wilt onderscheiden.

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <title>getBoundingRect testcase for IE</title>
    <script type="text/javascript">

      document.onmouseup = function (e) {
        var sel = document.selection || window.getSelection();
        if (sel.getRangeAt) {
          var r = sel.getRangeAt(0);
        } else {
          var r = sel.createRange();
        }
        var c = new Container(r);
        alert(c.getStart().nodeName + "\n\n" + c.getEnd().nodeName);
      }

      function Container(range) {
        this.range = range;
        if (this.range.getClientRects) {
          this.rects = this.range.getClientRects();
        }
      }

      Container.prototype = {
        getStart:function() {
          if (this.range.startContainer) {
            return this.range.startContainer.parentNode;
          } else {
            return this.getContainer(this.rects[0].left + 2, this.rects[0].top + 2);
          }
        },

        getEnd:function() {
          if (this.range.endContainer) {
            return this.range.endContainer.parentNode;
          } else {
            var lastRect = this.rects[this.rects.length - 1];
            return this.getContainer(lastRect.right + 4, lastRect.top + 4);
          }
        },

        getContainer:function(left, top) {
          var startElement = this.range.parentElement();
          while (startElement && !/^body$/i.test(startElement.nodeName)) {
            startElement = startElement.parentNode;
          }
          return this.findContainer(startElement, left, top);
        },

        findContainer:function(e, left, top) {
          for (var i = 0; i < e.childNodes.length; i++) {
            var o = e.childNodes[i], removeSpan = false;
            if (!o.getClientRects) {
              continue;
            }
            var rects = o.getClientRects();
            for (var j = 0; j < rects.length; j++) {
              if (rects[j].left <= left && rects[j].top <= top && rects[j].right >= left && rects[j].bottom >= top) {
                return this.findContainer(o, left, top);
              }
            }
          }
          return e;
        }
      }

    </script>
  </head>
  <body id="body">
    <p id="first">
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras nunc. Mauris nisl. Ut semper. Donec pellentesque, ipsum a placerat congue, mi metus consectetuer urna, a dictum augue sem pulvinar sem. Donec pede augue, egestas quis, posuere id, accumsan eget, pede. Vestibulum est dui, auctor at, sagittis fringilla, semper ac, nunc. Nullam tellus. Curabitur augue. Donec scelerisque adipiscing tellus. Curabitur ut libero. Curabitur et massa.
    </p>
    <p id="second"><b id="bold">
Nam ac tortor a ligula congue egestas. Integer venenatis. Nunc at purus ac dolor euismod mattis. Suspendisse tortor augue, laoreet ac, porttitor at, bibendum nec, ligula. Proin facilisis sapien sit  <span style="color: #F00" id="span">Curabitur id nunc et est hendrerit congue. </span>Nam dui. Integer ultricies massa sed purus. Etiam et sem vel ante consequat aliquam. Quisque eleifend sagittis eros. Ut eros neque, laoreet pellentesque, sodales vel, pharetra elementum, augue. Sed iaculis sagittis lacus. Donec gravida lacus eu metus. Pellentesque mauris dolor, pretium eu, laoreet nec, sagittis quis, orci. Praesent tempus elit et velit. Aenean blandit accumsan sem. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec sollicitudin sem ac lectus. Aenean vel sem.</b>
    </p>
    <p id="third">
Duis in risus in augue sagittis commodo. Nam nec orci. Vivamus sed sem eu lacus suscipit ullamcorper. Duis nunc neque, suscipit et, ullamcorper a, vulputate at, ante. Etiam sed nisl. Etiam fringilla placerat est. Vivamus vitae leo quis urna semper tristique. Sed quis ipsum non pede imperdiet lobortis. Aliquam volutpat. Ut viverra risus non lectus. Etiam tincidunt lacus sit amet neque. Vestibulum eu tellus eget orci hendrerit suscipit.
    </p>
    <p id="fourth">
In consequat. Sed tristique convallis est. Aliquam eget augue. Vestibulum id mi vitae sem bibendum euismod. Nunc lacinia faucibus ipsum. Donec lectus metus, tempor vel, rutrum id, tincidunt sed, magna. Ut dui tellus, accumsan eu, vulputate et, ullamcorper in, diam. Nam molestie. Nam orci urna, lacinia at, rhoncus id, vestibulum ac, ligula. Nunc a turpis. Vestibulum dolor metus, congue posuere, faucibus in, vehicula ut, enim. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Phasellus lorem. Vestibulum ac sapien vestibulum lacus aliquet vestibulum. 
    </p>
  </body>
</html>

[ Voor 6% gewijzigd door Verwijderd op 06-04-2005 01:08 ]

[Vinzzz243]

Verwijderd schreef op woensdag 06 april 2005 @ 01:04:
Ik vind het geen probleem om ideeen te delen, ik ben alleen niet van plan om al mijn stukken code op straat te gooien. Ik heb ook nog een commercieel belang. Je vraagt de jongens van Parse ook niet of ze react even compleet op straat willen gooien

snap ik, vandaar dat ik zei dat je evt wat gedachtengangen kon plaatsen, maar da heb je dan ook gedaan.

Onderstaande code ben ik niet erg tevreden over. Ik vraag me erg af in hoeverre deze code werkt. Het testen en fine-tunen kost veel tijd. Zal ook nog wel een tijd duren voordat ik helemaal tevreden ben over de code. In princiepe is deze code niet hetzelfde als startContainer en endContainer. Deze code levert de parentNode op van de start- en endContainer. Maar dat is vaak geen probleem. Kopieer de code naar IE en selecteer wat tekst en zie wat er gebeurt.

Deze code is dus een onderdeel om er voor te zorgen dat je het Formatblock ExecCommand kan omzeilen en zo ook custom elementen in kan voegen. Je ziet al dat het erg veel code is, voor een klein beetje functionaliteit. Ik ben alleen van mening dat je er veel tijd in moet steken als je je wilt onderscheiden.

Zelf ook wat functies geschreven, waarom niet elkaar helpen om idd die functies te verbeteren? Ik zal dit weekend eens wat code opgraven...
(of is dit topic daar niet voor bedoeld?

[Verwijderd]

Dit topic is bedoelt om anderen tips te geven en te helpen met problemen. Niet echt om hier vragen te posten, dan verlies je al gauw het overzicht, maar om een database met problemen rondom webeditors op te bouwen en eventueel dus ook om gedachten te wisselen over bepaalde technieken en hoe die beter zouden kunnen.
Ik moet zo een trein halen, zal vanavond even posten hoe je er voor kan zorgen dat je aan de server-side je html krijgt zonder elke 100ms de content naar een hidden textarea te versturen. Dat heb ik trouwens al eerder uitgelegd in een ander topic, maar ik zal het zometeen wat uitgebreider doen.

[Savantas]

Qua editor (paradigma 1) zou ik zeker Bitflux XML editor niet vergeten: http://bitfluxeditor.org (demo hier). Zeker interessant ook de wiki met o.a. info over versie 2.0 (demo hier).

Woops, even overheen gelezen... You need Mozilla...
Ach ja... in ieder geval wel multiOS!

[ Voor 15% gewijzigd door Savantas op 06-04-2005 09:29 ]

[Michali]

Ook een simpele maar mischien toch handige tip. Maak alle buttons mbv. img tags. Dit omdat je geen selectie verliest als je hierop klikt. En die selectie heb je juist nodig om de actie uit te kunnen voeren.

[crisp]

Michali schreef op woensdag 06 april 2005 @ 09:36:
Ook een simpele maar mischien toch handige tip. Maak alle buttons mbv. img tags. Dit omdat je geen selectie verliest als je hierop klikt. En die selectie heb je juist nodig om de actie uit te kunnen voeren.

Zolang je het click-event maar weer cancelled kan je prima buttons of links gebruiken, hoewel dat laatste onzinnig gebruik van de anchor-tag is aangezien die bedoelt is voor navigatie

[Michali]

crisp schreef op woensdag 06 april 2005 @ 10:26:
[...]

Zolang je het click-event maar weer cancelled kan je prima buttons of links gebruiken, hoewel dat laatste onzinnig gebruik van de anchor-tag is aangezien die bedoelt is voor navigatie

Het is mij nog niet gelukt om een event te cancellen. Ik weet niet hoe jij dat doet, maar als ik gewoon de normale uitleg/methodes volg werkt dat gewoon niet. Functies al preventDefault() en properties als cancelBubble en returnValue doen hier niets iig.

[crisp]

Michali schreef op woensdag 06 april 2005 @ 10:44:
[...]

Het is mij nog niet gelukt om een event te cancellen. Ik weet niet hoe jij dat doet, maar als ik gewoon de normale uitleg/methodes volg werkt dat gewoon niet. Functies al preventDefault() en properties als cancelBubble en returnValue doen hier niets iig.

My bad; ik cancel inderdaad helemaal niets; ik zet alleen de focus weer op de (in dit geval) textarea:

HTML:

<textarea id="bar"></textarea>
<input type="button" value="foo" onclick="document.getElementById('bar').focus()">

[raptorix]

Voor alle sites die wij gebruiken zetten we e-webedit pro in, niet goedkoop maar wel erg goed.

[Michali]

crisp schreef op woensdag 06 april 2005 @ 11:06:
[...]

My bad; ik cancel inderdaad helemaal niets; ik zet alleen de focus weer op de (in dit geval) textarea:

HTML:

<textarea id="bar"></textarea>
<input type="button" value="foo" onclick="document.getElementById('bar').focus()">

Ok, dat werkt idd. Ik had hier eerst ook problemen mee, maar toen deed iets anders verkeerd denk ik. De selectie verdween toen toch en de cursor sprong dan naar het begin van het venster.

[Urk]

Kijk anders eens naar de WYSIWYG editor van Google's Gmail. Sinds kort kan je daar rich formatting toepassen.
Neem aan dat Google het wel geschikt heeft gemaakt voor een groot aantal browsers, toch?

[Not Pingu]

Bij het eerste paradigma is het altijd de vraag of het aansluit bij de denkwijze van de gebruiker. Vaak zie je toch dat mensen vanuit Word willen copy-pasten, en daarbij gaan ze al snel met lettertypen en kleurtjes werken. Dat moet je natuurlijk niet hebben als je een strak design hebt waarvan niet afgeweken mag worden. Je zou natuurlijk alle font-tags kunnen strippen enzo, maar er zijn nog veel meer dingen waar je op moet letten.

Maar een semantische editor stelt toch nogal wat eisen aan de gebruiker: die moet maar net weten wat semantisch correct is en wat niet.

[Michali]

Gunp01nt schreef op woensdag 06 april 2005 @ 14:11:
Bij het eerste paradigma is het altijd de vraag of het aansluit bij de denkwijze van de gebruiker. Vaak zie je toch dat mensen vanuit Word willen copy-pasten, en daarbij gaan ze al snel met lettertypen en kleurtjes werken. Dat moet je natuurlijk niet hebben als je een strak design hebt waarvan niet afgeweken mag worden. Je zou natuurlijk alle font-tags kunnen strippen enzo, maar er zijn nog veel meer dingen waar je op moet letten.

Maar een semantische editor stelt toch nogal wat eisen aan de gebruiker: die moet maar net weten wat semantisch correct is en wat niet.

Dat klopt ja. Daarom vindt ik dat er altijd goed uitgelegt moet worden wat de redenaties er achter zijn. Ik ga zelf ook een krachtige filter schrijven omdat ik al merk dat een editor daarop breekt vaak. Of je het nu wilt of niet, zonder goed filter wordt het een gigantische bende uiteindelijk. Dan heb ik liever dat het netjes bijgehouden wordt. Scheelt ook weer heel wat problemen en frustraties bij de gebruiker.

[Verwijderd]

Michali schreef op woensdag 06 april 2005 @ 09:36:
Ook een simpele maar mischien toch handige tip. Maak alle buttons mbv. img tags. Dit omdat je geen selectie verliest als je hierop klikt. En die selectie heb je juist nodig om de actie uit te kunnen voeren.

Het is verstandig om op bepaalde momenten de selection op te slaan in een variabele. Zo heb je altijd de laatste selectie nog in je geheugen staan. Voorkomt problemen die je hierboven noemt. Doe je dat opslaan niet en je gebruikt bijvoorbeeld een dropdown menu, dan kan je dat menu nooit gebruiken om queries over je selection/range heen te gooien.
Kortom: range en selection altijd opslaan op bepaalde strategische momenten

[Verwijderd]

Gunp01nt schreef op woensdag 06 april 2005 @ 14:11:
Maar een semantische editor stelt toch nogal wat eisen aan de gebruiker: die moet maar net weten wat semantisch correct is en wat niet.

Ik ben het niet met je eens. Als een gebruiker een Kop in wil voegen, dan kiest hij uit de dropdown Format: Heading Level 1, of welke naam je die option ook gegeven hebt. De gebruiker ziet vervolgens dat er een Kop ingevoegd wordt, of dat een bepaald element omgezet wordt in een Kop. De leercurve hiervan is minimaal.

Knippen en plakken vanuit Word moeten klanten gewoon niet doen. Het is misschien een beetje bot, maar vertel ze gewoon dat ze dat *niet* moeten doen. Doen ze het wel, dan zijn de gevolgen voor hun.
Het schrijven van een goede Word filter is moeilijk, ik zou haast durven zeggen: onmogelijk.
Ik merk hier al dat er erg gehamerd wordt op zo'n filter, misschien toch verstandig om er eens veel tijd aan te besteden

[Not Pingu]

Verwijderd schreef op woensdag 06 april 2005 @ 23:35:
[...]


Ik ben het niet met je eens. Als een gebruiker een Kop in wil voegen, dan kiest hij uit de dropdown Format: Heading Level 1, of welke naam je die option ook gegeven hebt. De gebruiker ziet vervolgens dat er een Kop ingevoegd wordt, of dat een bepaald element omgezet wordt in een Kop. De leercurve hiervan is minimaal.

En hoeveel mensen gebruiken daadwerkelijk Kop 1? hoeveel mensen zetten een koptekst niet gewoon op Bold en lettergrootte 20?
Mensen zijn gewoon gewend om meer semi-grafisch met Word te werken. Semantiek komt daar helemaal niet bij kijken. Er worden door Word- gebruikers heel veel verschillende manieren gebruikt om een stuk tekst te benadrukken, en dan is het ook nog maar de vraag of er selectief wordt gedaan met het benadrukken van tekst.

Je zult nooit om Word heenkunnen, ten eerste omdat whatever editortje jij schrijft nooit zo lekker werkt als Word en omdat mensen gewoon gewend zijn aan Word. Als je een CMS hebt waarvoor iedereen content kan aanleveren en 1 persoon belast is met het online zetten van die content, dan kun je er donder op zeggen dat die persoon een hoop Word-documentjes toegestuurd krijgt met opmaak erin (not to mention tabellen) die overgenomen moet worden.

Je kunt moeilijk verwachten dat al die Word-documentjes helemaal overgetypt gaan worden of opnieuw opgemaakt. En tabellen enzo zullen zelfs helemaal opnieuw handmatig gemaakt moeten worden. Een tool moet nou eenmaal aansluiten op een bedrijfsproces en op de manier van werken binnen een bedrijf.

[ Voor 53% gewijzigd door Not Pingu op 07-04-2005 10:30 ]

[Verwijderd]

a

Gunp01nt schreef op donderdag 07 april 2005 @ 10:25:
[...]


En hoeveel mensen gebruiken daadwerkelijk Kop 1? hoeveel mensen zetten een koptekst niet gewoon op Bold en lettergrootte 20?
Mensen zijn gewoon gewend om meer semi-grafisch met Word te werken. Semantiek komt daar helemaal niet bij kijken. Er worden door Word- gebruikers heel veel verschillende manieren gebruikt om een stuk tekst te benadrukken, en dan is het ook nog maar de vraag of er selectief wordt gedaan met het benadrukken van tekst.

Je zult nooit om Word heenkunnen, ten eerste omdat whatever editortje jij schrijft nooit zo lekker werkt als Word en omdat mensen gewoon gewend zijn aan Word. Als je een CMS hebt waarvoor iedereen content kan aanleveren en 1 persoon belast is met het online zetten van die content, dan kun je er donder op zeggen dat die persoon een hoop Word-documentjes toegestuurd krijgt met opmaak erin (not to mention tabellen) die overgenomen moet worden.

Je kunt moeilijk verwachten dat al die Word-documentjes helemaal overgetypt gaan worden of opnieuw opgemaakt. En tabellen enzo zullen zelfs helemaal opnieuw handmatig gemaakt moeten worden. Een tool moet nou eenmaal aansluiten op een bedrijfsproces en op de manier van werken binnen een bedrijf.

Gebruikers mogen best in Word hun document opmaken. Dat moeten ze dan wel doen volgens de style dropdown van Word. Word heeft ook de mogelijkheid om volgens semantiek documenten op te maken. Als klanten volgens die manier werken, dan is er geen probleem. Heb uitgebreide tests gedaan hiermee met OpenOffice en tot dusver geen problemen. Zo meteen maar eens aan de slag met Word testen.

Ik ben het met je eens dat een bestaand proces moet aansluiten op nieuwe tools, maar van die regel mag best afgeweken worden. Gebruikers moeten gewoon een andere manier van werken aanleren; via een dropdown met semantische elementen. Ze zullen zelf echt niet weten dat ze werken volgens semantiek, maar werken wel netjes. De enige manier om iets Blauw lettertype 20 bold te krijgen is namelijk alleen door op Format -> Titel te klikken.
Wanneer ze in Word hun documenten al opmaken m.b.v. een stylesheet, dan kan er gewoon geplakt worden, maar anders moet de klant beseffen dat de content er wel eens heel anders uit kan komen te zien.

Ik heb bovendien nog geen enkele editor gezien die *de* oplossing heeft. Sommigen proberen het recht te breien, anderen strippen gewoon alles wat ze niet kennen. Je ontkomt er niet aan dat in een semantische editor er alles anders uitziet. De designer heeft namelijk ooit bepaald hoe een paragraaf er uit moet komen te zien. Als jan met de pet dan opeens helvetica 10pt kiest, dan vloekt dat misschien wel met het design zoals het ooit bedoeld is. Een editor moet altijd de wensen van de designer op volgen en niet die van de klant.
Waarom zou een klant anders nog een website laten ontwikkelen? Ik denk bij grotere bedrijven er veel meer nadruk ligt op de huisstijl van het bedrijf en beseffen de werknemers volgens mij veel beter hoe belangrijk die is en dat daar niet van af geweken mag worden.

[Vinzzz243]

ik ben van mening (en het is al vaker geopperd) dat het ligt aan je eigen opvatting.
Wij gebruiken bv een module, waarbij de klant in een apart invoerveld de titel van een paragraaf moet invullen. Tekst invoer is heel basic, bold, cursief, onderstrepen. Tot nu toe werkt dit prima. Een enkele keer moet je dan je module uitbreiden voor bv tekst in 3 kleuren te kunnen zetten (ook weer door de vormgever bepaalt).

De mogelijkheid om de titel in een apart input veld te zetten kun je natuurlijk ook in de rich text editor zetten, maar ja, in ons CMS heb je dan gelijk een naam voor je paragrafen, zonder dit te moeten rippen uit de rte.

Met andere woorden, iets perfects zal _nooit_ bestaan. Voor ons werkt dit perfect. Je kunt veel onder controle hebben op deze manier. Het enige dat de klant kan vern**ken is door gebruik maken van word-tekst (waar wij overigens ook t advies naar klanten overbrengen om dit eerst als platte tekst te kopieren) en nog erger: tabellen. Maar ook is een goede word-stripper daar een oplossing voor...

[faabman]

Verwijderd schreef op donderdag 07 april 2005 @ 11:07:
Ik ben het met je eens dat een bestaand proces moet aansluiten op nieuwe tools, maar van die regel mag best afgeweken worden.

Die opmerking kun je denk ik beter herformuleren. Nieuwe tools moeten aansluiten op het bestaande proces en _nooit_ andersom. ICT moet altijd als ondersteuning dienen voor de professional die er gebruik van maakt.

Gebruikers moeten gewoon een andere manier van werken aanleren; via een dropdown met semantische elementen.

Daarin heb je naar mijn idee helemaal gelijk en zoals je zelf ook al aangeeft moet de discussie over semantiek niet alleen worden gevoerd over een web-editor, maar veel breder worden getrokken. Microsoft levert eigenlijk altijd wel de mogelijkheid om semantisch juist bezig te zijn, ze maken het alleen (te) makkelijk om de semantiek te laten varen.

Vinzzz schreef op donderdag 07 april 2005 @ 12:01:
(waar wij overigens ook t advies naar klanten overbrengen om dit eerst als platte tekst te kopieren)

Dat advies geef ik zelf ook meestal... Maar eigenlijk is het natuurlijk gewoon van de zotten dat je dat advies geeft. De editor die je bakt moet eigenlijk gewoon om kunnen gaan met de bagger die de gebruiker aanlevert.

Overigens denk ik dat het voor de acceptatie door de gebruiker altijd het beste is om de GUI van je editor aan te laten sluiten bij Word.

[Vinzzz243]

faabman schreef op donderdag 07 april 2005 @ 13:10:
Overigens denk ik dat het voor de acceptatie door de gebruiker altijd het beste is om de GUI van je editor aan te laten sluiten bij Word.

ben jij dan al eens ooit een rte tegengekomen zonder de bekende B, I en U knopjes

faabman schreef op donderdag 07 april 2005 @ 13:10:


Dat advies geef ik zelf ook meestal... Maar eigenlijk is het natuurlijk gewoon van de zotten dat je dat advies geeft. De editor die je bakt moet eigenlijk gewoon om kunnen gaan met de bagger die de gebruiker aanlevert.

het is _meestal_ ook geen ramp als de gebruiker een *vieze* tabel via word in de site zet. Qua uiterlijk kan het best mooi passen. Je probeert echter wel mooie code te toveren.
Omgaan met de bagger kan dus 2ledig worden opgelost.

[ Voor 47% gewijzigd door Vinzzz243 op 07-04-2005 13:19 ]

[alienfruit]

Hmm, iemand enig idee hoe je een editor maakt waarbij je "speciale" tags kan invoeren, wat ik zou graag in een editor links naar andere pagina's kunnen aanbrengen. Maar zonder <a href="" /> e.d. maar bijvoorbeeld via <page:link id="15" /> wat dan later wordt vervangen door de juiste URL, iemand enig idee hoe ik dit het beste kan aanpakken?

Ik dacht aan een regex en createElement()

[Verwijderd]

alienfruit schreef op vrijdag 08 april 2005 @ 11:28:
Hmm, iemand enig idee hoe je een editor maakt waarbij je "speciale" tags kan invoeren, wat ik zou graag in een editor links naar andere pagina's kunnen aanbrengen. Maar zonder <a href="" /> e.d. maar bijvoorbeeld via <page:link id="15" /> wat dan later wordt vervangen door de juiste URL, iemand enig idee hoe ik dit het beste kan aanpakken?

Ik dacht aan een regex en createElement()

Voor zover ik weet is het in Internet Explorer in ieder geval niet mogelijk om custom tags in te voegen. Bovendien snap ik niet helemaal hoe je dit in de editor zou willen visualiseren. Hoe moet zo'n element weergegeven worden? Je kan ook een bestaand element pakken en die een attribuut geven. Wanneer je naar source mode gaat, of de HTML wil versturen naar de server, dan zoek je alle elementen met dat custom attribuut en verander je het element in de vorm die je zelf wilt. Zo zou ik het aanpakken.

[alienfruit]

Uh, dat was onder andere mijn vraag, zo niet echt direct gesteld Maar ik neem aan dat ik beter een anchor-element kan gebruiken met een extra attribuut? Of de "speciale" waarde voor de HREF-attribuut, die ik dan tijdens het opslaan wijzig een bepaalde waarde?

Verder zou ik toch alleen plaatjes, links en vet, cursief en onderstreept willen. Verder niks, iemand enig enige tips hoe je Word kan blokkeren qua knippen-en-plakken?

[ Voor 27% gewijzigd door alienfruit op 08-04-2005 19:16 ]

[Not Pingu]

Enige wat je kunt doen is OnKeyUp alle font tags weghalen e.d., copy/pasten van Word tekst hou je toch niet tegen. Tenzij je copy/pasten in het geheel wilt verbieden, maar dat lijkt me dan weer de verkeerde manier om Word-pasten tegen te gaan

[ Voor 41% gewijzigd door Not Pingu op 08-04-2005 19:49 ]

[djluc]

alienfruit schreef op vrijdag 08 april 2005 @ 19:14:
Uh, dat was onder andere mijn vraag, zo niet echt direct gesteld Maar ik neem aan dat ik beter een anchor-element kan gebruiken met een extra attribuut? Of de "speciale" waarde voor de HREF-attribuut, die ik dan tijdens het opslaan wijzig een bepaalde waarde?

Bijvoorbeeld: <a href="{page:34)">linkje</a> Daar kan een browser wel mee overweg in de editor. In je edit venster kan je deze waarde ook weer omzetten naar bijvoorbeeld een paginanaam zodat de gebruiker er niets van merkt.

[Reveller]

Is er eigenlijk ergens een beginners tutorial (of iets dergelijks) te vinden waarin de basis wordt uitgelegd van het bouwen van een cross-browser editor?

Wat ik ervan begrepen heb, is dat IE gebruik maakt van het execCommand en Mozilla van Midas. Betekent dat, dat je al je functies dubbel moet definieren (dus: if (IE) { // execCommand } else { // Midas zut } ?

Voor mijn eigen website wil ik graag zelf een cross-browser editor bouwen, maar ik wil slechts een beperkt aantal functies (vet, cursief, onderstreept en een dropdown om de goede heading te kiezen).

Ik hoop dat iemand een goede link heeft, want na het lezen van dit en andere topics moet ik zeggen dat het me allemaal wat duizelt

[Verwijderd]

Onderaan mijn openingspost staan wat links die je wel verder op weg moeten helpen. Er blijft echter veel verschil tussen IE en Gecko, dus veel code moet je anders schrijven; start en end container bepalen in IE kan niet op de gangbare manier, daar moet je een hack voor schrijven etc. Zo zijn er wel meer dingen. Je beperkingen liggen voornamelijk in het Range object. Als je zelf een editor schrijft push je die tot het maximum wat mogelijk is. Veel abstracte methodes schrijven die intern de boel afhandelen.
Een pasklare tutorial bestaat er volgens mij niet, en ik voel me ook niet echt geroepen om er een te schrijven. Door gratis editors te bekijken kan je veel leren. Ook loont het om de code van commerciele editors te analyseren (toch niets illegaals neem ik aan, obfuscaten weer leesbaar maken is nou eenmaal niet decompileren?).
Het is een tijdrovend karwij. Mocht je geen bugget hebben, dan zou ik toch eerder een bestaande editor helemaal downstrippen. kijk eens op htmlarea.com voor een overzicht van alle editors.

[Michali]

Even een vraagje. Ik ben op het punt gekomen in mijn CMS om de wysiwyg editor te maken. Er zullen dus wel nog meer vragen komen. Waar ik nu mee zit is dit: ik geef de mogelijheid om een stylesheet op te geven voor het document. Deze wil ik nu dynamisch toevoegen alleen lukt dit niet echt goed. In IE lijkt het hoe dan ook niet mogelijk om elementen aan de hand van appendChild aan de head tag toe te voegen. Ik krijg een error iig. In firefox lukt dit wel, alleen gebeurt er geheel niets. Als ik de DOM inspector kijk, dan zie ik wel dat de stylesheet netjes is toegevoegt alleen heeft het geen effect op het document. Iemand een idee hoe dit op te lossen is?

[Verwijderd]

vraag: hoe dynamisch een stylesheet invoegen

oplossing
Neem de HTML uit deze reply van mij als begin.

Op regel 76 het event eruit slopen; die stond daar alleen voor het probleem in die reply;

code:

        addEvent(d, "keyup", function (e) {
          alert("Woei");
        });

Vervolgens moet de window.onload methode de volgende code bevatten:

code:

    window.onload = function () {

      var editor = new rte("editor", document.forms.formulier);

      // Dynamisch een stylehsheet inladen...
      var style = editor.getWindow().document.createElement('link');
      style.href = 'style.css';
      style.rel  = 'stylesheet';
      style.type = 'text/css';
      editor.getWindow().document.getElementsByTagName('head')[0].appendChild(style);
    }

In mijn mini framework gaat het inladen van een stylesheet op deze manier zonder problemen. Weet je zeker dat je de stylesheet in het contentWindow van je iframe hebt ingeladen? Wanneer je hem namelijk in je root document laadt, dan werkt dat niet door op de HTML in het frame. Zeg maar twee verschillende namespaces (het zijn gewoon twee compleet verschillende pagina's met hun eigen dom).

Hoop dat je hier weer mee uit de voeten kan

[Michali]

Waar zou het aan liggen dat het bij mij fout ging/gaat? Moet je perse een element aanmaken via het document object van de window in het iframe? Bovendien gebruikte ik contentWindow.document.body.previousSibling.appendChild(styleOfLinkElement); In IE krijg ik dan een error. Ook als ik aan body zelf elementen probeer toe te voegen. In Firefox gaat het wel goed alleen heeft het geen effect op het document. En ik weet zeker dat het uitgevoert is op het document in de iframe en niet op de eigen (parent) pagina zeg maar. Ik zal deze oplossing eens proberen zo.

[Michali]

................. Soms heb je van die dingen, dan is het enige waarop je kunt zeggen dit:


Wat er dus fout ging was dat ik als link type 'type/css' meegaf ipv 'text/css'. Ongeloofelijk hoe je daar overheen kunt lezen. Bedankt iig, het is gelukkig opgelost en werkt perfect nu

Edit:

Ik heb nog wat toe te voegen. Ik heb ondervonden dat als je voor een iframe de display css eigenschap op none zet waarna je hem weer zichtbaar maakt, dat hij dan niet meer te bewerken is, ook al staat designMode nog steeds op "on". Om dit te verhelpen moet designMode weer expliciet de waarde "on" krijgen. Dan is de iframe gewoon weer bewerkbaar. Dit is overigens in Firefox het geval. In IE blijft de editor gewoon werken.

[ Voor 51% gewijzigd door Michali op 04-05-2005 19:47 ]

[dev icey]

Nadat ik dit topic gelezen te hebben, ben ik eindelijk begonnen met het zelf maken van een RTE. Als je de volgende link volgt kan je zien wat ik er tot nu toe van gemaakt heb. http://mjacobs.nl/Got/editor/index.php

Maar er zijn toch wel een paar dingen waar ik aan twijfel. Ik heb altijd gedacht dat een RTE maken echt moeilijk zou zijn, maar zeker de basisfuncties, zijn gewoon te simpel voor woorden. Hierdoor heb ik steeds het gevoel dat ik iets over het hoofd zie. Natuurlijk kost het fine tunen van de editor veel tijd. Nog een probleem waar ik tegenaan loop is het volgende: Iexplore en Firefox maken allebei hun eigen html code van de tekst.

Om als voorbeeld het volgende te nemen: test

Iexplore:

code:

<P><STRONG><EM>test</EM></STRONG></P>

Firefox:

code:

<span style="font-style: italic;"><span style="font-weight: bold;">test</span></span><br>

Zeker als de ene gebruiker een site bewerkt met Internet explorer, en de andere persoon firefox, gaat dat een warboel worden, wat het zeker niet overzichtelijker maakt. Gelukkig kunnen beide browsers met elkaars gegenereerde code om, dus dat is zeker niet het probleem. Dit probleem is al eerder in dit topic aangekaart, maar geeft mij niet het bevredigende antwoord. Om alle gebruikers te verplichten bijv. Firefox te gebruiken is niet wat ik wil, het gaat namelijk om een cross-browser editor te ontwikkelen. Hoe is dit probleem dan op te lossen, dat Internet explorer dezelfde code genereerd als Firefox?

Nog een probleem van Firefox is dat deze browser achter elke regel standaard een <br> plakt en niet echt slim te werk gaat. We kijken weer naar:

code:

<span style="font-style: italic;">
  <span style="font-weight: bold;">test</span>
</span><br>

Hier zie je dat Firefox 2 spans gebruikt, voor iets waar je normaliter 1 span zou gebruiken. Is hier ook een oplossing voor?

In iedergeval staat op mijn wishlist, dat je overal in het iframe kan klikken om je cursor te plaatsen achter de laatste letter.

[ Voor 18% gewijzigd door dev icey op 04-05-2005 23:41 ]

[Verwijderd]

Wanneer je gebruik maakt van de execCommand methode zal je inderdaad veel basisfunctionaliteit makkelijk kunnen implementeren. execCommand heeft alleen wel de eigenschap, dat veel methodes controle over je document uit handen nemen. Er zijn slechts een paar commando's die ik gebruik. Voor de overige heb ik zelf een oplossing bedacht om zo controle te houden over mijn document.
De basis implementeren is niet het moeilijkste. Het word ingewikkeld wanneer je je wilt onderscheiden. Implementeer maar een algoritme waarmee je in de editor de tabelcellen realtime kan slepen; breder of hoger maken. Zulke ongein kost echt dagen denkwerk.
Neem bijvoorbeeld je undo/redo functionaliteit. Je hebt totaal geen controle over wanneer er een nieuw history point gemaakt wordt. Bovendien verlies je al het 'geheugen' als je van edit naar source gaat en weer terug.

Oplossing voor je probleem; usecss gebruiken binnen je execCommand.

zie http://nexgenmedia.net/evang/iemozguide/#xml_differences. Even 1 sectie omhoog scrollen. Daar zie je wat uitleg over execCommand en ook usecss.

[ Voor 12% gewijzigd door Verwijderd op 05-05-2005 00:18 ]

[dev icey]

Ik denk dat UseCss inderdaad de beste oplossing is. Mijn bedoeling is vooral een editor te maken, waarvan ik zelf kan leren. Daarom begin ik eerst bij de basis, zodat ik het later makkelijker kan uitbreiden. De execCommand zelf schrijven, gaat mij ver te boven, en op dit moment beschik ik niet de capaciteiten op het gebied van javascript om dat te kunnen maken. Misschien dat je daar nog wat leesvoer voor hebt, om mij op de goede weg te helpen? In iedergeval ben ik blij met dit topic van jou, aangezien het mij een grote stap verder heeft geholpen.

[Michali]

Hoe bouwen jullie de editor eigenlijk op? Geheel gestructureerd of object georienteerd (voor zo ver dat kan)? Persoonlijk ben ik hem nu geheel object georienteerd aan het opbouwen en ik moet zeggen dat dat ook in Javascript erg lekker werkt. Je kunt zelfs inheritence een beetje emuleren puur door het parent object te aggregeren. Ook is polymorphisme goed te doen. Ik ben nog maar bij de basis en heb nu al 9 verschillende classes. Ik probeer ook echt veel aandacht te besteden aan het ontwerp, omdat ik weet dat de code aardig kan groeien en ik wil het graag overzichtelijk houden. Ook denk ik sterk aan de koppeling tussen de verschillende objecten wat er voor zorgt dat het geen gecompliceerde brei wordt. Wat jullie?

[Verwijderd]

Tuurlijk is structuur van je editor belangrijk. De meeste tijd gaat zitten in het ontwerpen van de architectuur. Vaststellen wat je editor moet kunnen en daarna bepalen hoe je dat gaat realiseren. Bij het ontwerpen is het erg belangrijk ervoor te zorgen dat memory leaks zo min mogelijk voorkomen.
Tijdens het schrijven van alle code verdeel ik alle objecten over verschillende bestanden en verschillende mappen; core, util, relaxng etc.
Voor het releasen gebruik ik een tool die ik geschreven heb in C. Met een PHP script zet ik alle Javascript bestanden in een groot bestand. Die tool die ik geschreven heb verwijdert vervolgens alle overbodige rommel;

code:

function foo() {
  /*
   do something
  */
  if (4 < 5) {
    alert('woei');
    return false;
  }
  return true;
}

wordt:

code:

function foo(){if(4<5){alert('woei');return false}return true}

Erg handig voor het comprimeren van je source code.

[ Voor 3% gewijzigd door Verwijderd op 06-05-2005 13:24 ]

[Michali]

Ik ben het zelf ook heel components gewijs aan het opbouwen. Ik ben zelfs zo ver dat ik verschillende onderdelen onafhankelijk zou kunnen loskoppelen, met slechts enkele wijzigingen. Maar dat bewaar ik voor later, want ik weet niet eens of ik dat echt nodig ga hebben. Groot voordeel is wel dat ik alles nu onafhankelijk kan debuggen. Ik werk nu met bestandjes niet groter dan 150 regels code, wat er goed te doen is.

[dev icey]

Om het topic weer even interessant te maken, wil ik graag het volgende aan het licht stellen.

Ik neem hierbij mijn editor weer als voorbeeld: http://mjacobs.nl/Got/editor/index.php

Rechts heb ik een knop gebrouwd die kijkt of waar de pointer in de iframe staat, bold staat ingeschakeld. Als je erop klikt krijg je een alert met true of false.

code:

function checkTextStatus() {
  alert(document.getElementById('edit').contentWindow.document.queryCommandState('Bold'));
}

Toen dacht ik dat het wel leuk/handig zou zijn deze status real-time aan te geven. Oftewel dat als je pointer ergens neerzet, dat de 'B'-knop dan met een border en een achtergrond kleur veranderd wordt. Dit vind ik dus heel handig, aangezien je dan gelijk kan zien of je de knop in moet drukken of niet.

Hoe wou ik dit dus realiseren. De functie checkTextStatus zou dan bij elke keer dat de pointer van plek veranderd(muisklik, onkeypress) aangeroepen moeten worden. Een nadeel, een iframe ondersteund deze events niet, om eerlijk te zijn, iframes ondersteunen geen enkele event. Toen had ik het idee om een 100%/100% div in de iframe te stoppen en de events van de div te gebruiken. Dit werkte, op het punt na dat ik vanuit die div niet de bovenstaande functie succesvol kon aanroepen. Daarna heb ik nog het iframe door een div vervangen, maar die kreeg ik in Firefox (dus wel Iexplore) niet contenteditable. Uiteindelijk heb ik dus de methode die Quist beschrijft gebruikt, na het strippen van een heleboel niet relevante code, ben ik erg tevreden over het resultaat.

Mijn vraag aan jullie is dus, is het wenselijk deze realtime formatting status te gebruiken, ook m.b.t. clientload? Ik hoop dat ik op deze manier misschien nog er iets van leer, en ook jullie ideëen hierover kan horen.

[ Voor 16% gewijzigd door dev icey op 06-05-2005 23:05 ]

[Verwijderd]

Het controleren van bepaalde condities op bepaalde momenten is gewoonweg noodzakelijk. Zoals je zelf al aangaf wil je bijvoorbeeld een bold knop ingedrukt hebben; state gedrag. Tevens wil je weten welke plugins (ik beschouw elke functionaliteit als een individuele plugin) beschikbaar zijn; canacceptcommand.

In pseudo code formuleer je dit dus als;

code:

var bold = editor.commands.new("bold");
bold.canAcceptCommand = function () {
  return editor.state() == "edit" && editor.queryCommandEnabled("bold");
};

bold.state = function () {
 return editor.enablers.isInTag("b"); 
}
bold.run = function () {
  editor.history.save(); // history point aanmaken voor undo/redo
  editor.execCommand("wrap", "b", null); // custom execCommando die om een selectie de b tag zet.
}

editor.commands.register(bold);

Vervolgens moet je editor op bepaalde momenten al je geregistreerde en actieve commands bij langs gaan en daarvan state() en canAcceptCommand() uitvoeren en aan de hand daarvan toolbar items en menu items updaten.

Kortom, je globale idee klopt als een bus. Ik snap alleen compleet niet wat je bedoelt met "Een nadeel, een iframe ondersteund deze events niet, om eerlijk te zijn, iframes ondersteunen geen enkele event.". Dit is gewoon simpelweg onjuist. Een iframe bevat een document waaraan je events kan koppelen. Dus ook een onmousedown of een onkeydown event.

Om terug te komen op de selection checker. Je moet ervoor zorgen dat je op bepaalde momenten de huidige selectie analyseert. Bij een keydown, of keyup? Mousedown? Bij elke toetsaanslag? Bij sommige aanslagen? Alleen wanneer een bepaald commando erom vraagt? Etc.
Je moet dus zelf nagaan op welke momenten je core het beste de selectie kan controleren. Dit moet namelijk niet te vaak gebeuren aangezien het een kostbare operatie kan zijn.

[ Voor 4% gewijzigd door Verwijderd op 07-05-2005 02:30 ]

[Michali]

Ik heb dat component gebeuren inmiddels wat verder uitgewerkt. Ik werk nu via een afgeleide van het Observer pattern om componenten op de hoogte te houden van gebeurtenissen. Alle componenten moeten een notify functie implementeren welke een event parameter meekrijgt. Het hoofd editor object bevat een functie nofityComponents welke ook een event parameter accepteert. Het enige wat die functie doet is van alle componenten de notify functie aanroepen met de gekregen event parameter. Op basis van welke type event de notify heeft getriggerd kunnen componenten bepalen of en hoe ze er op reageren. Zelf kunnen componten op hun beurt de notifyComponents functie ook weer aanroepen met het event type wat het beste past bij de uitgevoerde actie. Zo kunnen ze elkaar dus op de hoogte houden van gebeurtenissen zonder echt te weten dat er een ander component bestaat.

Ik ben nu bezig om alle commands ook los te koppelen van het geheel. Hoe ik dit precies ga doen weet ik nog niet, dat ben ik nog aan het uitdenken. Ik wil ook met status gaan werken. Ik wil bijvoorbeeld dat de align left button op actief staat als de geselecteerde block ook zo uitgelijnt is.

Leuk topic dit moet ik zeggen. We kunnen zo samen het niveau van deze dingen iets omhoog tillen. Beetje ideeën uitwisselen etc.

[dev icey]

Ik heb het nu voor elkaar gekregen dat de Bold, Italic en Underline button real time veranderd worden als je de pointer van plek verwisseld. Als je je pointer nu ergens in de tekst zet wordt er gekeken welke opmaak er is op de plek van de pointer, die opmaak wordt gelijk omgezet in een andere opmaak voor de plaatjes. Dit kan je zien op: http://mjacobs.nl/Got/editor/index.php

Michali schreef op zaterdag 07 mei 2005 @ 12:35:
Leuk topic dit moet ik zeggen. We kunnen zo samen het niveau van deze dingen iets omhoog tillen. Beetje ideeën uitwisselen etc.

Hier ben ik het dus totaal mee eens, vandaar dat je mij vaker updates zal zien posten. Het enige wat ik jammer vind is dat ik mij alle script/programmeer/opmaak talen tot nu toe me zelf heb aangeleerd en daardoor heel moeilijk sommige teksten kan lezen, aangezien ik wel weet hoe ik dingen moet aanpakken, maar totaal de benamingen ervoor niet weet. Op dingen als "afgeleide van het Observer pattern" loop ik dus helemaal stuk. Misschien komt het wel doordat ik er totaal geen code bij zie, en op die manier het niet kan visualiseren. Ik heb begrepen dat je Object Georienteerd aan het scripten bent, dus ik neem aan dat je met componenten de classes/functies bedoelt?

Daarnaast als iemand nog enige documentatie heeft, waar meer staat over de benamingen etc, dan zou ik die graag ontvangen.

[Michali]

Observer is een Design Pattern zoals dat beschreven is in het boek "Design Patterns" (en andere). Het houdt eigenlijk in je een relatie tussen twee objecten wilt hebben (of kunnen hebben) zonder dat het ene object direct weet dat het andere object bestaat. Dit is vooral handig bij het kunnen reageren op bepaalde gebeurtenissen.

Even een stukje voorbeeld code (dit lijkt erg veel op wat ik nu heb dus):"

JavaScript:

function EenComponent()
{
    this.editor = null;
    
    this.initialize = function(editor)
    {
        this.editor = editor;
    }
    
    this.notify = function(eventType)
    {
        // doe iets op basis van het type event
    }
    
    this.doeIets = function()
    {
        // voer de actie uit
        
        this.editor.notifyComponents(Een_Event_Type);
    }
}

function AnderComponent()
{
    this.editor = null;
    
    this.initialize = function(editor)
    {
        this.editor = editor;
    }
    
    this.notify = function(eventType)
    {
        // doe iets totaal anders op basis van het type event
    }
    
    this.doeIetsAnders = function()
    {
        // voer de actie uit
        
        this.editor.notifyComponents(Een_Ander_Event_Type);
    }
}

function Editor()
{
    this.components = new Array();
    
    this.addComponent = function(component)
    {
        component.initialize(this);
        this.components.push(component);
    }
    
    this.notifyComponents = function(eventType)
    {
        for ( i = 0; i < this.components.length; i++ )
        {
            this.components[i].notify(eventType);
        }
    }
}

editor = new Editor();

editor.addComponent(new EenComponent());
editor.addComponent(new AnderComponent());

Normaal zou Editor dus een direct relatie hebben met EenComponent en AnderComponent. Nu echter is deze relatie puur dynamisch en kunnen er componenten toegevoegt worden zo veel je wilt of helemaal geen. Dit maakt voor Editor niets uit. Toch worden alle componenten op de hoogte gehouden van gebeurtenissen. En op basis van de eventType parameter kan dan een actie uitgevoerd worden (of helemaal niets als het te kostbaar is). Het gaat vooral om de functie notify() van alle componenten en om notifyComponents van Editor. Initialize en de andere functie hebben in princiepe niet direct iets met het Observer pattern te maken.

Een component is in mijn ogen (de term wordt ook voor andere dingen gebruikt) in dit geval bijvoorbeeld de format selector waarmee een stuk tekst te formatteren is tot paragraaf of header oid. Ook is de font selector of font size selector een component etc.

Zoek anders een op google wat op over Design Patterns. Er is best wel leuke stof te vinden die ook in javascript best bruikbaar kan zijn. Het gaat immers om de princiepes en niet om de programmeer taal.

[ Voor 11% gewijzigd door Michali op 07-05-2005 18:17 ]

[RwD]

Urk schreef op woensdag 06 april 2005 @ 12:36:
Kijk anders eens naar de WYSIWYG editor van Google's Gmail. Sinds kort kan je daar rich formatting toepassen.
Neem aan dat Google het wel geschikt heeft gemaakt voor een groot aantal browsers, toch?

Ik weet niet of de Gmail rich editor wel zo geschikt is, ik heb even een paar dingen geprobeerd en mezelf die tekst gemaild en het resultaat is precies wat ik verwacht had; niet zo mooi. Maar de Gmail rich editor moet zorgen dat een enkel bestand met een stijl opgemaakt moet worden zonder dat er voorgedefineerde stijlen bestaan want je moet als mailer natuurlijk zelf kunnen bepalen hoe jouw emailtje er uit komt te zien.

Hier nog de tagsoep van Gmail's rich editor functie:

HTML:

<div>thg<strong>gf<em>hg</em></strong><em>fj</em>gfjhgj</div>
<div>hgfjf<font face="courier new,monospace" size="1">gjhfjh</font></div>
<div><font face="courier new,monospace" size="1"></font>&nbsp;</div>
<div><font face="courier new,monospace" size="1">hjhgjg</font><font color="#ffff00"><font face="courier new,monospace" size="1">hkd</font><font style="BACKGROUND-COLOR: #33ccff" face="courier new,monospace" size="1">khd<br>
</font></font></div>
<div><font face="courier new,monospace" color="#ffff00" size="1"></font>&nbsp;</div>
<div><font color="#ffff00"><font color="#cccccc"><font face="courier new,monospace" size="1"></font></font>&nbsp;</font></div>
<div><font face="courier new,monospace" size="1"></font>&nbsp;</div>
<div><font face="courier new,monospace"><font size="1"><font color="#ffff00">hgjhkl </font>dgk</font></font>kg</div>

De elementen zijn wel correct genest, maar er wordt door mekaar gebruik gemaakt van afgekeurde attributen en style attributen. Sommige onnodige elementen blijven bestaan zoals dit stukje waarin compleet overbodige elementen staan <font color="#cccccc"><font face="courier new,monospace" size="1"></font></font>
En tja, die font tag is ook al een tijdje niet meer echt geliefd. Dus kijken naar de Gmail rich editor vindt ik geen goed idee

edit:
Beetje late reactie, want jullie hebben het op dit punt over iets heel anders

[ Voor 22% gewijzigd door RwD op 11-05-2005 12:21 ]

[posttoast]

Ik weet niet of dit de geschikte plek is om dit te vragen, maar het lijkt me wel relevant.

Ik ben zelf met (mijn nog niet zo grote maar wel groeiende kennis van) javascript een simpele editor aan het klussen. Daarbij stuitte ik hierop:

makeLink() en wrapText(). Met name wrapText() vind ik een interessante functie. De persoon die deze code heeft 'bedacht' geeft echter, terecht, aan dat het niet werkt onder Safari. Ik ben zelf nog niet zo ver met mijn JS-kunde, maar is er hier iemand die weet of dit script ook voor Safari geschikt gemaakt kan worden?

[MarkvE]

Vincent Bovelander schreef op dinsdag 17 mei 2005 @ 12:24:

makeLink() en wrapText(). Met name wrapText() vind ik een interessante functie. De persoon die deze code heeft 'bedacht' geeft echter, terecht, aan dat het niet werkt onder Safari. Ik ben zelf nog niet zo ver met mijn JS-kunde, maar is er hier iemand die weet of dit script ook voor Safari geschikt gemaakt kan worden?

Dat komt doordat tot voor kort (2 of 3 weken geleden?) Safari geen WYSIWYG-mogelijkheid ondersteunde, nu is dit echter wel het geval (in ieder geval is er een begin) na een fikse update van deze browser. Dus je hebt goede kans dat het nu wél werkt in Safari.

[r0bert]

Ik heb klein editortje gemaakt, maar zit nog een klein irritant dingetje in wat ik niet voor mekaar krijg, maar wel graag wil. (En was blijkbaar niet de enige)

In de editor kun je een stuk tekst selecteren en dan door op B te klikken deze tekst BOLD maken (duh). Nu wil ik graag, dat nadat er op de B geklikt is, de cursor achter de [ b ] komt te staan. In FireFox heb ik het voor elkaar, maar in IE lukt het me niet omdat ik geen enkel gegeven over de positie van de selectie kan achterhalen. (Leftbound zeg maar, dus positie waar selectie begint of wat dan ook).

Dit heb ik verder wel:

code:

this.setDeselect = function (iPos)
{
            var oRange = this.workspace.createTextRange();
            oRange.moveStart("character", iPos);
            oRange.moveEnd("character", iPos - this.workspace.innerHTML.length); 
            oRange.select();
}

Maarja, ik weet niet welke iPos ik door moet geven.. Wie helpt ?

[ Voor 20% gewijzigd door r0bert op 31-10-2005 12:36 ]

[r0bert]

*kickjeuh*

[r0bert]

lijkt me een probleem wat toch wel vaker voor is gekomen

[r0bert]

Ok, ik beloof, mijn allerlaatste kick (e: Denk je dat ik het leuk vind )

[ Voor 4% gewijzigd door r0bert op 08-06-2005 01:05 ]

[posttoast]

r0bert schreef op woensdag 08 juni 2005 @ 01:05:
Ok, ik beloof, mijn allerlaatste kick (e: Denk je dat ik het leuk vind )

Misschien kun je hier iets mee?

[chielsen]

Misschien een beetje offtopic..

Als ik de source aanpas van de FCK editor, en dan alles in enkele bestanden wil gooien mbv de packager dan werkt de verkleinde versie nog wel in IE maar niet meer in FF.
Iemand een idee hoe dat komt?

[Verwijderd]

Te offtopic. Mail de makers, zij weten er meer van dan wij hier. Dit topic is bedoeld voor mensen die *zelf* een editor ontwikkelen. Helaas pindakaas dus...

[r0bert]

Uh.. sorry chielsen, ik heb je antwoord niet, maar euhm Quist, vind het beter dat ie het hier post dan dat ie er een compleet nieuw topic over opent, niet? Maar je suggestie blijft overeind staan, mail de makers of is er geen supportforum daar? Denk dat je daar meer kans helpt, hoewel je vraag niet erg specifiek is.. of je moet het bedoelen in de trant van, welke bestand kan ik wel weg doen en welke niet..

edi: /zucht

[Verwijderd]

Nee, zijn vraag gaat gewoon heel specifiek over een product van derden. In de faq staat erg duidelijk dat daar geen vragen over gesteld moeten worden. Wij kennen dat script namelijk niet goed en de vraagsteller kan dus beter de makers mailen.
mocht ik het antwoord wel weten, dan had ik het natuurlijk wel gemeld...

[Whiskeyjack]

Het schijnt dat ik de enige ben die op zoek is naar een editor van het type paradigma 2 (als ik het goed begrijp).

Het enige wat ik wil is dat tags een andere kleur krijgen en dat liefst de inspringafstand onthouden wordt (zoals in progam editors als dreamweaver). Het gaat om online XML editing. Iemand die weet of zo'n scriptje al bestaat danwel of dit gemakkelijk te maken is?

[ Voor 3% gewijzigd door Whiskeyjack op 02-07-2005 22:05 ]

[dev icey]

Dit is gewoon eigenlijk gewoon een hele basic editor.
- Tags andere kleur: Dit is gewoon te doen met behulp van syntax highlighting. (bijv. Alles tussen <> andere kleur)
- Inspringafstand: Userdefined: Dit is gewoon een tab aan het begin van elke regel, die je dan vervangt door een aantal spaties die je bij het openen van het document bepaald. Predefined: je kan dit ook natuurlijk doen dmv te kijken naar hoe het document genest is en de childs zitten tov de parents.

Ik weet niet hoe goed jouw programmeerkennis, maar dit zou je zelf kunnen maken.

[Verwijderd]

Hoe langer je zoekt, hoe langer je geen script op maat zult hebben. Stop eens met zoeken, en begin gewoon aan je editor.

[Verwijderd]

Ik ben nou een hele tijd aan het zoeken geweest voor een geschikte WYSIWYG editor. En ik weet nu wat ik wil. Niks bijzonders. Gewoon wat simpele functies.

Het enigste probleem dat ik heb is dat wanneer er een image in de tekst wordt gezet, dat de tekst niet netjes naast het plaatje loopt. Dit is namelijk bij alle editors die ik gezien het gevan.

Ik wil dat de tekst netjes om het plaatje heenloopt. Ik heb genoeg kennis om dit in een editor in te bouwen dus dat is geen probleem maar hoe?

Voorbeeldje :
######## = plaatje

Zo gaat elke editor ermee om, en moet het dus niet.

##########
##########
##########
########## En hier begint dan
pas de tekst. en dat is dus niet
de bedoeling.


########## Maar dit moet er
########## dus gebeuren,
########## zonder dat er
########## tabellen worden
gebruikt. Het plaatje hoeft alleen
maar links, rechts of in het midden
te staan.

[RobIII]

html: <img ... ... align="left">
css: img { float: left; } of .myclass { float: left; }

Komaan, basis HTML....

Verder hoort dit denk ik niet echt in dit topic thuis, tenzij je een WYSIWYG editor aan het maken bent (in which case ik weer niet begrijp waarom je de basis niet beheert)

[ Voor 81% gewijzigd door RobIII op 04-07-2006 01:46 ]

[Verwijderd]

Ik zie nu wat het probleem was. Ik snap dat wanneer je een align gebruikt dat het dan goed zou moeten komen. Maar wanneer je dus geen height en width gebruikt. dan gaat het dus niet lukken. Wist ik veel. Nu nog iets zoeken dat dat uitrekent in javascript. Maar in ieder geval bedankt.

[RobIII]

Verwijderd schreef op dinsdag 04 juli 2006 @ 02:36:
Ik zie nu wat het probleem was. Ik snap dat wanneer je een align gebruikt dat het dan goed zou moeten komen. Maar wanneer je dus geen height en width gebruikt. dan gaat het dus niet lukken. Wist ik veel. Nu nog iets zoeken dat dat uitrekent in javascript. Maar in ieder geval bedankt.

myimg.width en myimg.height
Gewoon properties van het image object hoor

[ Voor 12% gewijzigd door RobIII op 04-07-2006 03:09 ]

[Michali]

Hoezo wil het niet lukken als je geen height en width gebruikt? Dat zou gewoon moeten werken, hier wel iig.

[BtM909]

Tijdelijk even dicht

[ Voor 3% gewijzigd door BtM909 op 04-07-2006 14:28 ]