[Alg]Wat missen de bestaande web based html editors?

[Verwijderd]

Een aantal van jullie weten dat ik al lang bezig ben met het maken van een web based html editor. Nu zijn er vele editors op de markt waarvan 95% prut is.
Ik wil graag een discussie starten over de ideale web based html editor. Wat zijn functies die jullie absoluut missen en welke functies zijn compleet overbodig?
Wat is goed aan de bestaande systemen en wat fout?

Als er mensen zijn die dan toch over semantisch correcte code willen gaan blaten: hoe zou je een interface kunnen maken waarin het mogelijk is om semantisch correcte code te genereren?

Ook ben ik benieuwd naar problemen qua integratie en oplossingen daarvoor. Was het moeilijk of juist makkelijk een bepaalde editor te integreren?

Kortom: veel vragen, nog weinig antwoorden.

[NMe]

Het belangrijkste vind ik dat je code moet kunnen valideren tegen de W3C standaarden. Dat moet op zich niet al te lastig zijn, wanneer je geen depreceated tags en attributen gaat ondersteunen. Aparte CSS files lijken me al een stuk lastiger, dus dat kun je het makkelijkste inline houden, voor het grootste deel. Omdat ik je editor al gezien heb weet ik eigenlijk niet veel anders te noemen, althans geen dingen die er al in zitten.

Correcte code is dus in ieder geval het belangrijkste, de rest wijst zichzelf eigenlijk wel.

[BtM909]

Kan je hier wellicht wat tips uithalen: [rml][ CMS] Voor -en nadelen als gebruiker[/rml] ?

Zie nu ineens verbazingwekkend veel topics in WG over CMS

[Verwijderd]

Dat was ook mijn inspiratie. Maar een CMS is geheel iets anders dan een web based editing component. Dat is zoals de naam al aangeeft een component; een vervanging voor de textarea control.
Wel een verwant maar geen "dupe" topic

[Verwijderd]

Je kunt geen semantisch correcte code genereren als de persoon die ermee moet werken niet snapt hoe je tekst hoort op te maken.

Dat gaat jou met de huidige interface ook niet lukken. Knoppen als [B], [I] en [U] zijn eigenlijk uit den boze hè? We gingen betekenis koppelen aan bepaalde stukken tekst, weet je nog?

Mensen moeten bij het opmaken van tekst denken aan het doel. Het doel moeten ze kennen. De middelen volgen daarna. Het punt is alleen dat er verschillende doelen zijn.

Het ene doel is de gebruiker iets voorschotelen wat goed leesbaar en visueel aantrekkelijk is. Het andere doel is de betekenis van de diverse onderdelen van het document verklaren voor bijvoorbeeld zoekmachines en user agents voor mensen met een handicap.

Nu is het zo bedacht dat je HTML dan gebruikt voor het laatste doel, en dat je het met CSS zo bewerkt dat het eerste doel ook wordt bereikt. En het visueel stijlen van bepaalde elementen kan ook nog eens het tweede doel versterken.

Dit is een hoop theoretisch gezwets, laat ik weer een voorbeeld erbij halen. Stel, een gebruiker wil een woord vetgedruk maken. Stop. Lees de voorgaande zin nog eens, en maak hem in gedachte af met het woord omdat erachteraan.

Een gebruiker wil een woord vetgedrukt maken omdat:
• het woord met nadruk moet worden gelezen
• het een label is voor een invoerelement, en dat moet opvallen

Nu ga je dus òf een em/strong element, òf een label element erbij halen. Het tweede doel is bereikt, een automated processor kan de globale betekenis achterhalen. Nu moet je het woord nog vergedrukt maken. Bij een strong element ben je klaar, bij een label element moet je nog wat toevoegen, en bij een em element moet je wat ongedaan maken en wat toevoegen.

Dat wil niet zeggen dat om een woordt te benadrukken èn om een woord vergedrukt te maken, het altijd het verstandigst is om een strong element te gebruiken. Het kan ook zijn dat er iets is dat nog sterker benadrukt moet worden, en wat ook nog eens knalrood moet zijn. In dat geval gebruik je em voor de benadrukte, vette tekst, en strong voor de sterk benadrukte, rode, vette tekst.

Niet vergeten: een user agent past meestal wel een eigen stylesheet toe. Maar dat wil niet zeggen dat je het daar altijd mee eens moet zijn. Zoms moet je wat standaard style properties ongedaan maken en grijpen naar andere methoden om je doelen te bereiken.

Volgens mij is het je tijdens het lezen van deze lap tekst wel duidelijk geworden dat je met een simpele WYSIWYG component nooit kan bereiken dat er senamtisch correcte markup uit komt zetten als de gebruiker alleen maar denkt aan het uiterlijk.

[Verwijderd]

Dit verhaaltje semantiek is mij al lang bekend. Ik zit meer te denken aan implementaties. Hoe kan je de gebruiker zo sturen dat hij gedwongen wordt na te denken over de betekenis.
Die bold, italic en underline knopjes kan je eenvoudig vervangen. Dat zijn slechts plugins, het gaat mij meer om het algemene doel. Ik zelf heb eens wat gebrainstormt over een soort dropdown menu met daarin voorgedefineerde acties: titel, subtitel, tekst, nadruk, extra nadruk, paragraaf etc etc etc. Zo'n systeem lijkt me veel beter en zorgt er voor dat de semantiek beter in elkaar zit. Natuurlijk zijn hier ook weer gevallen te verzinnen waarbij je de boel in de soep kan laten lopen, maar over het algemeen zal je HTML er zo een stuk netter uitzien.

Laat ik wel vooropstellen dat ik een editor wil maken waarmee semantisch correcte code gemaakt kán worden. Of er daadwerkelijk semantisch correcte code uitkomt is aan de gebruiker.

Je kan namelijk nooit een editor maken die gegarandeerd semantisch correcte code uitspuugt. Ik hoef denk ik niet eens uit te leggen waarom.

Kortom: wat zijn goede functies in een editor die het stuurproces verbeteren?

[Verwijderd]

Vanuit het gebruikersoogpunt gezien, en wat mijn klanten vaak verlangen.

- de editor moet snel laden, multithreading in javascript is in zo'n geval wenselijk
- de editor moet foutloos zijn, en niet zoals htmlArea die echt zo ontzettend buggy is. Gebruikers raken direct gestressed als ze vreemde meldingen krijgen. "Oh wat heb ik nou weer gedaan, help!".
- gebruikers willen tabellen aanmaken, makkelijk, en heel basic
- gebruikers willen vanuit MS Word tekst plakken. Nu kun je hoog en laag springen, over of het verstandig is, de gebruikers willen het. Taak dus om te zorgen dat de te plakken tekst goed gefilterd wordt.
- gebruikers willen een MS Word vergelijkende spellingscontrole

Als developer zie ik graag:

- uitbreidbaarheid van de editor moet redelijk bereikbaar zijn
- bugs zijn er altijd, als ik ze moet fixen moet de code duidelijk zijn, en niet voorzien van var a=1, of var vdhf = 2. Duidelijk variable benaming dus
- Zelf diagnose. Ik heb dit zelf gebruikt in mijn treeview ding, als er een fout is, geef duidelijk aan waar de fout is, wat de reden van de fout is, wat er werd verwacht en wat de arguments waren. Dit scheelt later zo enorm veel debug tijd.
- multilingual voorbereid, eenvoudig te bereiken door iig de labels al in een struct te plaatsen.
- mogelijkheid om meerdere instanties aan te maken van een editor op dezelfde pagina
- verkrijgen van alle links in een editor, evt. zelfs met javascript lookups maar dat is echt enorm complex omdat het vaak afhankelijk is van de logica of variables die op hun beurt ook weer op logica zijn gebaseerd. Ik heb het een keer geprobeerd, maar het is echt heel complex.
-

[ Voor 4% gewijzigd door Verwijderd op 06-09-2004 22:08 ]

[Johnny]

Wat ik mis is een universele koppeling tussen webbrowser en editor waarmee je dus vanuit iedere WYSIWYG of text-editor content kan maken die weer naadloos in het CMS kan worden verwerkt.

Met andere woorden, je stuurt vanuit het CMS de gebruiker naar een speciale URL, met een eigen protocol. De browser laat het protocol afhandelen door het daarvoor ingestelde programma, je krijgt he favoriete teksteditor waarmee je de inhoud kunt bewerken, en je drukt op de save knop en het wordt weer naar het CMS terug gestuurd en intussen omgezet naar valid (X)HTML als dat nog niet gebeurd is.

[Verwijderd]

Verwijderd schreef op 06 september 2004 @ 22:07:
...

Ik ben zelf nu bezig met een algoritme voor Gecko om tabelcellen te kunnen slepen. En geloof me, het is verrekte irritant. Het slepen van tabellen en zoals je zelf al aangeeft MS Word knip plak mogelijkheid is zeer belangrijk. De paste plugin moet er dan gewoon een paar regexen overheen gooien.
Spellingscontrole is op zich een pre, maar wordt lastig te implementeren wanneer je platform onafhankelijk wil zijn.
NextAvenue bijvoorbeeld is 100% javascript code met uitzondering van het upload bestand voor de afbeelding manager.

Alle dingen die jij vanuit de developerskant aangeeft vind ik ook zeer belangrijk. Een editor moet uitbreidbaar zijn door middel van een simpele API. Een framework moet dus alles afhandelen. JS code moet niet obfuscated zijn, maar mag best gecrunched zijn. Zelfdiagnose, oftewel een goede error management is ook essensieel. Wanneer bijvoorbeeld een plugin een fout vertoont, moet er direct een message verschijnen: wie, wat, waar.

Wat je bedoelt met het verkrijgen van alle links is mij niet duidelijk. Dat is toch erg eenvoudig? Je kan tenminste in NextAvenue gewoon een nieuwe plugin aanmaken, knopje toevoegen, code aan knopje toevoegen en klaar is kees. Ik weet niet precies wat je wil bereiken en waar het probleem zit en wat het nut is.

code:

    ...
    <code>
      <![CDATA[
        nextavenue.history.save();
        nextavenue.getFrame().document.getElementsByTagName("img");
      ]]>
    </code>
  </command>

Kortom wat ik wil zeggen: een goede API is echt van levensbelang. Snel en eenvoudig nieuwe opties kunnen toevoegen.

Johnny schreef op 06 september 2004 @ 22:07:
Wat ik mis is een universele koppeling tussen webbrowser en editor waarmee je dus vanuit iedere WYSIWYG of text-editor content kan maken die weer naadloos in het CMS kan worden verwerkt.

Met andere woorden, je stuurt vanuit het CMS de gebruiker naar een speciale URL, met een eigen protocol. De browser laat het protocol afhandelen door het daarvoor ingestelde programma, je krijgt he favoriete teksteditor waarmee je de inhoud kunt bewerken, en je drukt op de save knop en het wordt weer naar het CMS terug gestuurd en intussen omgezet naar valid (X)HTML als dat nog niet gebeurd is.

Ik zie niet echt in wat dit te maken heeft met de editing component zelf. Dat is toch de taak van de programmeur hoe hij de component gebruikt? Hoe hij zijn achterliggende systeem programmeert.
Je kan in de meeste editors gewoon HTML ploppen, editen en op een knop op de pagina klikken om de content weer terug te sturen. Of begrijp ik je verhaal niet?

[ Voor 41% gewijzigd door Verwijderd op 06-09-2004 22:18 ]

[Verwijderd]

Verwijderd schreef op 06 september 2004 @ 22:15:
Wat je bedoelt met het verkrijgen van alle links is mij niet duidelijk. Dat is toch erg eenvoudig? Je kan tenminste in NextAvenue gewoon een nieuwe plugin aanmaken, knopje toevoegen, code aan knopje toevoegen en klaar is kees. Ik weet niet precies wat je wil bereiken en waar het probleem zit en wat het nut is.

Het verkrijgen van links is in zoverre belangrijk dat ik links kan indexeren om deze vervolgens op een later tijdstip te controleren in mijn cms. Ik wil bij het verwijderen van een artikel kunnen controleren of er een relatie ligt in een ander artikel naar dat artikel toe.

Het is handig als je dan

var aLinks1 = editor1.getLinks();
var aLinks2 = editor2.getLinks();

kunt uitvoeren ipv je eigen functies schrijven om door alle anchor tags te loopen.

Het wordt pas interessant, als je zoals ik bedoelde, ook in javascript code links kunt vinden. window.open('abcd.html') is nog makkelijk te vinden. Het wordt anders bij window.open(url);

De variabele url is wellicht gedefinieerd als var url = 'abcd.html'; maar kan ook op ontelbare andere manieren zijn gemaakt. Eigenlijk moet je daarvoor een javascript functie uitvoeren als var mylink = url; maar dat werkt weer niet als je url in een loop wordt gezet. kortom serious complex shit.

[Verwijderd]

in plaats van "i", "b" en "u" knoppen kan je best "nadruk" "kop" en "label" knoppen maken, oid. Dingen die dus dichter bij de uiteindelijke betekenis van het element staan. Het is van heel groot belang dat gebruikers een kleine inleiding krijgen in html (en semantiek, maar imho hoort dat impiciet bij html). Ook in word kan je koppen maker door een grote fontsize en een een bold lettertype te kiezen, maar de correcte methode is heading zoveel kiezen uit de opmaakstylen.

Ik ben echt tegen tabellen in RTE's omdat die dingen in de praktijk voor allerlei ranzige opmaakdoeleinden worden gebruikt (zoals plaatjes uitlijnen enzo). Hier moet iets anders voor aangeboden worden met een berichtje dat alleen tabulaire data hier thuishoort.

(nested) lists zitten er standaard wel in heb ik het idee, dat wil dan zeggen de ul's en de ol's. dl's zie ik weer zelden dit zou imho een mooie toevoeging zijn, mits de gebruker goed verteld wordt waar het voor dient (want die dingen zitten niet standaard in word)

knoppen voor "code", "em", "strong", "var", "dfn" etc zijn denk ik wel nuttig, desnoods vertaal je ze in het nederlands, maar zo sta je dichter bij de uiteindelijke html en zullen je gebruikers de bedoeling ook eerder snappen gok ik

[Johnny]

Verwijderd schreef op 06 september 2004 @ 22:15:
[...]

Of begrijp ik je verhaal niet?

Ja, je begrijpt het niet.

Zoals Gordijnstok al zij willen gebruikers alles kunnen wat ze in hun eigen teksteditor (meestal Word) ook kunnen. Hoe hard je het ook probeert, het is ondoenelijk om zoiets in een browser te doen, en al helemaal in alle browsers.

Wat ik zou willen is een apart CMS protocol. Dat protocol zou beveiligd moeten zijn, en een aantal CMS specifieke features moeten hebben met betrekking tot het beheren van inhoud, bijvoorbeeld het locken terwijl een item in is.

Als je met de browser een CMS url tegenkomt moet deze automatisch een programma starten wat hier mee om kan gaan, net als wanneer je op een mailto: link klikt. Je zou het met een tekst-editor kunnen doen als je HTML wilt editen, of MS Word 2007 als je WYSIWYG wilt, zolang het programma maar met het protocol om kan gaan.

Je zou het edit-gedeelte van het programma ook kunnen embedden in de pagina als een <object>.

In het protocol zou je ook allerlei eisen moeten kunnen vaststellen (HTML formaat, encoding, gebruik van externe media) waaraan de content moet voldoen.

Het gaat er om dat je de editor uit de browser haalt, want een browser is geen editor, en aangezien er ook steeds meer alternatieve browsers komen op nog meer alternatieve apparaten lijkt dit me de beste oplossing, want asl het een webbrowser kan draaien, dan kan het ook een teksteditor draaien.

[Verwijderd]

Johnny schreef op 06 september 2004 @ 22:41:
[...]


Ja, je begrijpt het niet.

...

Ik snap nu waar jij op doelt, maar daar gaat deze discussie niet over. Deze discussie gaat over browser based wysiwyg editing componenten en hun gebreken. Zoals Gordijnstok aangaf, mist hij de getLinks functie. Nu ben ik de beroerdste niet en zal ik die functie er wel even in rammen.
Browser based html editing kan veel beter naar mijn mening. Als de eindgebruiker veel beter gestuurd wordt door de GUI, dan is het naar mijn mening mogelijk hem/haar semantisch correcte html te laten maken.
Deze discussie gaat dus niet over fancy DW achtige editors met een eigen wysiwyg:// protocol achtig iets...
Enkel en alleen web based editing componenten die je kan integreren in je CMS ter vervanging van de traditionele textarea control.

[Clay]

Het meeste in die wysiwyg dingen is poeha. Ik zou eerder vragen wat er allemaal uit geschrapt kan worden dan wat we missen. Wat ik van een webbased html editor verwacht is dus eigenlijk zo weinig mogelijk.
Fonts, groottes en kleuren mag je daar helemaal niet opgeven. Dat doet of doen de stylesheet(s) van de applicatie zelf wel, weghalen dus die opties. Zo kan je een heleboel opties wegpraten waarna er maar een klein aantal buttons overblijft. Bold en Italic (Of Strong en emphasized, wat jij wil). Ook al weten de meesten die dat CMS komen te gebruiken niet wat de semantische principes erachter zijn, het zal vaak wel redelijk goedkomen
Lists, eventueel een definition list, links maken (met wizards voor popups etc.) Images includen, en dan nog de wat complexere dingen;

- Table editor. Waar je die table ook maakt, excel of word, of het ding zelf.
- Paste uit MS Office applicaties. Oldsk00l regexp filteren gewoon.
- MaakMijnLinksNietAbsoluut filter voor IE. !&@^%*&^$!!
- Xhtml filter (en evt xml check), ook regexp.
- Source mode, om toch te kunnen htmllen (en syntax highlighting!)

Dergelijke filters zou ik dus zonder pardon alle style="" attributen, font, center, span en andere troep laten weghalen.

De vraag is natuurlijk wel hoeveel je in dat wysiwyg ding gaat editen. Als een hele pagina in 1 keer editable is hoef je er niet meer op 1 pagina te kunnen runnen, en als je in je interface een andere manier van images in je content includen hebt ontwikkeld hoeft je wysiwyg ding dat ook niet te kunnen. Wat wel en niet hoeft kan je dus niet zomaar algemeen stellen.

Het "het moet er als word uitzien" argument vind ik ook maar ten dele waar. Presentatie zit in de CSS, en een site heeft een huisstijl waar je je aan dient te houden. Ook een klant kan je best wel uitleggen dat data en presentatie gescheiden zijn, en dat het daarom toch iets anders dan word gaat werken, en er dus geen comic sans gekozen kan worden.

[Rhapsody]

Als je naar Word compatibility kijkt, kun je heel veel info halen uit de RTF manual op MSDN.

Misschien kun je door een goede parser te schrijven Word documenten omzetten naar XHTML.
RTF zit niet zo heel ingewikkeld in elkaar, het is alleen eventjes werk om het uit te zoeken.

Dit is misschien niet wat je wil, maar het is wel erg makkelijk voor eindgebruikers.

[Verwijderd]

Clay schreef op 06 september 2004 @ 23:04:
...

De vraag is natuurlijk wel hoeveel je in dat wysiwyg ding gaat editen. Als een hele pagina in 1 keer editable is hoef je er niet meer op 1 pagina te kunnen runnen, en als je in je interface een andere manier van images in je content includen hebt ontwikkeld hoeft je wysiwyg ding dat ook niet te kunnen. Wat wel en niet hoeft kan je dus niet zomaar algemeen stellen.

...

Ik ben van mening dat alleen de content in de body tag van belang is. Je gebruikt een RTE alleen om bepaalde gedeeltes van een pagina mooi op te maken. Een complete pagina maak je er niet mee.

Ik ben het er ook mee eens dat Font en Color over boord gegooid moet worden, maar voor de echte pruts0rs moet wel de mogelijkheid zijn om die opties tóch via de API toe te voegen (twee woorden: klant, koning).

- MaakMijnLinksNietAbsoluut filter voor IE. !&@^%*&^$!!

Voor zover ik weet doet IE dat niet automatisch. Ligt er aan op de manier waarop je links toevoegt aan je content. Ik zal er eens wat mee gaan testen, misschien is het toch mogelijk dat je absolute url's krijgt.

XHTML. Dat is een leuke. In gecko geen probleem. Mijn editor levert nu regelmatig HTML code op die lekker valideert. Maar IE daarentegen is een ramp. P die niet wordt afgesloten, LI die niet wordt afgesloten enz.
Ga dat maar eens corrigeren. Dan is er een DOM methode om gewoon door alle nodes heen te lopen, maar dat gaat fout wanneer je HTML verkeerd genest is:

<b>foo<i>foo</b>blaat</i>

Door je DOM tree heen wandelen gaat nu fout, omdat IE er soep van heeft gemaakt. Zelf heb ik al enkele malen een poging gewaagd om een correctie algoritme te schrijven, maar de uitzonderingen op de regel zorgen altijd voor 97% dekking en in de overige 3% werd de HTML verklooid
XHTML code uit IE toveren is erg lastig heb ik ervaren.


Over het RTF verhaal: volgens mij zijn .doc bestanden niet in het RFT formaat. Met Word kan je wel bestanden opslaan als RTF, maar dat doet hij niet standaard. Dan kan je net zo goed van een klant vragen dat hij het opslaat als HTML, die je vervolgens gaat parsen en corrigeren.

[Clay]

Voor zover ik weet doet IE dat niet automatisch. Ligt er aan op de manier waarop je links toevoegt aan je content. Ik zal er eens wat mee gaan testen, misschien is het toch mogelijk dat je absolute url's krijgt.

Klopt. Ik kom het vaak met images en links tegen, maar eigenlijk alleen als je schakelt tussen (ingebouwd) wysiwyg mode en html mode. (innerText = innerHTML en vice versa, in moz ietsie anders)

Ga dat maar eens corrigeren. Dan is er een DOM methode om gewoon door alle nodes heen te lopen, maar dat gaat fout wanneer je HTML verkeerd genest is: [...] XHTML code uit IE toveren is erg lastig heb ik ervaren.

Yup is best pittig. Maar ik doe het dan ook niet met door de dom lopen (die is immers fout). Met regexp en een tree/stack die je zelf bijhoudt om nesting te corrigeren is het te doen. Maar makkelijk is het niet nee.