Wysiwyg-editor als bètafeature

[Vliegvlug]

Meg schreef op zaterdag 31 januari 2026 @ 17:01:
Ik weet niet of dit al gevraagd is maar zou wanneer je een enter geeft de mogelijkheid kunnen komen om geen witregel er tussen te hebben?

Ik vind het persoonljk erg irritant om shift+enter te gebruiken om geen witregel te krijgen.

Ik ook dus je bent niet de enige!

Zie eerdere posts hierover van @MazeWing
En de eerdere posts hierover van mij.

Zou die even doornemen om je op dit issue in te lezen.

[Meg]

Ah, dank @Vliegvlug!

[AW_Bos]

Het is erg handig dat je aan de hand van :) een smilie kan plaatsen, zoals: . Maar voor de *O* ligt dat anders. Ik zie dat dit automatisch het volgende wordt, inplaats van de vrolijke pop-pom-smiley . Misschien moeten smilies eerst gecontroleerd worden in plaats van mark-down tags?

Eerst wordt het een mark-down'd cursieve O. En na een spatie wordt het een lege single opsomming?

[ Voor 12% gewijzigd door AW_Bos op 02-02-2026 13:48 ]

[AW_Bos]

Ik heb nog even gekeken naar het handmatig intypen van de smilies, om die automatisch te laten tonen, maar ook daar gaan een paar smiley de mist in:

wordt een smilie met een )

:twk: en :henk: worden niet geparsed

[crisp]

AW_Bos schreef op maandag 2 februari 2026 @ 13:58:
Ik heb nog even gekeken naar het handmatig intypen van de smilies, om die automatisch te laten tonen, maar ook daar gaan een paar smiley de mist in:

wordt een smilie met een )

Die kan ik fixen; dat is hetzelfde als :Y versus :Y)

:twk: en :henk: worden niet geparsed

Het is ook zonder dubbele punt erachter

[crisp]

AW_Bos schreef op maandag 2 februari 2026 @ 13:46:
Het is erg handig dat je aan de hand van :) een smilie kan plaatsen, zoals: . Maar voor de *O* ligt dat anders. Ik zie dat dit automatisch het volgende wordt, inplaats van de vrolijke pop-pom-smiley . Misschien moeten smilies eerst gecontroleerd worden in plaats van mark-down tags?

Eerst wordt het een mark-down'd cursieve O. En na een spatie wordt het een lege single opsomming?

Dat is niet te fixen door een volgorde om te draaien; de markdown triggert al op het typen van de laatste *, terwijl de smiley nog een spatie, enter of leesteken daarna vereist. Ik weet zo ook even niet hoe we dit het beste kunnen fixen; hooguit door deze specifieke sequence te negeren als markdown oid...

[TheVivaldi]

Ik heb geregeld last van dat de bewerker ineens op visueel staat, terwijl ik aangegeven heb de broncodebewerker te willen. Dit gebeurt zowel op de FP als op het forum (maar ik zit meer op de FP, dus daar merk ik het het vaakst). Er is geen pijl op te trekken wanneer het gebeurt, maar het is wel rete-irritant.

[crisp]

TheVivaldi schreef op maandag 2 februari 2026 @ 16:18:
Ik heb geregeld last van dat de bewerker ineens op visueel staat, terwijl ik aangegeven heb de broncodebewerker te willen. Dit gebeurt zowel op de FP als op het forum (maar ik zit meer op de FP, dus daar merk ik het het vaakst). Er is geen pijl op te trekken wanneer het gebeurt, maar het is wel rete-irritant.

Moet ik morgen even checken, maar ik meen dat het in een losse cookie onthouden wordt. Als je regelmatig (of automatisch) je cookies trashed dan kan dat het gedrag verklaren.

[crisp]

@TheVivaldi het wordt clientside bijgehouden in local storage

[TheVivaldi]

crisp schreef op maandag 2 februari 2026 @ 19:14:
[...]

Moet ik morgen even checken, maar ik meen dat het in een losse cookie onthouden wordt. Als je regelmatig (of automatisch) je cookies trashed dan kan dat het gedrag verklaren.

Ik ben nogal ouderwets en gooi mijn cookies nooit weg.

[TheVivaldi]

crisp schreef op dinsdag 3 februari 2026 @ 07:58:
@TheVivaldi het wordt clientside bijgehouden in local storage

Die leeg ik ook nooit.

[crisp]

TheVivaldi schreef op dinsdag 3 februari 2026 @ 10:48:
[...]

Die leeg ik ook nooit.

Dan weet ik het ook niet... Benieuwd of meer mensen daar last van hebben.

[beeldbuijs]

Ik gebruik zelden de broncode-stand. Ik denk de meeste mensen niet. Dus dan merk je het ook niet als de editor spontaan naar de visuele stand zou gaan, want daar zit je al.

Het valt me wel op dat nog steeds regelmatig de verzendknop van de FP editor niet werkt. Niets helpt dan, alleen tekst kopiëren naar je klembord, pagina herladen en opnieuw doen.

[DaFeliX]

Zoals ik al eerder aangaf (hier of in een .plan) dat het introduceren van extra complexiteit als een 'toggle' voor "enter=harde break/nieuwe paragraaf" onwenselijk is. Maar we begrijpen heus ook wel wel de frustratie die sommigen hiermee ervaren.

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.

Ik tag even wat mensen die deze feedback hadden gegeven in dit topic hier over: @CAPSLOCK2000 @Cambionn @sus @MazeWing @Paul @Sissors @Proton_ @Vliegvlug @Mog @Finraziel @beeldbuijs

Hopelijk helpt dit een beetje

[crisp]

beeldbuijs schreef op dinsdag 3 februari 2026 @ 15:26:
Ik gebruik zelden de broncode-stand. Ik denk de meeste mensen niet. Dus dan merk je het ook niet als de editor spontaan naar de visuele stand zou gaan, want daar zit je al.

Het valt me wel op dat nog steeds regelmatig de verzendknop van de FP editor niet werkt. Niets helpt dan, alleen tekst kopiëren naar je klembord, pagina herladen en opnieuw doen.

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?

[Sissors]

DaFeliX schreef op woensdag 4 februari 2026 @ 08:31:
Zoals ik al eerder aangaf (hier of in een .plan) dat het introduceren van extra complexiteit als een 'toggle' voor "enter=harde break/nieuwe paragraaf" onwenselijk is. Maar we begrijpen heus ook wel wel de frustratie die sommigen hiermee ervaren.

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.

Ik tag even wat mensen die deze feedback hadden gegeven in dit topic hier over: @CAPSLOCK2000 @Cambionn @sus @MazeWing @Paul @Sissors @Proton_ @Vliegvlug @Mog @Finraziel @beeldbuijs

Hopelijk helpt dit een beetje

Mijn feedback was dat het wel prima was dat er standaard een nieuwe alinea komt, dus weet niet of ik de juiste persoon ben voor feedback

Maar om toch te geven: Ongeveer drie mensen gaan dit gebruiken. En voor die drie is het mooi natuurlijk dat voor hun een irritatie is opgelost, maar de rest die het onhandig vindt accepteert het maar gewoon. Het is echter niet iets wat iemand uit zichzelf gaat vinden.

[crisp]

Sissors schreef op woensdag 4 februari 2026 @ 08:49:
[...]

Mijn feedback was dat het wel prima was dat er standaard een nieuwe alinea komt, dus weet niet of ik de juiste persoon ben voor feedback

Maar om toch te geven: Ongeveer drie mensen gaan dit gebruiken. En voor die drie is het mooi natuurlijk dat voor hun een irritatie is opgelost, maar de rest die het onhandig vindt accepteert het maar gewoon. Het is echter niet iets wat iemand uit zichzelf gaat vinden.

Daarom is er ook een helpfunctie

[MazeWing]

Sissors schreef op woensdag 4 februari 2026 @ 08:49:
[...]

Mijn feedback was dat het wel prima was dat er standaard een nieuwe alinea komt, dus weet niet of ik de juiste persoon ben voor feedback

Maar om toch te geven: Ongeveer drie mensen gaan dit gebruiken. En voor die drie is het mooi natuurlijk dat voor hun een irritatie is opgelost, maar de rest die het onhandig vindt accepteert het maar gewoon. Het is echter niet iets wat iemand uit zichzelf gaat vinden.

Gezien het feit dat heel veel apps standaard gewoon een nieuwe regel doen ipv een paragraaf lijkt het me dat heel veel mensen hier hinder van gaan ondervinden. Weet iedereen dit topic wel te vinden en/of moeite doen te reageren.

Maar blij dat er nu een workaround is die ook op iOS werkt!

[Vliegvlug]

DaFeliX schreef op woensdag 4 februari 2026 @ 08:31:
Zoals ik al eerder aangaf (hier of in een .plan) dat het introduceren van extra complexiteit als een 'toggle' voor "enter=harde break/nieuwe paragraaf" onwenselijk is. Maar we begrijpen heus ook wel wel de frustratie die sommigen hiermee ervaren.

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.

Ik tag even wat mensen die deze feedback hadden gegeven in dit topic hier over: @CAPSLOCK2000 @Cambionn @sus @MazeWing @Paul @Sissors @Proton_ @Vliegvlug @Mog @Finraziel @beeldbuijs

Hopelijk helpt dit een beetje

Dat helpt zeker!

Erg fijn dat er nu een oplossing is voor de mensen die eenhandig typen en de Apple gebruikers, zonder dat er naar de broncode editor gewisseld hoeft te worden
Super bedankt! @crisp

Het zal nog wel enige tijd kosten voordat het maken van een zin op een nieuwe regel op deze manier in mijn systeem zit maar kan nu wel eindelijk de visuele editor eens goed gaan testen. Merkte dat ik toch in de broncode editor bleef hangen als ik daarnaartoe was gewisseld om een zin op een nieuwe regel te krijgen.

[Vliegvlug]

Zal wel toeval zijn maar de gelijk de eerste dat ik met goede moed de visuele editor gebruik gaat het meteen al fout.

Ik wil reageren op deze post: .jef in "[Multi] Clair Obscur: Expedition 33"

Mijn editor staat vooraf op visuele modus maar zodra ik bovenstaande post wil quoten opent deze in de broncode editor met de melding:
“Er ging iets fout waardoor er niet overgeschakeld kan worden naar WYSIWYG. De foutcode is: Unsupported attribute(s): title”

[crisp]

Vliegvlug schreef op woensdag 4 februari 2026 @ 11:16:
Zal wel toeval zijn maar de gelijk de eerste dat ik met goede moed de visuele editor gebruik gaat het meteen al fout.

Ik wil reageren op deze post: .jef in "[Multi] Clair Obscur: Expedition 33"

Mijn editor staat vooraf op visuele modus maar zodra ik bovenstaande post wil quoten opent deze in de broncode editor met de melding:
“Er ging iets fout waardoor er niet overgeschakeld kan worden naar WYSIWYG. De foutcode is: Unsupported attribute(s): title”

[Afbeelding: Foutmelding bij quoten van post, visuele editor wil niet, broncode editor wordt in plaats daarvan ge]

Het is ook niet voor niets een bèta; er zijn nog zaken waar ondersteuning voor onbreekt, zoals een titel bij een spoiler (al moet ik toegeven dat ik die zelf nog niet op de radar had, dus daar moet een nieuw ticket voor komen).

We verwachten wel dat we dit soort zaken in de komende weken zoveel mogelijk op kunnen lossen voordat we overgaan naar een release voor iedereen

[Vliegvlug]

crisp schreef op woensdag 4 februari 2026 @ 11:24:
[...]

Het is ook niet voor niets een bèta; er zijn nog zaken waar ondersteuning voor onbreekt, zoals een titel bij een spoiler (al moet ik toegeven dat ik die zelf nog niet op de radar had, dus daar moet een nieuw ticket voor komen).

Is ook niet als kritiek bedoelt maar als bug report.
Leek me hier meer op zijn plek dan een heel nieuw topig in Stoute Bugs openen. Maar als dat juist wenselijker is hoor ik het graag.

Ik had ook geen idee waar het door kwam, dat je in een spoiler een titel kan opvoeren wist ik eigenlijk niet, lijkt me wel handig.
Maar in de visuele editor lijkt daar vervolgens geen mogelijkheid voor, maar dat is waarschijnlijk iets wat nog geïmplementeerd moet worden zeker?

We verwachten wel dat we dit soort zaken in de komende weken zoveel mogelijk op kunnen lossen voordat we overgaan naar een release voor iedereen

[Cambionn]

DaFeliX schreef op woensdag 4 februari 2026 @ 08:31:
Zoals ik al eerder aangaf (hier of in een .plan) dat het introduceren van extra complexiteit als een 'toggle' voor "enter=harde break/nieuwe paragraaf" onwenselijk is. Maar we begrijpen heus ook wel wel de frustratie die sommigen hiermee ervaren.

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.

Ik tag even wat mensen die deze feedback hadden gegeven in dit topic hier over: @CAPSLOCK2000 @Cambionn @sus @MazeWing @Paul @Sissors @Proton_ @Vliegvlug @Mog @Finraziel @beeldbuijs

Hopelijk helpt dit een beetje

Een witregel is de lege regel tussen 2 paragrafen in. Die voer je juist niet in nu .

Even los daarvan. Heb het getest en het werkt idd. Maar het grootste verschil is dat dit op de telefoon werkt, wat aan zich fijn is voor de momenten dat ik idd gewoon een regel recht eronder wil. Dat kan met de oude shift+enter niet (die nog wel werkt op desktop. Gelukkig, want dat is semi-standaard op websites die dit hebben en niet uit kunnen zitten en dus wat ik meteen pak als het weer eens mis gaat. Hoewel dat in je systeem zetten voor al je typen ook niet handig is, omdat dat weer vaak mis gaat met opmaak omdat websites opmaak per paragraaf doen en dan denken dat nieuwe paragrafen onderdeel zijn van de voorgaande. Laat Tweakers dat aub niet ook invoeren).

Maar verder blijft het natuurlijk dat je:

1. 3 karakters moet typen ipv op enter drukken (spatie + spatie + enter). De "enter + enter + backspace" waar ik nu steeds mee eindig kost net zo veel kliks. En ja, dat moet ik nog steeds continue doen met die nieuwe editor, want wennen doe ik er niet aan .
2. Vrijwel alle veelgebruikte software gewoon ingesteld kan worden (en hier ingesteld staat) om op 1x enter de volgende regel te pakken, en je voor Tweakers dus een andere tiep gewoonte moet aanleren. Precies waarom ik dus steeds verkeerd tiep als ik bij Tweakers een bericht tiep. En ik heb echt geen zin om al mijn andere software en gewoontes te veranderen voor Tweakers . Daarbij zijn er ook genoeg andere websites waar ik op zit waar enter nog ouderwets volgende regel is, dus al zou ik alles aanpassen dan loop ik daar tegen hetzelfde aan.

Dat zijn ook problemen die je niet oplost tenzij je een optie hebt de default aan te passen. Dus ik blijf erbij dat een harde setting, ondanks dat je aangeeft dat niet te gaan doen, de enige echte oplossing is.

Overigens nog wel de bijvoeging, dat ik op dit puntje na echt blij ben met de editor en hem heel fijn vind. Moge het duidelijk zijn dat jullie best wat goed werk doen wat ik zeer waardeer. En ik snap ook dat er tegenwoordig 2 standaarden zijn, en er mensen zijn die een voorkeur hebben voor hoe het nu is. Ik wil ook echt niet over brengen dat jullie fout bezig zijn, maar meer waar ik persoonlijk tegenaan loop (en waarschijnlijk meer mensen die gewend zijn aan of een voorkeur hebben voor). Ik zal Tweakers er ook echt niet om laten liggen. Maar schijtirritant vind ik het (persoonlijk) wel elke keer als ik op enter druk.

[crisp]

Vliegvlug schreef op woensdag 4 februari 2026 @ 11:39:
[...]

Is ook niet als kritiek bedoelt maar als bug report.
Leek me hier meer op zijn plek dan een heel nieuw topig in Stoute Bugs openen. Maar als dat juist wenselijker is hoor ik het graag.

Ik had ook geen idee waar het door kwam, dat je in een spoiler een titel kan opvoeren wist ik eigenlijk niet, lijkt me wel handig.
Maar in de visuele editor lijkt daar vervolgens geen mogelijkheid voor, maar dat is waarschijnlijk iets wat nog geïmplementeerd moet worden zeker?


[...]

Dit topic is ook bedoelt voor dit soort feedback, sec gezien zijn nogniet-ondersteunde functies ook geen bugs (en de meesten hebben we wel op de backlog staan)

[Vliegvlug]

Cambionn schreef op woensdag 4 februari 2026 @ 11:45:
[...]

1. 3 karakters moet typen ipv op enter drukken (spatie + spatie + enter). De "enter + enter + backspace" waar ik nu steeds mee eindig kost net zo veel kliks. En ja, dat moet ik nog steeds continue doen met die nieuwe editor, want wennen doe ik er niet aan .

Wat bedoel je met “enter + enter + backspace"?
Als ik dat hier doe is dat niet anders dan 1x enter typen namelijk, want de backspace haalt de tweede enter weer weg, of mis ik iets

Dat zijn ook problemen die je niet oplost tenzij je een optie hebt de default aan te passen. Dus ik blijf erbij dat een harde setting, ondanks dat je aangeeft dat niet te gaan doen, de enige echte oplossing is.

Dat zou inderdaad een stuk fijner zijn ja maar begreep dat dat heel erg ingewikkeld is, zie crisp in "Wysiwyg-editor als bètafeature"

Overigens nog wel de bijvoeging, dat ik op dit puntje na echt blij ben met de editor en hem heel fijn vind. Moge het duidelijk zijn dat jullie best wat goed werk doen wat ik zeer waardeer. En ik snap ook dat er tegenwoordig 2 standaarden zijn, en er mensen zijn die een voorkeur hebben voor hoe het nu is. Ik wil ook echt niet over brengen dat jullie fout bezig zijn, maar meer waar ik persoonlijk tegenaan loop (en waarschijnlijk meer mensen die gewend zijn aan of een voorkeur hebben voor). Ik zal Tweakers er ook echt niet om laten liggen. Maar schijtirritant vind ik het (persoonlijk) wel elke keer als ik op enter druk.

Ik vind het ook heel irritant ja maar ben wel blij dat er tenminste een alternatief is, dat is 100x beter dan helemaal geen alternatief en steeds terug moeten naar de broncode editor.

[Cambionn]

Vliegvlug schreef op woensdag 4 februari 2026 @ 12:00:
Wat bedoel je met “enter + enter + backspace"?
Als ik dat hier doe is dat niet anders dan 1x enter typen namelijk, want de backspace haalt de tweede enter weer weg, of mis ik iets

Dat is idd hetzelfde. Maar omdat ik normaal dus met een "enter = volgende regel" setup werk, druk ik automatisch 2x op enter als ik een nieuwe paragraaf wil beginnen. Maar dan heb ik dus een enorme ruimte, en moet ik weer 1 enter weg halen .

Vliegvlug schreef op woensdag 4 februari 2026 @ 12:00:
Dat zou inderdaad een stuk fijner zijn ja maar begreep dat dat heel erg ingewikkeld is, zie crisp in "Wysiwyg-editor als bètafeature"

Ik vind het ook heel irritant ja maar ben wel blij dat er tenminste een alternatief is, dat is 100x beter dan helemaal geen alternatief en steeds terug moeten naar de broncode editor.

Dat het ingewikkeld is had ik door, daarom ook dat ik aangaf "ondanks dat je aangeeft dat niet te gaan doen" en extra mee wou geven dat ik het vooral erg waardeer wat ze met de editor doen en snap dat ze keuzes moeten maken en dit een heel persoonlijke is en geen feitelijk beter of slechter. Ik bedoel het echt niet negatief, maar probeer meer te verwoorden waar ik tegenaan loop (en dat waar ik persoonlijk tegenaan loop niet op te lossen is zonder een default aan te passen, voor iedereen of als persoonlijke setting, en dat mijn feedback dus blijft staan). Verwoorden is niet altijd mijn sterkste punt, dus als het anders over komt, excuus.

[sus]

DaFeliX schreef op woensdag 4 februari 2026 @ 08:31:
Zoals ik al eerder aangaf (hier of in een .plan) dat het introduceren van extra complexiteit als een 'toggle' voor "enter=harde break/nieuwe paragraaf" onwenselijk is. Maar we begrijpen heus ook wel wel de frustratie die sommigen hiermee ervaren.

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.

Ik tag even wat mensen die deze feedback hadden gegeven in dit topic hier over: @CAPSLOCK2000 @Cambionn @sus @MazeWing @Paul @Sissors @Proton_ @Vliegvlug @Mog @Finraziel @beeldbuijs

Hopelijk helpt dit een beetje

Yes! Hele dikke dikke kudo’s!

[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