Wil jij jouw ervaringen delen met wysiwyg-editors?

[Moonsugar]

Beste mede-tweakers,

In de laatste development .plan vertelden we dat we bezig waren met een proof-of-concept voor een wysiwyg-editor voor de reacties op artikelen, met als doel om te kijken of de gekozen tooling, te weten Quill, daarvoor geschikt zou zijn. Uiteindelijk zou een dergelijke editor dan ook op het forum aangeboden moeten gaan worden.

Op het moment van plaatsen van die .plan hadden we een basisopzet met Quill gemaakt en in de afgelopen iteratie zijn we bezig geweest met het implementeren van meer geavanceerde features zoals het kunnen quoten van andere berichten en mentionen van andere gebruikers. Hierbij liepen we echter al snel tegen issues aan: Quill bleek niet in staat om complete blokken content te kunnen samenvoegen in een enkele blockquote-tag, nesting van 'blocks' bleek niet mogelijk, en ook andere (basis)features vereisten al snel aanpassingen aan bestaande extensies of het schrijven van eigen extensies.

Hierdoor hebben we helaas moeten concluderen, ook met het oog op mogelijkheden die we voor het forum onontbeerlijk achten, dat Quill toch niet de juiste tool voor ons was. Kortom: we zijn nu weer op zoek naar een andere wysiwyg-editor die beter aansluit bij onze behoeften, en daar kunnen we ook wel wat hulp bij gebruiken.

Wat zijn onze basis requirements voor een wysiwyg-editor?

• Lightweight, extensible, gebruiksvriendelijk, eenvoudig te implementeren (uiteraard)
• Goed onderhouden, actieve community, goede documentatie, ruime beschikbaarheid van extensies/plugins
• Open source, free (as in beer) is een pré maar geen must
• Mogelijkheid tot serverside processing/parsing waarbij je in kan haken op bijvoorbeeld specifieke tags (ivm mentions e.d.)

Buiten Quill hebben wij zelf ervaring met CKEditor versie 4, maar aangezien die al wat verouderd is, niet echt lightweight en best lastig te extenden is hebben we die buiten beschouwing gelaten.

Wat is nu onze bedoeling met dit topic?
Omdat het onderzoeken en uitproberen van de vele beschikbare editors best een tijdrovende klus is, zeker als je specifieke requirements hebt die uitbreidbaarheid/aanpasbaarheid vereisen, willen we naast ons eigen research ook zoveel mogelijk informatie proberen te krijgen van mensen die echt ervaring hebben met specifieke editors, en vanuit die ervaring zouden kunnen aangeven of die editor een geschikte kandidaat voor ons zou kunnen zijn (of juist niet).

Heb jij dus goede of slechte ervaringen met een bepaalde wysiwyg-editor, en zou je hierover willen uitwijden, dan zouden we dat zeer op prijs stellen! Ons doel is om tegen het einde van volgende week (22 april) genoeg informatie te hebben verzameld om een goede keuze te kunnen maken voor een nieuwe proof-of-concept en hiervoor willen we zo snel mogelijk toewerken naar een bruikbare shortlist.

Bedankt alvast voor jullie hulp en feedback!

[AW_Bos]

Ikzelf gebruik CKeditor, maar dan op niet zo'n geavanceerde featureset als jullie, maar misschien kan je dit topic ook even aliassen naar Softwareontwikkeling ?

[crisp]

AW_Bos schreef op donderdag 14 april 2022 @ 19:39:
Ikzelf gebruik CKeditor, maar dan op niet zo'n geavanceerde featureset als jullie,

Welke versie?

maar misschien kan je dit topic ook even aliassen naar Softwareontwikkeling ?

Goed idee done!

[Creepy]

Als CKEditor wordt genoemd dan mag TinyMCE ook zeker niet ontbreken. Opensource met een plugin architectuur voor het maken van uitbreidingen en aanpassingen. Ik heb het veel gebruikt voor een HTML editor voor email waar we toen toch best wel wat voor hebben moeten verbouwen.

Maaruh, ik kan me niet voorstellen dat jullie CKEditor of TinyMCE nog niet op jullie netvlies hadden.

[StephanVierkant]

Ik heb ook Quill gebruikt, maar vanwege het gebrek aan fatsoenlijke ondersteuning van nested lists toch mee gestopt. Vooral de houding van de ontwikkelaars ('hier heb je wat css om het te fixen') stuitte me tegen de borst. Dat ze het nog steeds als 'enhancement' zien en niet als bug nodigt de community ook niet echt uit het te fixen.

Helaas heb ik ook geen vervanger gevonden en ben overgestapt naar Markdown. De power users hebben daarbij geen editor nodig en andere gebruikers hadden toch al genoeg aan eenvoudige elementen als bold/italic/bullet points.

Ik had graag een goed advies gegeven, maar helaas blijkt een goede editor vinden toch verdomd lastig zijn.

[DaFeliX]

Creepy schreef op donderdag 14 april 2022 @ 20:34:
[...]

Maaruh, ik kan me niet voorstellen dat jullie CKEditor of TinyMCE nog niet op jullie netvlies hadden.

Zeker, en CKEditor staat wat mij betreft wel op de shortlist.

TinyMCE wmb niet, omdat je daar geen custom data model hebt, je krijgt altijd HTML. Die HTML kun je dan wel sanitizen, maar dat zou je dan serversided ook nog 'ns moeten doen. Wat dat betreft was Quill wel heel fijn, met het delta-model waarmee het serversided parsen een heel stuk eenvoudiger wordt.

[DJMaze]

Er zijn heel veel editors, en allemaal hebben ze voor- en nadelen.
Daarnaast heb je ook nog het probleem van verschillende browsers die verschillend reageren.

Echter, het eerste verschil is de [enter] toets en [shift]+[enter] vs de huidige textarea.
Nu is [enter] een BR omdat het plain text is.
Straks in HTML is dat een block element (P of DIV, afhankelijk van browser).

Om dan te kiezen voor een bestaande oplossing betekent sowieso een complete acceptatie dat dingen niet zullen zijn zoals het was en verschillend per gebruiker/browser.

En dan praat ik nog niet eens over mensen die knippen/plakken in browser of van MS Word naar je browser (kuch kuch).

Daarom koos ik zelf voor de gulle middenweg.
Een basis WYSIWYG zonder deprecated execCommand() en ipv werkt met de DOM en zonder GUI zodat je zelf alles kan bepalen.
Nadeel hier is dat je dus zelf meer moet programmeren.
Voordeel is dat je alle vrijheid hebt om custom HTML te injecteren voor de huidige speciale UBB tags zoals: spoiler, topic, mentions, etc.

Zoals ik het nu zie vallen sowieso de grote jongens zoals CKEditor en TinyMCE af om een flink aantal redenen.
Wat wel meer aan de wensen voldoet hangt ook af van de kennis die ontwikkelaars hebben en willen bijleren.

Maar goed, begin eens met een lijstje editors en schrijf hun voor/nadelen op.

• Squire
• CKEditor
• Pell
• SCEditor
• Suneditor
• TinyMCE
• Trix
• etc.

[Voor 10% gewijzigd door DJMaze op 15-04-2022 09:14]

[DaFeliX]

DJMaze schreef op vrijdag 15 april 2022 @ 08:58:
Er zijn heel veel editors, en allemaal hebben ze voor- en nadelen.
Daarnaast heb je ook nog het probleem van verschillende browsers die verschillend reageren.

Echter, het grootste (eerste) probleem is de [enter] toets en [shift]+[enter] vs de huidige textarea.
Nu is [enter] een BR omdat het plain text is.
Straks in HTML is dat een block element (P of DIV, afhankelijk van browser).

Om dan te kiezen voor een bestaande oplossing betekent sowieso een complete acceptatie dat dingen niet zullen zijn zoals het was en verschillend per gebruiker/browser.
[...]

Het idee is dat we UBB straks ook laten varen, dus de acceptatie dat het straks anders zal zijn is er denk ik wel

DJMaze schreef op vrijdag 15 april 2022 @ 08:58:
[...]

Daarom koos ik zelf voor de gulle middenweg.
Een basis WYSIWYG zonder deprecated execCommand() en ipv werkt met de DOM en zonder GUI zodat je zelf alles kan bepalen.
Nadeel hier is dat je dus zelf meer moet programmeren.
Voordeel is dat je alle vrijheid hebt om custom HTML te injecteren voor de huidige speciale UBB tags zoals: spoiler, topic, mentions, etc.

[...]

Het zelf meer moeten programmeren is ook een kant die ik nu een beetje aan 't opgaan ben. Een kant-en-klare editor zal je snel op weg helpen, maar omdat we juist best wel specifieke dingen hebben zoals de genoemde spoilers, zal je er toch vroeger of later in moeten gaan hakken.
Ik zit nu in een fase waarin ik ook denk dat het wellicht beter is in de eerste fase maar wat meer werk te doen, om de flexibiliteit te houden om een goed geheel te krijgen - ipv lelijke hacks in een mooie editor

Welke basis gebruik jij? ProseMirror, Slate of nog wat anders?

DJMaze schreef op vrijdag 15 april 2022 @ 08:58:
[...]

Zoals ik het nu zie vallen sowieso de grote jongens zoals CKEditor en TinyMCE af om een flink aantal redenen.
Wat wel meer aan de wensen voldoet hangt ook af van de kennis die ontwikkelaars hebben en willen bijleren.
[...]

TinyMCE valt idd af volgens mij, maar CKEditor5 lijkt me wel een goede? Althans, het is modulair genoeg dat je zelf je editor kunt bouwen met alleen de componenten die je nodig hebt. Of het dan een simpel product is heb ik 't even niet over

[Mr. Awesome]

Ik heb goede ervaringen met Quill, die heb ik geïmplementeerd in Angular. Hierbij was de wens dat de gebruiker placeholders kon typen die automatisch herkend werden en gemarkeerd werden, dit was ff wat geklooi maar is best mooi gelukt met die delta's. UBB-codes herkennen zou op eenzelfde manier kunnen, als dat jullie wens is.

Met andere editors geen ervaring.

[DJMaze]

@DaFeliX ik gebruik een aangepaste versie van Squire.
Aangepast omdat ik geen IE en Edge-legacy ondersteun.

https://github.com/neilj/Squire

[Voor 13% gewijzigd door DJMaze op 15-04-2022 09:39]

[Tk55]

Waarom geen markdown icm preview zoals op oa github, reddit en veel andere sites?

[DJMaze]

Tk55 schreef op vrijdag 15 april 2022 @ 11:08:
Waarom geen markdown icm preview zoals op oa github, reddit en veel andere sites?

Kijk even naar het Overzicht van UBB-codes en vraag jezelf af: kan dat allemaal met markdown?

Voorbeeldje: RGB

[Voor 21% gewijzigd door DJMaze op 15-04-2022 11:11]

[DJMaze]

@DaFeliX Nu ik er over nadenk, is https://www.sceditor.com/ misschien een gulle middenweg als basis?
Dat is een BB editor met preview.

[Voor 25% gewijzigd door DJMaze op 15-04-2022 11:17]

[DaFeliX]

DJMaze schreef op vrijdag 15 april 2022 @ 11:16:
@DaFeliX Nu ik er over nadenk, is https://www.sceditor.com/ misschien een gulle middenweg als basis?
Dat is een BB editor met preview.

hey, die kende ik nog niet. Ik ga 'm bekijken!

[scosec]

Hier nog een tip van mijn kant. Wellicht interessant om een te bekijken.

https://imperavi.com/redactorx/ of https://imperavi.com/redactor/

[Zenomyscus]

Persoonlijk heb ik ContentTools wel eens gebruikt. Het lijkt niet echt op de standaard tekstverwerker, maar het werkt in mijn scenario prima:
https://github.com/GetmeUK/ContentTools

[DJMaze]

DaFeliX schreef op vrijdag 15 april 2022 @ 11:24:
hey, die kende ik nog niet. Ik ga 'm bekijken!

Graag gedaan!

Ik kwam al wat leuke tests tegen:

1. kopieer bb code
2. plak in de wysiwyg
3. alles is opgemaakt

1. kopieer wysiwyg
2. plak in textarea
3. de bb code is weg
4. oplossing?: vang copy af en zet text/plain part zelf incl. ubb (mits mogelijke)

De CODE=* tags herkent ie niet, alleen de basis.
Maar dat wordt in het Forum sowieso met elke editor een gigantische uitdaging

[Ulster Seedling]

Geen ervaring, maar Facebook heeft net hun nieuwe text editor open source gemaakt: https://lexical.dev

Waarschijnlijk nog te vroeg om te gaan gebruiken, maar misschien wel interessant.

Overigens zou mijn voorkeur sterk uitgaan naar Markdown i.p.v. UBB of een WYSIWYG-editor. En als het toch een WYSIWYG-editor moet zijn, dan liefst een die Markdown accepteert en automatisch omzet naar de juiste opmaak.

[_David_]

Misschien hebben jullie nog wat aan de Stacks editor, wordt gebruikt door StackOverflow. Gebaseerd op prosemirror.

[recoil9]

Geen ervaring mee maar tiptap heeft ondersteuning voor mentions, is open source, ondersteund extensies en is ook gebasseerd op ProseMirror. Grootste voordeel van ProseMirror, naar mijn mening, is dat het te exporteren is naar JSON.

Mijn ervaring met ProseMirror is dat het cross-platform goed werkt (met name op Android) ten opzichte van editors zoals Slate en Draft.js

Interessante link over het onderliggende data-model https://open.nytimes.com/building-a-text-editor-for-a-digital-first-newsroom-f1cb8367fc21

[johnwoo]

recoil9 schreef op vrijdag 15 april 2022 @ 22:26:
Geen ervaring mee maar tiptap heeft ondersteuning voor mentions, is open source, ondersteund extensies en is ook gebasseerd op ProseMirror. Grootste voordeel van ProseMirror, naar mijn mening, is dat het te exporteren is naar JSON.

Hier wel ervaring met tiptap (mentions ook in gebruik, evenals drag&drop en pasted image uploads met instant preview nodes), en ik kan het aanraden.

Het is geen kant-en-klare editor (zoals CK, Tiny) waarin beslissingen voor jou worden genomen en het soms lastig is je eigen specifieke feature erin te hacken. Maar het biedt wel een toolbox (bovenop ProseMirror) waarmee je zelf bepaalt wat je gebruikt, en vooral ook, hoe. Zo heb je vrij snel je eigen editor in elkaar gezet.

Hun eigen homepage zegt het al; "for web artisans". Een tiptap editor "craft" je ook meer, terwijl je een CK/Tiny meer "installeert" (of aanvinkt, als onderdeel van een CMS). Tiptap heeft ook geen themes; je bouwt zelf je toolbars en buttons maar, precies zoals je ze wil hebben. Daarmee integreert het ook beter in je site dan een volledige kant-en-klaar editor.

[DaFeliX]

Wat de keuze van een editor (of, welke tool dan ook) lastig maakt, dat vrijwel elk product zichzelf de hemel inprijst. Pas op 't moment dat je dan met zo'n tool aan de slag gaat, merk je dat er dingen niet (goed) werken.
Tegen welke dingen ben jij aangelopen @johnwoo met 't gebruik van tiptap?

[Ossebol]

Zelf heb ik hele goede ervaringen met Jodit, zowel binnen hobbyprojecten als binnen enterpriseomgevingen. BInnen de laatste context zetten we de editor in binnen onze Angular-app. Jodit is behoorlijk ver te customizen.

[w3ssl3y]

Ik ben tijdens mijn vorige baan bezig geweest met CKEditor 5. Heb daar toen ook zelf wat extra plugins aan toegevoegd en op dat gebied is het echt geweldig! Je hebt ontzettend veel controle over de editor en het is allemaal heel declaratief. Het was wel veel reverse-engineeren van plugins die zij zelf leveren om er achter te komen hoe ze nu willen dat je iets doet, maar als het werkt, werkt het top!

Waar ik heel erg over struikelde is dat de editor echt gigantisch is en bij ons ongeveer een derde van de totale bundle size bedroeg. Dat los je natuurlijk op door het in een aparte chunk te proppen maar het had wel serieuze impact op de laadtijd van een pagina. Ook vond ik de hele toolchain voor het bouwen van je eigen editor wel complex, en ik ben fervent Webpack gebruiker sinds v2/3 ongeveer! Nu heb ik wel gezien dat CKEditor ondertussen iets doet met Webpack DLL's doet maar daar heb ik zelf nog geen gebruik van gemaakt.

[Compizfox]

Implementeer alsjeblieft gewoon Markdown in plaats van een WYSIWYG-editor.

[Ronosho]

Ik heb eej tind geleden ook gekeken naar een fatsoenlijke editor. Uit eindelijk bij Froala uitgekomen

[DaFeliX]

Compizfox schreef op maandag 2 mei 2022 @ 14:33:
Implementeer alsjeblieft gewoon Markdown in plaats van een WYSIWYG-editor.

Markdown ondersteunen is niet ideaal, dat is qua nesting niet zo prettig. Simpele zaken werken prima, maar zodra je meerdere soorten opmaak met elkaar wil combineren (zoals een lijst in een cell binnen een table) loop je daar tegen de limiten van markdown aan. Dan is de UBB die we nu gebruiken een logischere fallback.
Sowieso moet "oude" UBB omgezet kunnen worden naar de WYSIWYG code, zodat men content kan blijven aanpassen die "vroeger" geschreven is. En wellicht moeten we UBB als invoermogelijkheid blijven aanbieden voor mensen die geen javascript willen, maar markdown ondersteunen lijkt me niet handig.

[Ulster Seedling]

DaFeliX schreef op maandag 2 mei 2022 @ 15:03:
[...]


Markdown ondersteunen is niet ideaal, dat is qua nesting niet zo prettig. Simpele zaken werken prima, maar zodra je meerdere soorten opmaak met elkaar wil combineren (zoals een lijst in een cell binnen een table) loop je daar tegen de limiten van markdown aan. Dan is de UBB die we nu gebruiken een logischere fallback.
Sowieso moet "oude" UBB omgezet kunnen worden naar de WYSIWYG code, zodat men content kan blijven aanpassen die "vroeger" geschreven is. En wellicht moeten we UBB als invoermogelijkheid blijven aanbieden voor mensen die geen javascript willen, maar markdown ondersteunen lijkt me niet handig.

Markdown ondersteunt (vaak) HTML. Dus voor geavanceerd gebruik (“een lijst in een cell binnen een table”) zou je dan ook gewoon HTML kunnen gebruiken? Vrijwel hetzelfde als UBB, alleen met andere haakjes.

Ik denk dat 99% van het gebruik ‘eenvoudig’ is, en dat Markdown daar echt een stuk prettiger is dan UBB (of een WYSIWYG-editor die geen Markdown spreekt).

(Wellicht zou je zelfs een Markdown-dialect kunnen maken die UBB i.p.v. HTML accepteert, voor geavanceerd gebruik? Dat klinkt voor deze situatie als een perfecte oplossing m.i. )

[Tom]

Ik denk ook dat er twee dingen door elkaar gehaald worden, namelijk je markup language en de editor.
Markdown is net als HTML (of het onofficiele UBB) een markup language, alleen dan met een andere syntax en beperkter qua functionaliteit (en uiteindelijk bij het renderen is het HTML). Een editor is een schil voor de gebruiker om tekst op gebruiksvriendelijke manier op te maken. De output staat daar los van, dat kan in theorie vanalles zijn (Markdown, UBB of HTML). Volgens mij zoekt T.net vooral een editor.

[DaFeliX]

Ulster Seedling schreef op maandag 2 mei 2022 @ 16:34:
[...]


Markdown ondersteunt (vaak) HTML. Dus voor geavanceerd gebruik (“een lijst in een cell binnen een table”) zou je dan ook gewoon HTML kunnen gebruiken? Vrijwel hetzelfde als UBB, alleen met andere haakjes.

Maar dan wil je Markdown + HTML, dan zou het logischer zijn om 1 standaard te hanteren die beide use-cases aankan. HTML binnen Markdown is imo een teken dat Markdown zelf onvoldoende ondersteuning heeft.

[...]

(Wellicht zou je zelfs een Markdown-dialect kunnen maken die UBB i.p.v. HTML accepteert, voor geavanceerd gebruik? Dat klinkt voor deze situatie als een perfecte oplossing m.i. )

Op zich geen gek idee, maar ik vraag me dan wel af of dat nu zo gebruiksvriendelijk is. Het is dan wel heel erg specifiek, en onze UBB al geen 'echte' BBCode. Volgens mij kun je het dus beter allebei laten vallen en helemaal opnieuw beginnen

Tom schreef op maandag 2 mei 2022 @ 17:06:
Ik denk ook dat er twee dingen door elkaar gehaald worden, namelijk je markup language en de editor.
Markdown is net als HTML (of het onofficiele UBB) een markup language, alleen dan met een andere syntax en beperkter qua functionaliteit (en uiteindelijk bij het renderen is het HTML). Een editor is een schil voor de gebruiker om tekst op gebruiksvriendelijke manier op te maken. De output staat daar los van, dat kan in theorie vanalles zijn (Markdown, UBB of HTML). Volgens mij zoekt T.net vooral een editor.

Klopt, en klopt. Ons eerste idee was ook een editor complementair te maken, en volgens mij hadden we prima onderhuids UBB kunnen blijven gebruiken. Dat is qua development de kleinste tijdsinvestering, en zorgt voor maximale flexibiliteit.
Echter, onze UBB parsers zijn best wel complex geworden, en de voordelen die o.a. Quill en TipTap (of eigenlijk, ProseMirror) hebben van een output in een ander formaat maakt het back-end parsen een heel stuk eenvoudiger. Het parsen van een JSON blob is vele malen minder complex en minder foutgevoelig dan het parsen van UBB of HTML. Dit komt doordat de editor (die je intenties "weet") het lexen voor z'n rekening neemt. Hierdoor is het backendwerk een stuk eenvoudig, en sluit dit heel goed aan bij de editor zelf.

Neem als voorbeeld een mention, dat is voor de gebruiker simpelweg een link naar een profiel door @Tom te typen. Maar, onze backend moet wel weten welke user er gementioned is, zodat de notificatie gestuurd kan worden. Als je een JSON blob het met daarin "mention for user 111", hoeft de backend alleen maar de notificatie te sturen. In UBB (of markdown) moet je die intentie uit platte tekst halen, en als je dan [~Tom typt, en de ] vergeet, wil je niet dat de user "Tom typt, en de" de notificatie ontvangt

[Compizfox]

DaFeliX schreef op maandag 2 mei 2022 @ 15:03:
[...]


Markdown ondersteunen is niet ideaal, dat is qua nesting niet zo prettig. Simpele zaken werken prima, maar zodra je meerdere soorten opmaak met elkaar wil combineren (zoals een lijst in een cell binnen een table) loop je daar tegen de limiten van markdown aan. Dan is de UBB die we nu gebruiken een logischere fallback.
Sowieso moet "oude" UBB omgezet kunnen worden naar de WYSIWYG code, zodat men content kan blijven aanpassen die "vroeger" geschreven is. En wellicht moeten we UBB als invoermogelijkheid blijven aanbieden voor mensen die geen javascript willen, maar markdown ondersteunen lijkt me niet handig.

Ik denk dat je niet te ingewikkelde opmaak moet willen ondersteunen. Markdown is ideaal voor bijna alle forumposts. Voor dingen waar je echt ingewikkeldere tabellen oid nodig hebt, kun je gewoon HTML gebruiken.

Een WYSIWYG-editor is echt overkill en gewoon onhandig voor forumposts, imo. Ik kan veel sneller in Markdown schrijven dan ik kan zitten prutsen in een WYSIWYG-editor.

Bovendien is Markdown zo goed als standaard voor dit soort dingen: kijk naar Reddit, GitHub, Stack Overflow enz.

UBB aan de andere kant is erg onhandig en veel te verbose.

---

Tom schreef op maandag 2 mei 2022 @ 17:06:
Ik denk ook dat er twee dingen door elkaar gehaald worden, namelijk je markup language en de editor.
Markdown is net als HTML (of het onofficiele UBB) een markup language, alleen dan met een andere syntax en beperkter qua functionaliteit (en uiteindelijk bij het renderen is het HTML). Een editor is een schil voor de gebruiker om tekst op gebruiksvriendelijke manier op te maken. De output staat daar los van, dat kan in theorie vanalles zijn (Markdown, UBB of HTML). Volgens mij zoekt T.net vooral een editor.

Je zou natuurlijk Markdown als opmaaktaal kunnen gebruiken i.c.m. een WYSIWYG-editor, maar dat is een beetje vloeken in de kerk. Hét voordeel van Markdown is nu juist dat het zo simpel is dat je het gewoon in plain text kunt schrijven, en dat je dus geen WYSIWYG nodig hebt.

Persoonlijk vind ik dit inderdaad ook veel fijner en sneller (en minder error-prone) dan WYSIWYG-editors.

[Voor 28% gewijzigd door Compizfox op 03-05-2022 17:08]

[RoestVrijStaal]

Even een technische mededeling: de examples op tiptap werken niet op browsers die geen custom elements ondersteunen. WebComponents zijn (nog) geen HTML standaard.

Het zou jammer zijn als het reageren enkel nog met Chromium-based browsers kan

Dus tiptap valt voor mij af.

[Voor 6% gewijzigd door RoestVrijStaal op 26-05-2022 21:42]

[crisp]

RoestVrijStaal schreef op donderdag 26 mei 2022 @ 21:41:
Even een technische mededeling: de examples op tiptap werken niet op browsers die geen custom elements ondersteunen. WebComponents zijn (nog) geen HTML standaard.

Het zou jammer zijn als het reageren enkel nog met Chromium-based browsers kan

Dus tiptap valt voor mij af.

Dat valt toch wel mee zo te zien: https://caniuse.com/custom-elementsv1

[Yucon]

Het allerbelangrijkste vind ik dat een plaatje er gewoon ingesleept kan worden.

Een voorbeeld van een forum dat lekker werkt is dat van thethingsnetwork.

[Bender]

Hier overgestapt van CKEditor naar TinyMCE, ik meen dat de reden was dat CKEditor een meer commerciële karakter heeft gekregen.
Plugin integratie kan bij beide, maar vond die van TinyMCE toch wel makkelijker.

[Josk79]

offtopic:
|‐------------------------‐-----------‐-----------‐-----------‐-----------‐|
| Deze Wysiwyg van Tweakers is prima, toch? |
| |
| Zie hoe mooi mijn tekstblok is geworden! |
|‐------------------------‐-----------‐-----------‐-----------‐-----------‐|

[AW_Bos]

Josk79 schreef op dinsdag 16 augustus 2022 @ 20:37:

offtopic:
|‐------------------------‐-----------‐-----------‐-----------‐-----------‐|
| Deze Wysiwyg van Tweakers is prima, toch? |
| |
| Zie hoe mooi mijn tekstblok is geworden! |
|‐------------------------‐-----------‐-----------‐-----------‐-----------‐|

Dat heet een code-editor, geen WYSIWYG.

[drm]

Hoewel ik wysiwyg als de pest mijd, en mijn ervaring wellicht wat gedateerd is, deel ik 'm toch.

Ik heb ervaring met twee wysiwyg editors, FCK Editor (de voorloper van CK) en TinyMCE en nog wat proof-of-concepts van andere editors die ik niet echt productie-ervaring kan noemen. Dit was vrijwel altijd in een CMS-achtige context, dus matcht wellicht niet helemaal met de T.net use case(s).

Ik ben zelf altijd voorstander geweest van TinyMCE omdat het een vrij simpel model hanteert en de API goed gedocumenteerd was. De basis is simpel: je bewerkt de DOM van een geisoleerd document (een iframe met een contenteditable body), en maakt zoveel mogelijk gebruik van de browser features om mutaties op die DOM te doen. Elke poging om daar nog een model tussen te zetten (wat sommige editors doen) levert een 'source of truth' probleem op omdat je niet alle events consistent cross-browser af kunt vangen (althans, destijds niet, ik weet niet of dat nog steeds een issue is), en dat wordt dan vervolgens met allerlei hacks opgevangen. Mijn redenatie was: ofwel je gebruikt contenteditable en je rendert de HTML op basis van de DOM (met eventuele toepasselijke transformaties) of je bouwt het gedrag van contenteditable na door een editor van scratch te bouwen. Ik vond dat laatste niet acceptabel, omdat je dan ineens allerlei features na moet gaan bouwen die door de browser al geimplementeerd zijn (denk aan copy/paste, applystyle, etc).

HTML klinkt vies, maar als je je realiseert dat HTML de tekstweergave van de onderliggende DOM is, is het ineens helemaal niet zo ingewikkeld meer. Je bouwt gewoon een transformer die de DOM doorloopt en alle meuk uitfiltert die je niet wilt hebben, of beter: alleen alle meuk overlaat die je wel wilt hebben. Diezelfde filter pas je toe na elke transformatie (zoals bijv een paste). Welke tool is daar beter voor dan de JS engine van je browser? Vanzelfsprekend pas je dezelfde implementatie toe aan de serverkant (met node tegenwoordig een fluitje van een cent, maar desnoods gebruik je er een headless chrome* voor) en je bent er.

Maar, dat gezegd hebbende, ik heb het pad van een non-contenteditable based editor met een eigen document-model nooit bewandeld (behalve dan voor highlighting met een monospaced overlay) en ik zou daar (al is het maar vanwege vakmatige interesse) wel degelijk onderzoek naar doen voordat je hierover een beslissing neemt. Dat lijkt me vooralsnog de eerste keuze die je moet maken.

*) dit is voor public-facing implementaties misschien niet echt haalbaar, resource-wise, maar ik noem 't toch maar even

PS, ten overvloede, ik adviseer(de) vooral zoveel mogelijk tegen wysiwyg, omdat de meeste mensen nog steeds niet weten hoe je netjes een document opmaakt. Content-managers die doodleuk tabellen vanuit Word in een CMS plakken en zich afvragen waarom hun ad-hoc font-definities niet meegenomen worden, wil je natuurlijk met een vriendelijk gebaar doodknuppelen, maar het gebeurt vaker dan je lief is. Ik ben benieuwd hoe veel wan-gebruik en human error je op je hals haalt met dit project

[raxon]

Ik ben zelf bezig met een cms schrijven en loop ook tegen dit probleem aan. Mijn voorkeur lijkt uit te gaan naar prosemirror. Heb vroeger ook met ck editor gewerkt en vindt dat toen al een gedrocht. Als je kijkt naar de json data van prosemirror ziet dat er netjes uit. Het plakken vanuit een ander programma boeit me niet echt en ga dat denk ik zonder opmaak doen. De html van word al eens gezien?

[AW_Bos]

raxon schreef op donderdag 25 augustus 2022 @ 07:02:
Ik ben zelf bezig met een cms schrijven en loop ook tegen dit probleem aan. Mijn voorkeur lijkt uit te gaan naar prosemirror. Heb vroeger ook met ck editor gewerkt en vindt dat toen al een gedrocht. Als je kijkt naar de json data van prosemirror ziet dat er netjes uit. Het plakken vanuit een ander programma boeit me niet echt en ga dat denk ik zonder opmaak doen. De html van word al eens gezien?

Verschrikkelijk! Maar HTML moet je dan eigen ook strippen. Als ik ooit iets uit Word moet copy/pasten naar een website met wysiwyg, dan doe ik dit altijd met tussenkomst van het old school Notepad.

[DaFeliX]

raxon schreef op donderdag 25 augustus 2022 @ 07:02:
Ik ben zelf bezig met een cms schrijven en loop ook tegen dit probleem aan. Mijn voorkeur lijkt uit te gaan naar prosemirror. Heb vroeger ook met ck editor gewerkt en vindt dat toen al een gedrocht. Als je kijkt naar de json data van prosemirror ziet dat er netjes uit. Het plakken vanuit een ander programma boeit me niet echt en ga dat denk ik zonder opmaak doen. De html van word al eens gezien?

Leuk! Ik heb ook een aantal CMS'en geschreven. Wat is voor jou de reden om hem zelf te schrijven ipv een bestaand CMS te pakken?
Ik heb met CKEditor 3 gewerkt en dat was idd een gedrocht, maar sinds CKEditor versie 5 is er een hele hoop verbeterd; zo werkt die nu ook met een HTML element dat contenteditable is.

Prosemirror werkt trouwens met een allowlist, niet met een denylist. Volgens mij is dit nu zo'n beetje de standaard, maar er is een periode geweest dat het andersom was.

Het voordeel van het gebruiken van een allowlist is dat alleen elementen die je ondersteund, in de editor terechtkomen. Hierdoor is het kopieren van opgemaakte tekst uit welke bron dan ook in elk geval heel veilig: er komt geen "troep" in. Het nadeel is dan wel dat als een gebruiker tekst opmaakt met tabellen die je niet ondersteunt, de tekst platgeslagen wordt.

Er zit volgens mij wel een belangrijk verschil tussen een CMS en hoe we het bij Tweakers inzetten. Ik kan mij heel goed voorstellen dat het kopieren/plakken in onze situatie nauwelijks voorkomt, omdat men op een reactie reageert en dus vooral in de editor zelf zal typen. Bij een CMS zul je denk ik vaker hebben dat mensen kopij inkopen of voor meerdere bronnen maken. Hier zal het volgens mij dus vaker gebeuren dat men tekst inplakt.

[crisp]

drm schreef op donderdag 25 augustus 2022 @ 04:23:
Hoewel ik wysiwyg als de pest mijd, en mijn ervaring wellicht wat gedateerd is, deel ik 'm toch.

Ik heb ervaring met twee wysiwyg editors, FCK Editor (de voorloper van CK) en TinyMCE en nog wat proof-of-concepts van andere editors die ik niet echt productie-ervaring kan noemen. Dit was vrijwel altijd in een CMS-achtige context, dus matcht wellicht niet helemaal met de T.net use case(s).

Voor ons redactie-CMS gebruiken we al CKEditor (4), en daarvoor TinyMCE.

TinyMCE is nadien weer nieuw leven ingeblazen, maar we hebben veel custom widgets geschreven voor CKEditor, dus we zitten daar voor het CMS redelijk aan vast nu...

Ik ben zelf altijd voorstander geweest van TinyMCE omdat het een vrij simpel model hanteert en de API goed gedocumenteerd was. De basis is simpel: je bewerkt de DOM van een geisoleerd document (een iframe met een contenteditable body), en maakt zoveel mogelijk gebruik van de browser features om mutaties op die DOM te doen. Elke poging om daar nog een model tussen te zetten (wat sommige editors doen) levert een 'source of truth' probleem op omdat je niet alle events consistent cross-browser af kunt vangen (althans, destijds niet, ik weet niet of dat nog steeds een issue is), en dat wordt dan vervolgens met allerlei hacks opgevangen. Mijn redenatie was: ofwel je gebruikt contenteditable en je rendert de HTML op basis van de DOM (met eventuele toepasselijke transformaties) of je bouwt het gedrag van contenteditable na door een editor van scratch te bouwen. Ik vond dat laatste niet acceptabel, omdat je dan ineens allerlei features na moet gaan bouwen die door de browser al geimplementeerd zijn (denk aan copy/paste, applystyle, etc).

Het grote nadeel van contenteditable is dat het een reverse-engineered API is vanuit de oorspronkelijke implementatie van Microsoft in Internet Explorer. Inmiddels is IE dood en begraven, maar het blijft toch een bron van cross-browser compatibility issues (iig tussen de verschillende engines, webkit - gecko - chromium). Dat zal vast de laatste jaren verbeterd zijn, maar het is voor veel editors wel de reden geweest om een beetje af te stappen van contenteditable en/of daar een eigen custom model tussen te zetten

[raxon]

De reden dat ik een cms bouw is ook de reden dat ik een framework met eigen template taal heb ontwikkeld, houdt je bezig en bekwaam. Ik wil meerdere subdomeinen/domeinen beheren in 1 tool en geen een bood dat aan volgens mij. Mijn taal zit ook eventueel in json config files, die dan geparsed worden. Je kunt dan bijvoorbeeld json.select(URL,selector) uitvoeren om de config files compact te houden en verdelen over meerdere files..., wel leuk trouwens