Wysiwyg-editor nu ook live op het forum

[beeldbuijs]

crisp schreef op woensdag 4 februari 2026 @ 08:46:
[...]

Indien dat op desktop gebeurd; zou je dan eens kunnen kijken in de javascript console (F12) of je daar errors ziet, en die aan ons doen toekomen?

Ik heb het alleen op mijn iPhone (Safari).

[beeldbuijs]

DaFeliX schreef op woensdag 4 februari 2026 @ 08:31:
[…]We hebben nu de help uitgebreid met de uitleg hoe je een witregel invoegt; en (kudo's voor @crisp !) een extra 'markdownnotatie' toegevoegd. Je kunt nu een regel eindigen met twee spaties, gevolgd door een <enter> waarna een witregel wordt ingevoerd i.p.v. een nieuwe paragraaf gestart.

Hopelijk helpt dit een beetje

Ah, dit wordt door mij in ieder geval zéér gewaardeerd!

Als graficus moet ik hierbij wel opmerken dat dit juist géén witregel en géén nieuwe paragraaf is.

Een aaneengesloten stuk tekst noem je in het Nederlands geen paragraaf, maar een alinea. Een paragraaf bevat normaliter meerdere alinea's. De verwarring ontstaat natuurlijk, zoals zo vaak, doordat een alinea in het Engels / html een paragraph / <p> heet.

Een witregel tussen twee stukken tekst maakt juist dat het twee alinea's worden. Een witregel is letterlijk een witte regel: een regel zonder tekst er in, maar die vermijd je nou juist hiermee.

Kortom, twee spaties en een return worden omgezet in een newline, oftewel een Line Feed / LF oftewel een ASCII 10 character, dat de cursor naar de volgende regel verplaatst. Wel zo prettig om dit tot je beschikking te hebben.

[DaFeliX]

beeldbuijs schreef op woensdag 4 februari 2026 @ 21:13:
[...]

Ah, dit wordt door mij in ieder geval zéér gewaardeerd!

Als graficus moet ik hierbij wel opmerken dat dit juist géén witregel en géén nieuwe paragraaf is.

Een aaneengesloten stuk tekst noem je in het Nederlands geen paragraaf, maar een alinea. Een paragraaf bevat normaliter meerdere alinea's. De verwarring ontstaat natuurlijk, zoals zo vaak, doordat een alinea in het Engels / html een paragraph / <p> heet.

Een witregel tussen twee stukken tekst maakt juist dat het twee alinea's worden. Een witregel is letterlijk een witte regel: een regel zonder tekst er in, maar die vermijd je nou juist hiermee.

Kortom, twee spaties en een return worden omgezet in een newline, oftewel een Line Feed / LF oftewel een ASCII 10 character, dat de cursor naar de volgende regel verplaatst. Wel zo prettig om dit tot je beschikking te hebben.

Om 't op z'n goed Nederlands te zeggen; thanks for educating me . Ik zal het proberen te onthouden.

[crisp]

In de help noemen we het "regelafbreking"

[Meg]

Waarom heeft de "normale tekst" een pijl omhoog en omlaag terwijl "Meer" alleen een pijl omlaag heeft tot je hem opent en dan switcht die.

Verder nog steeds enorm tevreden.

[crisp]

Meg schreef op donderdag 5 februari 2026 @ 09:52:
Waarom heeft de "normale tekst" een pijl omhoog en omlaag terwijl "Meer" alleen een pijl omlaag heeft tot je hem opent en dan switcht die.

Verder nog steeds enorm tevreden.

Omdat ze functioneel anders zijn. Met het 'tekststijl' menu kan je stijlen wisselen en deze geeft ook de huidige status weer, het 'meer'-menu is daadwerkelijk een uitklapmenu met keuzes.

[Meg]

Wanneer komt de functie naar DMs?

[Help!!!!]

Ik post vooral op het forum en gebruik m.n. basic tags. Volgensmij werkt de [BR] tag (nog) niet en die mis ik wel maar verder bevalt het tot nu toe best wel goed en is het denk ik een verbetering en gebruikersvriendelijker.

Dat is ook wel eens fijn want meestal ben ik, eufemistisch gezegd, niet zo'n fan van de grote changes op Tweakers (ahum PW) .

[crisp]

Meg schreef op vrijdag 6 februari 2026 @ 19:37:
Wanneer komt de functie naar DMs?

Voordat het live gaat, staat op de to-do

Help!!!! schreef op vrijdag 6 februari 2026 @ 19:52:
Ik post vooral op het forum en gebruik m.n. basic tags. Volgensmij werkt de [BR] tag (nog) niet en die mis ik wel maar verder bevalt het tot nu toe best wel goed en is het denk ik een verbetering en gebruikersvriendelijker.

Die zou ondertussen moeten werken, staat ook een optie voor in het meer-menu (regelafbreking).

[Sissors]

Ik heb momenteel met de editor met regelmaat dat ik niet een witregel krijg. En ik kan het redelijk consistent reproduceren iig door één spatie te hebben en dan een enter, dus niet twee! Voor mij iig voelt het inconsistent. Ik eindig weleens een zin, doe de spatie voor de volgende zin, wil wat opzoeken bijvoorbeeld, en besluit dan toch een nieuwe alinea te doen, en dan krijg ik ineens alleen een nieuwe regel.

[Vliegvlug]

Sissors schreef op vrijdag 6 februari 2026 @ 22:33:
Ik heb momenteel met de editor met regelmaat dat ik niet een witregel krijg. En ik kan het redelijk consistent reproduceren iig door één spatie te hebben en dan een enter, dus niet twee! Voor mij iig voelt het inconsistent. Ik eindig weleens een zin, doe de spatie voor de volgende zin, wil wat opzoeken bijvoorbeeld, en besluit dan toch een nieuwe alinea te doen, en dan krijg ik ineens alleen een nieuwe regel.

Ik vind het wel een verbetering eigenlijk, één spatie ipv twee.

En zo vaak gebeurt dat toch niet, weleens. Best mee te leven lijkt me, de winst voor mij is 50% in het aantal bespaarde spaties, beetje geven en nemen!

[DaFeliX]

Sissors schreef op vrijdag 6 februari 2026 @ 22:33:
Ik heb momenteel met de editor met regelmaat dat ik niet een witregel krijg. En ik kan het redelijk consistent reproduceren iig door één spatie te hebben en dan een enter, dus niet twee! Voor mij iig voelt het inconsistent. Ik eindig weleens een zin, doe de spatie voor de volgende zin, wil wat opzoeken bijvoorbeeld, en besluit dan toch een nieuwe alinea te doen, en dan krijg ik ineens alleen een nieuwe regel.

Hm, inderdaad; ik zie het ook; en als je deze dan weghaald en weer op enter drukt gaat het wel goed... Ik heb een bugticket aangemaakt, we gaan er naar kijken!

[duvekot]

Ik had het hier nog niet voorbij zien komen, maar als je op mobiel (Android/Chrome) mer de beta wysiwyg-editor een link wil toevoegen, dan staat dat invoer scherm eigenlijk net te laag op de pagina om op de invoegen knop te kunnen drukken

[DaFeliX]

br00ky schreef op maandag 24 november 2025 @ 13:08:
Copy-paste vanaf mobiele Firefox werkt niet zodra er een smiley in het bericht zit. Ik bevestig nick changes altijd met
[...]
maar dat kan je niet pasten. De tekst is heel even in beeld en verdwijnt daarna weer. Zonder smiley is er niks aan de hand.

In broncode modus werkt het overigens wel gewoon.

Ik heb het geprobeerd te reproduceren (dankjewel voor je hulp @br00ky !), maar ik kom er gewoonweg niet achter wat het probleem is.

We hebben nog wel een verbetering op de planning staan voor betere herkenning van smileys, en ook nog wat andere tickets die mogelijk invloed hebben op deze bug. Ik hoop stiekem dat daarmee het probleem opgelost gaat worden. Ik pauzeer dit specifieke probleem nu dus even, we gaan verder met het andere werk en ik hoop dat het vanzelf opgelost gaat worden. Voor de 'echte' release moeten we maar 'ns kijken of het nog steeds speelt.

[harley]

heb niet het hele topic doorgelezen.
Maar wilde wel een probleem melden :

Hét grote motortopic - Deel 28 (2026)

Want ik probeerde de afbeelding van @JL Koppelle juist te plaatsen ( die verneukte de layout) maar
1. het duurt erg lang voordat ik iets kan typen, en de pc zelf is niet traag.
Als ik alleen die wijziging wil opslaan krijg ik de volgende foutmelding :

Er is iets fout gegaan. Probeer het later nog eens, of ga terug.

De inhoud is te lang na conversie: 460,921 karakters na conversie, 198,777 karakters meer dan mogelijk. Probeer de reactie in te korten of plaats enkele losse reacties.

(interne identificatie: message::update::maxcolumnsize_exceeded)

Hieronder vind je de belangrijkste ingevoerde waarden terug, met een simpele copy&paste kan je deze weer gebruiken.

Ook zie ik al in de opmaak dat de tabel veel meer kolommen heeft als die daadwerkelijk in de post heeft.

Heb hem naar broncode gezet en het daar wel kunnen wijzigen.

[crisp]

harley schreef op vrijdag 20 februari 2026 @ 19:57:
heb niet het hele topic doorgelezen.
Maar wilde wel een probleem melden :

Hét grote motortopic - Deel 28 (2026)

Want ik probeerde de afbeelding van @JL Koppelle juist te plaatsen ( die verneukte de layout) maar
1. het duurt erg lang voordat ik iets kan typen, en de pc zelf is niet traag.
Als ik alleen die wijziging wil opslaan krijg ik de volgende foutmelding :

[...]

Ook zie ik al in de opmaak dat de tabel veel meer kolommen heeft als die daadwerkelijk in de post heeft.

Heb hem naar broncode gezet en het daar wel kunnen wijzigen.

Er zitten wat inconsistenies in de daar gebruikte tabel qua aantal kolommen. Het zou beter zijn om de tabel "Vorige delen" en "Overzicht met rijders" los te koppelen van de "main" tabel zodat je niet met colspans hoeft te klooien. Dat lost ook wat problemen met de layout op mobiel op.

Maar meer algemeen is het sowieso beter om geen tabel te misbruiken voor layout...

[harley]

Ik heb de startpost niet gemaakt, ben pas sinds gisteren mede auteur en wilde wat dingen bijwerken.
Zal eens kijken of ik hem helemaal op de schop kan gooien.

kan het edit venster ook (veel) groter dan wat die nu kan ? Want met zo'n grote startpost is het wel heel veel scrollen....

[crisp]

harley schreef op vrijdag 20 februari 2026 @ 20:22:
Ik heb de startpost niet gemaakt, ben pas sinds gisteren mede auteur en wilde wat dingen bijwerken.
Zal eens kijken of ik hem helemaal op de schop kan gooien.

kan het edit venster ook (veel) groter dan wat die nu kan ? Want met zo'n grote startpost is het wel heel veel scrollen....

Je kan het tekstveld vanuit de rechteronderhoek groter slepen

[harley]

@crisp Dat weet ik, maar dan wordt ie maximaal 2x zo hoog en 1/3e breder. dat is op de huidige monitoren nog steeds amper een derde van mijn hele beeldscherm

[ Voor 14% gewijzigd door harley op 20-02-2026 20:32 ]

[crisp]

harley schreef op vrijdag 20 februari 2026 @ 20:31:
@crisp Dat weet ik, maar dan wordt ie maximaal 2x zo hoog en 1/3e breder. dat is op de huidige monitoren nog steeds amper een derde van mijn hele beeldscherm

[Afbeelding]

Ik zou dan adviseren om een aparte teksteditor te gebruiken bij zo'n grote topicstart; kan je het ook tussentijds opslaan

[harley]

Wat is daar dan wysiwyg aan ?

[crisp]

harley schreef op vrijdag 20 februari 2026 @ 20:45:
Wat is daar dan wysiwyg aan ?

Ik bedoel om eerst de UBB te fixen zodat het daarna (hopelijk) wel goed gaat in de wysiwyg-editor.

[AW_Bos]

Ligt het aan mij, of is er een update geweest waardoor je niet meer direct een afbeelding kan copy-pasten in de editor?

"Gebruik het camera-icoontje in de toolbar om een afbeelding te uploaden naar je fotoalbum en in de tekst te kunnen plaatsen."

Voorheen werkte dat geloof ik wel.

[F_J_K]

AW_Bos schreef op zaterdag 21 februari 2026 @ 01:09:
Ligt het aan mij, of is er een update geweest waardoor je niet meer direct een afbeelding kan copy-pasten in de editor?

Copypaste doet hier (Firefox) vanuit de verkenner (copypaste file) en vanuit bijv. paint (copypaste "pixels") niets en als ik vanuit de image viewer plak krijg ik c:\users\... en dat gaat niet werken nee. Drag & drop gaat nog wel prima.

[crisp]

In de meeste gevallen krijg je een base64-encoded data:-url bij direct copy/paste van afbeeldingen in de editor, en daar bieden wij geen support voor, dus dat hebben we "uitgeschakeld". Of je iets naar je fotoalbum wilt uploaden moet een bewuste keuze zijn, dus ondersteunen we dat alleen vanuit de fotoalbum-dialoog.

[AW_Bos]

Dat is duidelijk. Is er ook een reden voor waarom het in de editor uitgeschakeld is? Waar de upload in het fotoalbum beide mogelijkheden (copy-paste van bestand én base-64 encoded string) aankan, kan de editor alleen maar het copy/pasten van eenbestandafbeelding aan. Of is dat iets wat nog gelijkgetrokken moet worden?

[crisp]

AW_Bos schreef op zaterdag 21 februari 2026 @ 11:09:
Dat is duidelijk. Is er ook een reden voor waarom het in de editor uitgeschakeld is? Waar de upload in het fotoalbum beide mogelijkheden (copy-paste van bestand én base-64 encoded string) aankan, kan de editor alleen maar het copy/pasten van eenbestandafbeelding aan. Of is dat iets wat nog gelijkgetrokken moet worden?

Het fotoalbum upload het naar de server en zet het in je fotoalbum, en dat moet imo een expliciete keuze zijn. De editor ondersteund alleen externe afbeeldingen op basis van een url. Base64 data:-urls zijn niet wenselijk en bieden wij vanuit RML ook geen support voor.

[AW_Bos]

Ah, dat is duidelijk.

[Vliegvlug]

Ik heb met de visuele editor in bepaalde situaties dat ik mijn cursor niet op de juiste plek geplaatst krijg, dat is dan onmogelijk. Je ziet de cursor er heel even staan maar dan schiet hij naar boven of onder.

Het hangt samen met de opmaak en de overgang tussen verschillende opmaakt, bij gewone tekst heb ik het niet.

Kwam het vanochtend weer tegen en deze keer screenshots gemaakt.
Gaat om deze situatie, een qoute van een post met een plaatje eronder waar in de spoiler tag op gezet heb:



Vervolgens wil ik mijn cursor plaatsen voor de s van “spoiler” om een toelichtende tekst tussen quote en foto te plaatsen.

Maar hoe ik ook mijn best doe de cursor komt er heel even te staan om vervolgens naar onder of boven te schieten.

Boven, dan komt hij aan het einde van de tekst in de quote:



Onder, dan komt hij voor het plaatje:



In broncode weergave zit de tekst er zo uit:


Dit is trouwens op een iPad met onscreen toetsenbord in Firefox.

[crisp]

Vliegvlug schreef op woensdag 25 februari 2026 @ 13:55:
Ik heb met de visuele editor in bepaalde situaties dat ik mijn cursor niet op de juiste plek geplaatst krijg, dat is dan onmogelijk. Je ziet de cursor er heel even staan maar dan schiet hij naar boven of onder.

Het hangt samen met de opmaak en de overgang tussen verschillende opmaakt, bij gewone tekst heb ik het niet.

[...]

Dat is inderdaad hetzelfde als wanneer je bijvoorbeeld 2 quotes na elkaar hebt. Daar zit fysiek dan geen 'ruimte' tussen, alleen marge. Wat je dan kan doen is je cursor aan het einde van het eerste tekstblok zetten en dan 2x keer enter geven.

[Vliegvlug]

crisp schreef op woensdag 25 februari 2026 @ 14:09:
[...]

Dat is inderdaad hetzelfde als wanneer je bijvoorbeeld 2 quotes na elkaar hebt. Daar zit fysiek dan geen 'ruimte' tussen, alleen marge. Wat je dan kan doen is je cursor aan het einde van het eerste tekstblok zetten en dan 2x keer enter geven.

Oh, wat apart want als je naar de broncode editor wisselt zit er wel een witregel tussen en die heb ik er niet later zelf in toegevoegd. Heb alles eerst in de wysiwyg editor gedaan en daarna pas naar broncode overgeschakeld.

[crisp]

Vliegvlug schreef op woensdag 25 februari 2026 @ 14:41:
[...]

Oh, wat apart want als je naar de broncode editor wisselt zit er wel een witregel tussen en die heb ik er niet later zelf in toegevoegd. Heb alles eerst in de wysiwyg editor gedaan en daarna pas naar broncode overgeschakeld.

Ja, in de broncode editor doen we een vorm van 'prettifying' om het leesbaar te maken. Maar uiteindelijk wordt de whitespace tussen dat soort elementen bij het parsen weer weggehaald.

[Toppe]

Het uploaden van een afbeelding staat nu onder ‘Meer’ en aangezien ik die functie best wel vaak gebruik merk ik eigelijk hoe irritant het is.

Bijvoorbeeld tekst in het midden zetten wordt volgens mij niet heel veel gebruikt?

Zou het niet mogelijk zijn om tekst links en midden te vervangen voor hyperlinks en afbeeldingen?

[crisp]

Toppe schreef op donderdag 5 maart 2026 @ 07:45:
[Afbeelding] Het uploaden van een afbeelding staat nu onder ‘Meer’ en aangezien ik die functie best wel vaak gebruik merk ik eigelijk hoe irritant het is.

Bijvoorbeeld tekst in het midden zetten wordt volgens mij niet heel veel gebruikt?

Zou het niet mogelijk zijn om tekst links en midden te vervangen voor hyperlinks en afbeeldingen?

Ja, we moeten nog eens goed naar de indeling kijken. Ook de inhoudsopgave zal niet vaak gebruikt worden denk ik. Maar de beperkte ruimte op mobiele devices zal altijd een uitdaging blijven ben ik bang..

[Toppe]

crisp schreef op donderdag 5 maart 2026 @ 07:51:
[...]

Ja, we moeten nog eens goed naar de indeling kijken. Ook de inhoudsopgave zal niet vaak gebruikt worden denk ik. Maar de beperkte ruimte op mobiele devices zal altijd een uitdaging blijven ben ik bang..

Klopt, als ik voor mij zelf kan spreken zou ik graag zien:

- tekst opties (zoals nu)
- vet
- Italic
- doorstreept
- afbeelding (upload, niet externe url)
- hyperlink
- lijst

Is het niet mogelijk om eventueel meerdere opties te maken zodat de gebruiker in zijn instellingen de voor hen werkende versie kan kiezen?

[ Voor 13% gewijzigd door Toppe op 06-03-2026 07:44 ]

[crisp]

Toppe schreef op vrijdag 6 maart 2026 @ 07:43:
[...]

Klopt, als ik voor mij zelf kan spreken zou ik graag zien:

- tekst opties (zoals nu)
- vet
- Italic
- doorstreept
- afbeelding (upload, niet externe url)
- hyperlink
- lijst

Ik denk dat dat redelijk overeen komt met onze statistieken qua tag-gebruik

Ik heb er in ieder geval een ticket voor gemaakt.

Is het niet mogelijk om eventueel meerdere opties te maken zodat de gebruiker in zijn instellingen de voor hen werkende versie kan kiezen?

Helaas zijn dergelijke customisatie-opties altijd duur in onderhoud, terwijl relatief gezien maar een heel klein deel van de gebruikers er daadwerkelijk gebruik van maakt. Ik denk dan ook niet dat we dat zullen overwegen.

[ Voor 3% gewijzigd door crisp op 06-03-2026 07:58 ]

[Rolfie]

Ik weet niet of dit normaal is, maar ik was een stukje text aan het type waarbij ik meerdere keren iets als 3 * 3 en later in de zin 4 * 4 moest typen. Maar bij het gebruik van de 2de *, veranderd de editor beide de tekst tussen de * als Italic. Een eventuele backspace, en daarna weer een *, loste dit niet op.

Ik had eerst iets van, ik moet meer koffie drinken, wat ik zal wel de iets met een i gedaan hebben (zit vlak bij de * natuurlijk), maar na meerdere keren dit gehad te hebben, kwam ik er achter dat dit blijkbaar iets normaal is. Wat ik heel vreemd vind, want juist meerdere keren een * gebruiken in tekst, is vrij normaal.

Ik snap niet de logica van, dat een * aangepast wordt in een editor naar italic tekst. Maar ik zou wel verwachten dat een backspace dit direct ongedaan maakt.


Is dit een bug of feature (die ik niet begrijp).

[Vliegvlug]

Rolfie schreef op zaterdag 7 maart 2026 @ 08:07:
Ik weet niet of dit normaal is, maar ik was een stukje text aan het type waarbij ik meerdere keren iets als 3 * 3 en later in de zin 4 * 4 moest typen. Maar bij het gebruik van de 2de *, veranderd de editor beide de tekst tussen de * als Italic. Een eventuele backspace, en daarna weer een *, loste dit niet op.

Ik had eerst iets van, ik moet meer koffie drinken, wat ik zal wel de iets met een i gedaan hebben (zit vlak bij de * natuurlijk), maar na meerdere keren dit gehad te hebben, kwam ik er achter dat dit blijkbaar iets normaal is. Wat ik heel vreemd vind, want juist meerdere keren een * gebruiken in tekst, is vrij normaal.

Ik snap niet de logica van, dat een * aangepast wordt in een editor naar italic tekst. Maar ik zou wel verwachten dat een backspace dit direct ongedaan maakt.


Is dit een bug of feature (die ik niet begrijp).

Ik kan dit niet reproduceren of ik snap niet wat je bedoelt.

Dit kan ik zonder problemen typen:
3*3 plus 4*4 of bedoel je 1*2*3*456*8=21.888.

Er gebeurt bij mij helemaal niets met italic.

Ik zit op een iPad met Firefox als browser

[F_J_K]

2 2 is 4 maar 4 4 niet. De spatie voor de ster zorgt er voor

2*2 is 4 maar 4*4 niet.

[Meg]

Maar kan je dan i.p.v. een * niet beter een _ doen om schuine tekst te krijgen bijvoorbeeld?

[Vliegvlug]

Meg schreef op zaterdag 7 maart 2026 @ 08:47:
Maar kan je dan i.p.v. een * niet beter een _ doen om schuine tekst te krijgen bijvoorbeeld?

Zou ik ook logischer vinden want * associeer ik met vet, maar kan ook komen omdat ik dit van whatsapp ken.

[Hero of Time]

Vliegvlug schreef op zaterdag 7 maart 2026 @ 08:25:
[...]

Ik kan dit niet reproduceren of ik snap niet wat je bedoelt.

Dit kan ik zonder problemen typen:
3*3 plus 4*4 of bedoel je 1*2*3*456*8=21.888.

Er gebeurt bij mij helemaal niets met italic.

Ik zit op een iPad met Firefox als browser

Heb je wel de wysiwig editor aan staan om te gebruiken? Want dit gedrag is alleen daar omdat er markdown wordt toegepast. Zolang je nog niet de beta gebruikt of op broncode zit, ga je het idd niet snappen.

[Vliegvlug]

Hero of Time schreef op zaterdag 7 maart 2026 @ 12:42:
[...]

Heb je wel de wysiwig editor aan staan om te gebruiken? Want dit gedrag is alleen daar omdat er markdown wordt toegepast. Zolang je nog niet de beta gebruikt of op broncode zit, ga je het idd niet snappen.

Uiteraard wel in de visuele editor geprobeerd. Maar zoals @F_J_K terecht opmerkt gebeurt het alleen als je een spatie achter de * doet.

Het stond in de post van @Rolfie wel met spaties maar ik dacht dat hij dat bewust gedaan had om te voorkomen dat de *'s zouden verdwijnen.

Foute aanname van mij

[Rolfie]

F_J_K schreef op zaterdag 7 maart 2026 @ 08:35:
2 2 is 4 maar 4 4 niet. De spatie voor de ster zorgt er voor

2*2 is 4 maar 4*4 niet.

Correct. Het was inderdaad met een spatie er bij. Het koste mij heel wat moeite om de logica te begrijpen, waarom dit aangepast was. Ik moet zeggen, ik snap nog steeds niet de logica, waarom je zit zou willen, of waarom als je een backspace doet, het daarna toch weer actief is.

Ik zou ook zeggen, dat ik niet de enige ben, die er spaties tussen zet.

Heel onlogisch, of misschien ben ik gewoon te oud om dit te snappen.

[Rolfie]

Vliegvlug schreef op zaterdag 7 maart 2026 @ 14:37:
[...]

Uiteraard wel in de visuele editor geprobeerd. Maar zoals @F_J_K terecht opmerkt gebeurt het alleen als je een spatie achter de * doet.

Het stond in de post van @Rolfie wel met spaties maar ik dacht dat hij dat bewust gedaan had om te voorkomen dat de *'s zouden verdwijnen.

Foute aanname van mij

Ik gebruik juist vaak spaties er tussen, voor de duidelijkheid.

Ik kon ook niet echt terugvinden, waarom dit zo was.

Ik kon ook niets echt terug vinden in Overzicht van UBB-codes

[Rolfie]

Meg schreef op zaterdag 7 maart 2026 @ 08:47:
Maar kan je dan i.p.v. een * niet beter een _ doen om schuine tekst te krijgen bijvoorbeeld?

En na een backspace dit juist negeren. Want nu deed ik de dubbel * icm copy past.

[Meg]

Ik vind ook dat smilies wel direct mogen werken, want als ik :) typ moet ik eerst een spatie doen alvoor ik krijg wat persoonlijk niet mijn voorkeur heeft.

[DaFeliX]

Rolfie schreef op zaterdag 7 maart 2026 @ 08:07:
Ik weet niet of dit normaal is, maar ik was een stukje text aan het type waarbij ik meerdere keren iets als 3 * 3 en later in de zin 4 * 4 moest typen. Maar bij het gebruik van de 2de *, veranderd de editor beide de tekst tussen de * als Italic. Een eventuele backspace, en daarna weer een *, loste dit niet op.

[...]
Is dit een bug of feature (die ik niet begrijp).

Er zit nog een bug in, dat als de editor opmaak toepast en je op backspace drukt, hij niet alleen de opmaak ongedaan maakt, maar ook het teken zelf "weghaalt". Ik zet dit tussen quotes, want eigenlijk haalt ie het teken niet weg, maar voeg ie hem gewoon nooit in - technisch gezien klopt het 'ongedaan maken' dus wel.

Deze bug zit in Tiptap zelf, we hebben nog een ticket om hier naar te kijken.

[Toppe]

Meg schreef op zaterdag 7 maart 2026 @ 18:33:
Ik vind ook dat smilies wel direct mogen werken, want als ik :) typ moet ik eerst een spatie doen alvoor ik krijg wat persoonlijk niet mijn voorkeur heeft.

Hoe doe je dat dan bij mensen die geen emojis willen typen? Ik ken genoeg mensen die alleen :) doen ipv en dat ook zou willen houden.

_{Al zou het denk denk ik technisch niet al te ingewikkeld moeten zijn om te zorgen dat je via je instellingen de fysieke weergave van de emojis uit te schakelen?}

[Vliegvlug]

De tabel maak functie is in de broncode editor stuk bij mij, betreft iPadOS met Firefox.

Ik kan niet zoals bij de originele editor een bepaald aantal vakjes selecteren door slepen maar er komt direct de volgende code in te staan zodra ik het tabel icoon maar aanraak:

[table border=1 width=350 cellpadding=2 bordercolor=#000000]
[tr]
[td][/td]
[/tr]
[/table]

Wat als je er een tekst <test> in zet als volgt wordt weergegeven:

<test>

Schakel ik vervolgens over naar de visuele editor dan kan ik daar weer wel met slepen het aantal cellen kiezen en als ik daar dan één cel maak met weer de tekst <test> dan ziet het er zo uit:

<test>

Dus zonder een rand er omheen. Wat in broncode er zo uit ziet:

[table]
[tr]
[td]<test>[/td]
[/tr]
[/table]

Dat verschil tussen beiden vind ik nogal inconsequent. Heb ook liever standaard een rand zodat het duidelijk een tabel is en niet wat met tabs of spaties gescheiden tekstblokjes. Over de cel breedte kan getwist worden maar automatische breedte of stuk minder breed zou mijn voorkeur hebben.

En uiteraard zou de tabel optie in de broncode editor ook gewoon moeten functioneren waarbij je de hoeveelheid cellen kan selecteren.

Ander vervelend ding van de visuele modus is dat het dropdown pijlje voor de opties binnen de cel wordt weergegeven en daarmee de tekst blokkeert zodat je niet ziet wat je typt:


Dat pijltje kan beter naast of boven de cel geplaatst worden zodat de tekst wel zichtbaar is.

[ Voor 3% gewijzigd door Vliegvlug op 20-03-2026 22:49 ]

[F_J_K]

Detail:
( wordt in de editor getoond als ( ) zonder spatie en staat er onderwater als (:*) maar zodra ik op Verstuur of Voorbeeld druk verandert het in (

[crisp]

Vliegvlug schreef op vrijdag 20 maart 2026 @ 22:41:
De tabel maak functie is in de broncode editor stuk bij mij, betreft iPadOS met Firefox.

Ik kan niet zoals bij de originele editor een bepaald aantal vakjes selecteren door slepen maar er komt direct de volgende code in te staan zodra ik het tabel icoon maar aanraak:

De tabel-functie in de RML/broncode versie is inderdaad wat simpeler en voegt alleen een soort van template toe. Er zijn geen plannen om dat daar aan te passen naar de versie die we voor de wysiwyg-editor hebben gebouwd waar je meteen het aantal rijen en kolommen kan aangeven.

Schakel ik vervolgens over naar de visuele editor dan kan ik daar weer wel met slepen het aantal cellen kiezen en als ik daar dan één cel maak met weer de tekst <test> dan ziet het er zo uit:

<test>

Dus zonder een rand er omheen. Wat in broncode er zo uit ziet:

[table]
[tr]
[td]<test>[/td]
[/tr]
[/table]

Dat verschil tussen beiden vind ik nogal inconsequent. Heb ook liever standaard een rand zodat het duidelijk een tabel is en niet wat met tabs of spaties gescheiden tekstblokjes. Over de cel breedte kan getwist worden maar automatische breedte of stuk minder breed zou mijn voorkeur hebben.

We hebben nog een ticket openstaan om de initiële styling van een nieuwe tabel in de wysiwyg-editor aan te passen (inderdaad: padding, breedte en border).

Ander vervelend ding van de visuele modus is dat het dropdown pijlje voor de opties binnen de cel wordt weergegeven en daarmee de tekst blokkeert zodat je niet ziet wat je typt:
[Afbeelding: Dropdown knop voor tabel blokkeert tekst in visuele editor]

Dat pijltje kan beter naast of boven de cel geplaatst worden zodat de tekst wel zichtbaar is.

Ook daar hebben we een ticket voor om te kijken of en hoe we dat kunnen verbeteren

[crisp]

F_J_K schreef op zaterdag 21 maart 2026 @ 13:59:
Detail:
( wordt in de editor getoond als ( ) zonder spatie en staat er onderwater als (:*) maar zodra ik op Verstuur of Voorbeeld druk verandert het in (

Ik kan dit niet reproduceren. We houden al expliciet rekening met :* versus :*), dus ik vraag me af hoe je dan toch () kan krijgen. Is dat met copy/pasten of zo?

[F_J_K]

Nope, ik type (in firefox) 4 karakters en dan enter: (

[F_J_K]

crisp schreef op maandag 23 maart 2026 @ 11:02:
[...]

Ik kan dit niet reproduceren. We houden al expliciet rekening met :* versus :*), dus ik vraag me af hoe je dan toch () kan krijgen. Is dat met copy/pasten of zo?

Als ik jouw post quote krijg ik

Er ging iets fout waardoor er niet overgeschakeld kan worden naar WYSIWYG. De foutcode is: Unable to translate, cannot find a translator for: norml

Als je denk dat dat dit een bug is, maak dan een bugmelding aan in Stoute Bugs.

[crisp]

F_J_K schreef op maandag 23 maart 2026 @ 11:09:
Nope, ik type (in firefox) 4 karakters en dan enter: (

Ik zie geen ?

F_J_K schreef op maandag 23 maart 2026 @ 11:10:
[...]

Als ik jouw post quote krijg ik

[...]

Klopt, \[norml] heeft geen ondersteuning in wysiwyg, en gaan we waarschijnlijk ook niet maken (te complex).

[F_J_K]

crisp schreef op maandag 23 maart 2026 @ 11:14:
[...]

Ik zie geen ?

Nee dat is juist het probleem

[crisp]

F_J_K schreef op maandag 23 maart 2026 @ 11:20:
[...]

Nee dat is juist het probleem

Ja, dus om een te krijgen moet je er niet direct een ) achter typen want dan wordt het een , da's toch logisch? (of :> gebruiken; dan is er geen overlap met :*) )

[F_J_K]

crisp schreef op maandag 23 maart 2026 @ 11:23:
[...]

Ja, dus om een te krijgen moet je er niet direct een ) achter typen want dan wordt het een , da's toch logisch? (of :> gebruiken; dan is er geen overlap met :*) )

Aaah. Feature, not bug. Nothing to see here, move along move along!

[AW_Bos]

crisp schreef op maandag 23 maart 2026 @ 11:14:
[...]

Ik zie geen ?


[...]

Klopt, \[norml] heeft geen ondersteuning in wysiwyg, en gaan we waarschijnlijk ook niet maken (te complex).

Zulke tags moeten uiteindelijk toch genegeerd/gerepareerd worden? De perfecte editor zou bij het omschakelen van Broncode naar Visueel geen errors mogen geven over de content. Enkel als het echt een bug in de editor is.

[ Voor 4% gewijzigd door AW_Bos op 23-03-2026 13:04 ]

[crisp]

AW_Bos schreef op maandag 23 maart 2026 @ 13:04:
[...]

Zulke tags moeten uiteindelijk toch genegeerd/gerepareerd worden? De perfecte editor zou bij het omschakelen van Broncode naar Visueel geen errors mogen geven over de content. Enkel als het echt een bug in de editor is.

De perfecte editor kost 10x meer tijd om te maken dan een bijna perfecte editor. Tijd die we steken in het ondersteunen van een tag die nagenoeg nooit gebruikt wordt kunnen we imo beter steken in andere zaken. In dit geval voorkomen we dat er naar wysiwyg kan worden overgeschakeld zodat er geen opmaak verloren gaat, en dat lijkt me een prima oplossing voor nu

De lijn tussen een bug en een tekortkoming is overigens vrij dun; de een wordt vaak als de ander gerapporteerd

[Hero of Time]

Maar het is wel een reëel probleem. F_J_K probeerde jou net te quoten en kreeg die error, want jij gebruikte de norml tag terwijl hij de wysiwyg editor aan heeft. Het is dus niet dat het zelden voorkomt, getuige het effect hier.

Iets van afhandeling van o.a. deze tag die niet ondersteund wordt zou beter zijn dan maar gewoon falen en niet kunnen reageren. Bijvoorbeeld geforceerd overschakelen naar broncode.

[F_J_K]

Dat laatste gebeurt ook: ik kreeg de broncode-view voor m'n snufferd

[XWB]

Hero of Time schreef op maandag 23 maart 2026 @ 18:53:

Iets van afhandeling van o.a. deze tag die niet ondersteund wordt zou beter zijn dan maar gewoon falen en niet kunnen reageren. Bijvoorbeeld geforceerd overschakelen naar broncode.

Dat gebeurt ook, de editor schakelt in zo'n situatie naar broncode zodat je verder kan reageren.

[Hero of Time]

Gelukkig zijn de Tweakers devs ook slim en hebben ze daar dus allang over nagedacht.

[Dirk]

https://gathering.tweakers.net/forum/get_messageversion/84944596/20991200

^^ Ik had daar twee quotes in elkaar gezet in plaats van boven elkaar door naar de bovenste regel te gaan en daar opnieuw op de quoteknop van een reactie de drukken. Het resultaat was niet nuttig.

Ja, alleen admins kunnen iets met dat linkje.

[ Voor 3% gewijzigd door Dirk op 28-03-2026 01:10 ]

[crisp]

Dirk schreef op zaterdag 28 maart 2026 @ 01:09:
https://gathering.tweakers.net/forum/get_messageversion/84944596/20991200

^^ Ik had daar twee quotes in elkaar gezet in plaats van boven elkaar door naar de bovenste regel te gaan en daar opnieuw op de quoteknop van een reactie de drukken. Het resultaat was niet nuttig.

Ja, alleen admins kunnen iets met dat linkje.

Ja, als je 'in' een quote staat dan is dat op zich logisch. Je moet je cursor in het begin van de quote zetten en dan enter geven om de quote te onderbreken en ruimte erboven te maken.

[Dirk]

Dat is technisch logisch, maar in het gebruik is zeker niet logisch.

[crisp]

Dirk schreef op zaterdag 28 maart 2026 @ 12:53:
Dat is technisch logisch, maar in het gebruik is zeker niet logisch.

Wat verwacht je dan dat er gebeurd? Een quote in een quote is namelijk gewoon mogelijk (wordt bij het parsen wel afgekort tot [...], maar toch).

[Dirk]

Als ik mijn cursor bovenin een reactie zet (binnenin de quote, want hoger kan ik niet zonder extra acties komen) en vervolgens bij een andere reactie op de quote-knop druk, dan verwacht ik dat de quote er volledig boven komt.

Het probleem zit hem waarschijnlijk vooral in de omgang met blokelementen aan het begin van de reactie, ik verwacht met mijn cursor er voor te kunnen komen, maar dat kan niet zonder expliciet een witregel toe te voegen. Ik verwacht dit andersom: wanneer ik mijn cursor voor een blokelement bij de start van een reactie zet (wat nu niet kan) en begin te typen, dan verwacht ik dat de witregel impliciet wordt toegevoegd.

Nu werden in de editor beide quotes getoond, de bovenste binnenin de eerste, dus de weergave klopte ook niet. Daardoor zag ik ook over het hoofd dat het fout ging tot na het plaatsen van de reactie.

[martijnsch]

Ik vroeg me af wat 'externe inhoud' precies doet.
Ik gok dat je hiermee dingen kan embedden zoals YouTube video's?
Naar mijn inziens mag er bij deze functionaliteit ergens in het dialoogvenster wel een uitleg in een zin, en misschien welke diensten er ondersteund worden, of een linkje naar meer info.

[AW_Bos]

Zijn er ook plannen om de WYSIWYG-editor in de DM-sectie te plaatsen? Volgens mij is de editor qua functionaliteit op het forum gelijk met de oude RML-editor in de Direct Messages pagina op send_privatemessage/.

[ Voor 9% gewijzigd door AW_Bos op 11-04-2026 10:03 ]

[crisp]

AW_Bos schreef op zaterdag 11 april 2026 @ 10:01:
Zijn er ook plannen om de WYSIWYG-editor in de DM-sectie te plaatsen? Volgens mij is de editor qua functionaliteit op het forum gelijk met de oude RML-editor in de Direct Messages pagina op send_privatemessage/.

Jazeker, daar staat nog een ticket voor open

[Vliegvlug]

Waar ik zojuist tegenaan loop is dat de “vast opmaak” optie anders werkt dan ik verwacht had.

Ik wilde namelijk een aantal woorden midden in een tekst vaste spatiëring geven.

Stap 1.
Ik selecteer de woorden:



Stap 2.
Kies “Vaste opmaak” helemaal onderaan uit het dropdown menu:



Stap 3.
Huh, de hele regel wordt vaste opmaak?

Terwijl de selectie zelfs nog actief is.
In code ziet dit er dan zo uit:

code:

[pre]Dit is een test tekst met fixed width font in het midden.[/pre]

(Waarbij ik de [pre]-tag niet eens kende maar dat is blijkbaar voor hele alinea’s in één keer van fixed-witdh font voorzien.)

Wat ik echter verwacht had was dat de tekst er zo uit zou zien:
“Dit is een test tekst met fixed width font in het midden.”
In code

code:

Dit is een test tekst met [mono]fixed width font[/mono] in het midden.

(staat me trouwens niet bij dat de tekst dan ook gearceerd werd vroeger, maar dat kan ook aan mijn gebrekkige geheugen liggen )

Zou graag zien dat de mogelijkheid om een selectie mono spaced te maken ook in de visuele editor wordt opgenomen. De “Meer”-optie helemaal rechts op de menubalk van de visuele editor lijkt me een ideale plek daarvoor!

[crisp]

Vliegvlug schreef op woensdag 15 april 2026 @ 09:33:
Waar ik zojuist tegenaan loop is dat de “vast opmaak” optie anders werkt dan ik verwacht had.

Ik wilde namelijk een aantal woorden midden in een tekst vaste spatiëring geven.

Stap 1.
Ik selecteer de woorden:
[Afbeelding: Wysiwyg visuele editor “Vaste opmaak optie” - stap 1]


Stap 2.
Kies “Vaste opmaak” helemaal onderaan uit het dropdown menu:
[Afbeelding: Wysiwyg visuele editor “Vaste opmaak optie” - stap 2]


Stap 3.
Huh, de hele regel wordt vaste opmaak?
[Afbeelding: Wysiwyg visuele editor “Vaste opmaak optie” - stap 3]
Terwijl de selectie zelfs nog actief is.
In code ziet dit er dan zo uit:

code:

[pre]Dit is een test tekst met fixed width font in het midden.[/pre]

(Waarbij ik de [pre]-tag niet eens kende maar dat is blijkbaar voor hele alinea’s in één keer van fixed-witdh font voorzien.)

Wat ik echter verwacht had was dat de tekst er zo uit zou zien:
“Dit is een test tekst met fixed width font in het midden.”
In code

code:

Dit is een test tekst met [mono]fixed width font[/mono] in het midden.

(staat me trouwens niet bij dat de tekst dan ook gearceerd werd vroeger, maar dat kan ook aan mijn gebrekkige geheugen liggen )

Zou graag zien dat de mogelijkheid om een selectie mono spaced te maken ook in de visuele editor wordt opgenomen. De “Meer”-optie helemaal rechts op de menubalk van de visuele editor lijkt me een ideale plek daarvoor!

Zie de hoofdletter M in je screenshot, net voor "Meer"

[Vliegvlug]

crisp schreef op woensdag 15 april 2026 @ 10:50:
[...]

Zie de hoofdletter M in je screenshot, net voor "Meer"

Oh, serieus!? Dat is fijn!

Nooit maar het idee gehad dat die “M” daarvoor stond, denk dat het heel erg helpt daar een Courier achtig font met schreef van te maken. Zoiets als dit: M

[Hahn]

Ik ben UX/UI Designer van beroep en ik heb letterlijk nog nooit die 'M' als icon gezien voor opmaak

Als je mij zou vragen wat het zou doen, dan zou ik zeggen dat ik verwacht dat Gmail zou openen ofzo

[Vliegvlug]

Hahn schreef op woensdag 15 april 2026 @ 11:22:
Ik ben UX/UI Designer van beroep en ik heb letterlijk nog nooit die 'M' als icon gezien voor opmaak

Als je mij zou vragen wat het zou doen, dan zou ik zeggen dat ik verwacht dat Gmail zou openen ofzo

Ik heb wel voordat ik postte de balk goed bekeken en zelfs onder “Meer” gekeken naar fixed-width maar die M lijkt inderdaad de lading niet te dekken vandaar dat ik ‘m totaal over het hoofd heb gezien. Waar het wel voor zou moeten staan had ik geen idee van maar de Gmail associatie snap ik wel.

[crisp]

Vliegvlug schreef op woensdag 15 april 2026 @ 11:20:
[...]

Oh, serieus!? Dat is fijn!

Nooit maar het idee gehad dat die “M” daarvoor stond, denk dat het heel erg helpt daar een Courier achtig font met scheef van te maken. Zoiets als dit: M

We gebruiken Font Awesome voor icoontjes, maar het is lastig om daar een geschikt icon te vinden voor "monospace" (suggesties zijn welkom!)

[Vliegvlug]

crisp schreef op woensdag 15 april 2026 @ 11:27:
[...]

We gebruiken Font Awesome voor icoontjes, maar het is lastig om daar een geschikt icon te vinden voor "monospace" (suggesties zijn welkom!)

Heb flink gezocht daar maar ze lijken bij Font Awesome inderdaad enkel schreefloze fonts te hebben.

Maar waar komt dat icoon met pijltje en T voor small font op de balk dan vandaan?
Die T lijkt wel schreef te zijn namelijk.

[crisp]

Vliegvlug schreef op woensdag 15 april 2026 @ 12:21:
[...]

Heb flink gezocht daar maar ze lijken bij Font Awesome inderdaad enkel schreefloze fonts te hebben.

Maar waar komt dat icoon met pijltje en T voor small font op de balk dan vandaan?
Die T lijkt wel schreef te zijn namelijk.

Haha, die is huisvlijt

[DUX]

crisp schreef op woensdag 15 april 2026 @ 11:27:
[...]

We gebruiken Font Awesome voor icoontjes, maar het is lastig om daar een geschikt icon te vinden voor "monospace" (suggesties zijn welkom!)

"arrows-left-right-to-line"?

[AW_Bos]

DUX schreef op woensdag 15 april 2026 @ 12:52:
[...]

"arrows-left-right-to-line"?
[Afbeelding]

Dat heeft meer weg van 'opvullen over een regel', vin dik.

[Vliegvlug]

crisp schreef op woensdag 15 april 2026 @ 12:27:
[...]

Haha, die is huisvlijt

Dan zou ik zeggen dat de hulp van diegene die dat icoon heeft gemaakt weer moet worden ingeroepen!

[Vliegvlug]

DUX schreef op woensdag 15 april 2026 @ 12:52:
[...]

"arrows-left-right-to-line"?
[Afbeelding]

Zelf zou ik die niet met monospace font associëren eerlijk gezegd.

[JelleDJs]

Ik moet zeggen dat ik enorme moeite had om deze comment te typen:
JelleDJs in "Meld hier spel- en tikfoutjes - en dus *geen* andere foutjes"

Ik werk constant in tekst editors zoals deze met Shift + Enter.
Vind ik nou eenmaal prettiger.

Blijkbaar gaat dat in combinatie met quotes compleet mis.

Ik had namelijk de tekst getypt die in de quote wilde hebben. Die selecteerde ik vervolgens en daarna klikte ik op 'Quote' (nadat ik überhaupt die knop niet kon vinden). Alleen toen ging het hele bericht in de quote. Blijkbaar ziet quote alleen de tekst tussen twee 'normale' enters? Waarom niet puur de geselecteerde tekst?

Daarnaast nog iets anders wat ik regelmatig tegenkom, als ik boven een icoontje in de balk blijf staan met mijn cursor, komen er bij de meeste een tekstje erbij (tool-tip heet dit, toch?) met wat het doet. Echter, bij de "Tekst verkleinen" verschijnt die vaak, in eerste instantie, niet bij mij. En als ik die vervolgens heb getest, werkt die bij veel meer niet.
Zit hier een regel aan vast dat het maar één keer per icoontje mag?

[crisp]

JelleDJs schreef op woensdag 22 april 2026 @ 10:57:
Ik moet zeggen dat ik enorme moeite had om deze comment te typen:
JelleDJs in "Meld hier spel- en tikfoutjes - en dus *geen* andere foutjes"

Ik werk constant in tekst editors zoals deze met Shift + Enter.
Vind ik nou eenmaal prettiger.

Blijkbaar gaat dat in combinatie met quotes compleet mis.

Ik had namelijk de tekst getypt die in de quote wilde hebben. Die selecteerde ik vervolgens en daarna klikte ik op 'Quote' (nadat ik überhaupt die knop niet kon vinden). Alleen toen ging het hele bericht in de quote. Blijkbaar ziet quote alleen de tekst tussen twee 'normale' enters? Waarom niet puur de geselecteerde tekst?

Je hoeft geen tekst te selecteren om iets om te zetten naar een quote. Quote is een text-style toggle die werkt op de hele paragraaf waar je op dat moment in zit. Maar aangezien jij niet met paragrafen werkt (door shift+enter te gebruiken) heb je eigenlijk 1 grote paragraaf die helemaal omgezet wordt. Je zal hier dus toch je werkwijze op aan moeten passen ben ik bang...

Daarnaast nog iets anders wat ik regelmatig tegenkom, als ik boven een icoontje in de balk blijf staan met mijn cursor, komen er bij de meeste een tekstje erbij (tool-tip heet dit, toch?) met wat het doet. Echter, bij de "Tekst verkleinen" verschijnt die vaak, in eerste instantie, niet bij mij. En als ik die vervolgens heb getest, werkt die bij veel meer niet.
Zit hier een regel aan vast dat het maar één keer per icoontje mag?

(deze) Tooltips zijn een standaard browser-feature. Dit is dus geen gedrag dat door onze code wordt veroorzaakt.

[True]

Met: .plan: Wysiwygeditor in gebruik op het forum - Development-iteratie #336 zou een titel fix hier wellicht wel passend zijn.

[crisp]

True schreef op woensdag 6 mei 2026 @ 12:37:
Met: .plan: Wysiwygeditor in gebruik op het forum - Development-iteratie #336 zou een titel fix hier wellicht wel passend zijn.

Bij deze

[Vliegvlug]

Ik ben inmiddels wel aardig gewend aan de visuele editor maar voor één ding blijf ik toch consequent terug naar de broncode editor gaan; namelijk als ik foto’s in de tekst heb ingevoegd.

Die zijn zodanig groot in vergelijking met het beschikbare teskteditveld dat het ik er elke keer tegenaan loopt dat het me niet goed lukt na invoegen van een foto het overzicht te behouden of om voor of na een foto uit te komen om wat aan te passen in mijn post en daarbij de foto onbedoeld selecteer of wis.
En daarnaast is het ook niet mogelijk de afbeeldingstekst aan te passen, dat kan zover ik zie enkel in broncode modus.

De mogelijkheid om ipv de volledige foto een placeholder of miniatuur afbeelding mét weergave en edit mogelijk van de afbeeldingstekst in de visuele editor weer te kunnen geven zou voor mij erg welkom zijn!

Doordat ook de visuele editor de optie “Toon voorbeeld” heeft, heeft dit verder geen impact op de mogelijkheid om te zien hoe je post er uiteindelijk na posten uit komt te zien. Want dat is tenslotte waar die optie voor is niet waar!

[crisp]

Vliegvlug schreef op woensdag 6 mei 2026 @ 13:40:
Ik ben inmiddels wel aardig gewend aan de visuele editor maar voor één ding blijf ik toch consequent terug naar de broncode editor gaan; namelijk als ik foto’s in de tekst heb ingevoegd.

Die zijn zodanig groot in vergelijking met het beschikbare teskteditveld dat het ik er elke keer tegenaan loopt dat het me niet goed lukt na invoegen van een foto het overzicht te behouden of om voor of na een foto uit te komen om wat aan te passen in mijn post en daarbij de foto onbedoeld selecteer of wis.
En daarnaast is het ook niet mogelijk de afbeeldingstekst aan te passen, dat kan zover ik zie enkel in broncode modus.

De mogelijkheid om ipv de volledige foto een placeholder of miniatuur afbeelding mét weergave en edit mogelijk van de afbeeldingstekst in de visuele editor weer te kunnen geven zou voor mij erg welkom zijn!

Doordat ook de visuele editor de optie “Toon voorbeeld” heeft, heeft dit verder geen impact op de mogelijkheid om te zien hoe je post er uiteindelijk na posten uit komt te zien. Want dat is tenslotte waar die optie voor is niet waar!

Wat bedoel je met "afbeeldingstekst"? Afaik zijn alle image properties in de wysiwyg-editor aan te passen.

Je zou met custom css de styling van img.rml in de editor kunnen overrulen door deze een fixed hoogte/breedte te geven; dan heb je ongeveer wat je zou willen.

[Vliegvlug]

crisp schreef op woensdag 6 mei 2026 @ 14:48:
[...]

Wat bedoel je met "afbeeldingstekst"? Afaik zijn alle image properties in de wysiwyg-editor aan te passen.

Je hebt gelijk, ik was er nog niet achtergekomen hoe dat moest, ingedrukt houden van een afbeelding werkte namelijk niet maar ben er inmiddels achtergekomen dat je eerst de afbeelding moet selecteren en dan op de werbalk het afbeelding ikoon moet indrukken.

Ik knip en plak altijd uit de gallerij dus dat ikoon nooit gebruikt maar daarmee is inderdaad van alles in te stellen

Je zou met custom css de styling van img.rml in de editor kunnen overrulen door deze een fixed hoogte/breedte te geven; dan heb je ongeveer wat je zou willen.

Daar zou ik me dan eerst in moeten verdiepen, heb nog nooit wat gedaan met custom css en waar je dat dan moet instellen weet ik ook nog niet, maar klinkt inderdaad wel als iets wat kan gaan werken.

Maar een dergelijke functionaliteit in de editor inbouwen is geen optie?
Ik zal toch niet de enige zijn die tegen het feit aanloopt dat het editorveld zodanig krap is dat die plaatjes onevenredig veel ruimte innemen?

Het kunnen vergoten van het editor tekstvak zou ook al enorm helpen.

[crisp]

Vliegvlug schreef op woensdag 6 mei 2026 @ 15:14:
[...]

Het kunnen vergoten van het editor tekstvak zou ook al enorm helpen.

Maar dat kan ook, maar wel (letterlijk) tot zekere hoogte (en breedte). We willen het forum nog iets breder maken waarmee de editor ook nog iets breder kan op desktop.

[Vliegvlug]

crisp schreef op woensdag 6 mei 2026 @ 15:21:
[...]

Maar dat kan ook, maar wel (letterlijk) tot zekere hoogte (en breedte). We willen het forum nog iets breder maken waarmee de editor ook nog iets breder kan op desktop.

Fijn dat het iets breder gaat worden.

Maar hoe kan ik het editorveld vergroten?

Ik zie er geen mogelijkheid voor namelijk:



Dit is wat ik nu heb op mijn iPad met Firefox als browser.

[crisp]

Vliegvlug schreef op woensdag 6 mei 2026 @ 15:39:
[...]

Fijn dat het iets breder gaat worden.

Maar hoe kan ik het editorveld vergroten?

Ik zie er geen mogelijkheid voor namelijk:
[Afbeelding: Editor in visual mode op Apple iPad in Firefox browser]


Dit is wat ik nu heb op mijn iPad met Firefox als browser.

Dat is een browserfeature, dan zullen browsers op iOS dat misschien niet hebben...

[Raven]

Nou, inmiddels de nieuwe editor geprobeerd, maar ik wordt niet blij van de nieuwe enter-functie Kan dat gedrag aangepast worden waarbij wat nu shift-enter is, met alleen enter gebeurt? Net ff door topic geskimmed, maar zag niet zo gauw wat, of ik kijk er overheen.

edit: Switchen naar broncode lijkt de oplossing.

[ Voor 8% gewijzigd door Raven op 06-05-2026 17:42 ]

[Vliegvlug]

Raven schreef op woensdag 6 mei 2026 @ 17:34:
Nou, inmiddels de nieuwe editor geprobeerd, maar ik wordt niet blij van de nieuwe enter-functie

Jij bent niet de enige!
Zie Vliegvlug in "Wysiwyg-editor nu ook live op het forum" en de discussie daarna.

Kan dat gedrag aangepast worden waarbij wat nu shift-enter is, met alleen enter gebeurt? Net ff door topic geskimmed, maar zag niet zo gauw wat, of ik kijk er overheen.

Je kan het shift-enter gedrag ook krijgen door 2x spatie + enter te typen!
Dit is een work-around die is ingebouwd want het is heel ingewikkeld om de editor om te bouwen naar “enter is nieuwe regel in dezelfde alinea”, zie crisp in "Wysiwyg-editor nu ook live op het forum"

Ik vind het nog steeds wel jammer maar er is voor mij inmiddels goed te werken met deze work-around dus ben blij dat die er is!

edit: Switchen naar broncode lijkt de oplossing.

Dat werkt ook ja maar vind de visuele editor een stuk fijner voor de meeste zaken.

[YakuzA]

Vliegvlug schreef op woensdag 6 mei 2026 @ 17:56:
[...]

Jij bent niet de enige!
Zie Vliegvlug in "Wysiwyg-editor nu ook live op het forum" en de discussie daarna.
[...]

Je kan het shift-enter gedrag ook krijgen door 2x spatie + enter te typen!
Dit is een work-around die is ingebouwd want het is heel ingewikkeld om de editor om te bouwen naar “enter is nieuwe regel in dezelfde alinea”, zie crisp in "Wysiwyg-editor nu ook live op het forum"

Ik vind het nog steeds wel jammer maar er is voor mij inmiddels goed te werken met deze work-around dus ben blij dat die er is!
[...]

Dat werkt ook ja maar vind de visuele editor een stuk fijner voor de meeste zaken.

Posts met dit soort gesplitste quotes zijn iig een drama om te maken in de 'visual' mode.
Ook tags die niet in de standaard dropdown staan zijn niet meer in te voegen. in de visual mode kun je bepaald UBB codes zoals [embed] meer gebruiken.

[Vliegvlug]

YakuzA schreef op woensdag 6 mei 2026 @ 18:26:
[...]

Posts met dit soort gesplitste quotes zijn iig een drama om te maken in de 'visual' mode.

Nee hoor, gewoon midden in een quote je cursor neerzetten waar je de splitsing wilt hebben en 2x enter!

Ook tags die niet in de standaard dropdown staan zijn niet meer in te voegen. in de visual mode kun je bepaald UBB codes zoals [embed] meer gebruiken.

Dat is wel een beperking ja maar alsnog is het stuk beter dan enkel de broncode editor waarbij een tabel invoegen bijvoorbeeld helemaal niet te doen was. Paar keer gedaan maar werd helemaal gek van de hoeveelheid copy-paste die daarvoor nodig was.

[crisp]

YakuzA schreef op woensdag 6 mei 2026 @ 18:26:
[...]

Posts met dit soort gesplitste quotes zijn iig een drama om te maken in de 'visual' mode.
Ook tags die niet in de standaard dropdown staan zijn niet meer in te voegen. in de visual mode kun je bepaald UBB codes zoals [embed] meer gebruiken.

Embeds kan je toevoegen mbv het playbuttonicoontje (omdat de meeste embeds nu eenmaal video's zijn). Wel willen de preview daarvan nog wel gaan verbeteren, maar het is wel functioneel.