Wysiwyg-editor als bètafeature

[Vliegvlug]

crisp schreef op woensdag 28 januari 2026 @ 11:16:
[...]

Nee, dat heeft nooit zo gewerkt.

Ik schreef ook dat die tekst van @MazeWing de suggestie wekte dat het werkte, maar als dat nooit zo was heb ik geen idee wat hij bedoelde met steeds backspace moeten gebruiken om de automatische alinea weg te krijgen.

Je kan met Shift+enter een enkele newline maken (werkt ook op mobiel - iig met Gboard op Android)

Nooit geweten dat dat kon maar ik type dan ook altijd enkelhandig dus dat is alsnog geen oplossing voor mij, dan is switchen naar broncode modus voor mij de enige optie

[...]

Nee, dit is standaard gedrag van de wysiwyg-editor welke we niet gaan aanpassen.

Zoals ik al schreef was dat al overduidelijk gemaakt en daar vraag ik dan ook helemaal niet om (maar men mag altijd op een wonder hopen toch! )

Mijn vraag is of het zo gemaakt kan worden dat backspace enkel de nieuwe alinea witregel verwijdert en niet ook automatisch terug springt naar het einde van de vorige regel.
Zoals ik uitlegde is dat in mijn ogen een win-win want er verandert dan niets in het gedrag dat enter een nieuwe alinea maakt maar geeft mensen die maar één hand gebruiken (of misschien wel niet anders kunnen omdat ze een hand of ledemaat missen, waar accessibility voor mensen met een beperking ook om de hoek komt kijken), de mogelijkheid dit met het indrukken van één toest vrij eenvoudig weer ongedaan te maken.

Dus hopelijk kan dit echt overwogen worden en niet ter plekke gelijk worden afgeschoten.

[...]

Wat is er precies onbruikbaar hierdoor?

Zoals dit in jouw reacties bij eerdere discussie hierover is dat onder andere een smaak ding maar het heeft ook een funtioneel component.

Blijkbaar zijn er ook mensen, en ik weet dat het heel moeilijk voor te stellen is , die graag binnen een alinea een zin op een nieuwe regel beginnen.
Ik ben namelijk nogal geneigd om lange stukken tekst te typen en mijn posts zijn ongetwijfeld een stuk langer dat de gemiddelde post hier op Tweakers en dan vind ik het niet meer prettig lezen als er een doorlopende aaneenschakeling van zinnen is binnen een lange alinea. En ik vermoed dat dit voor veel mensen geldt.

Dus zelfs als je zelf bijna nooit lange alinea’s schrijft help ik daarmee ook de lezers die dus ook baad hebben bij een makkelijk manier dat ik wel een zin binnen een alinea op een nieuwe regel kan beginnen!

[Vliegvlug]

MazeWing schreef op woensdag 28 januari 2026 @ 11:52:
[...]

Het blijft toch apart dat een marktaandeel van 36-38% (VS iOS apparaten) zo eenvoudig aan de kant wordt geschoven.

Hoe je het ook wendt of keert: het is gewoon een zeer gebruiksonvriendelijke implementatie, zeker op iOS.

Oh, shift-enter werkt niet op iOS!
Ben nu echt heel blij dat ik geen iPhone heb maar een Android toestel, dan heb ik tenminste nog een halfgare fallback optie.

Helaas heb ik wel een iPad en net getest op iPadOS en ook daarop werkt shift+enter niet!
En laat ik, als ik thuis, ben nu net 99% van mijn posts op Tweakers daarop typen.
Ook weer eenhandig.

Hoewel het daar nog iets makkelijker zou zijn geweest om wel mijn andere hand erbij te pakken voor shift-enter.
Dat is goed waardeloos zeg, echt slecht dat Apple dat niet geimplemeteerd heeft.

Hoop dan ook echt dat de ”backspace na enter” om terug te komen op een nieuwe regel van de eerdere alinea geïmplementeerd kan worden in de wysiwyg-editor van Tweakers, want dat is dus echt broodnodig.
Niet alleen voor die paar zielen die enkel eenhandig willen of kunnen typen maar ook voor alle Apple gebruikers die er tegenaan lopen!

[crisp]

Vliegvlug schreef op woensdag 28 januari 2026 @ 11:58:
[...]

Mijn vraag is of het zo gemaakt kan worden dat backspace enkel de nieuwe alinea witregel verwijdert en niet ook automatisch terug springt naar het einde van de vorige regel.

Zijn er ueberhaupt paragraaf-based editors die dat doen?

Dit is niet iets wat we op dit moment zullen overwegen. Wellicht dat er dus nog wel een andere mogelijkheid komt om een expliciete linebreak in te voegen, maar niet via backspace vanuit een nieuwe paragraaf.

[Mog]

-Edit-
Verkeerd gelezen.

LinkedIn en volgens mij Reddit (heb geen account meer, kan niet checken) doen 1x enter = BR en 2x enter = P.

[ Voor 58% gewijzigd door Mog op 28-01-2026 12:41 ]

[MazeWing]

Mog schreef op woensdag 28 januari 2026 @ 12:40:
-Edit-
Verkeerd gelezen.

LinkedIn en volgens mij Reddit (heb geen account meer, kan niet checken) doen 1x enter = BR en 2x enter = P.

Zoals het hoort en al sinds jaar en dag gebruikelijk is, zeker op internet!

Het is gewoon onmogelijk om een BR te doen op een iOS device. Als je enter doet is het altijd een nieuwe paragraaf en druk je dan op backspace dan haalt ie de nieuwe paragraaf weg (incl. de witregel dus) en zit je weer in de vorige paragraaf. Het is zelfs onmogelijk om de witruimte te selecteren.

Dat dit ooit door de testfase heen is gekomen is onbegrijpelijk. Ik verzoek @crisp gewoon eens 1 bericht te typen met een iOS device en dan zijn ervaring te delen.

[crisp]

@MazeWing ik gebruik nagenoeg nooit shift+enter omdat het meestal gewoon niet nodig is.

Verder laat ik het hierbij; wellicht komt er nog een knopje of iets anders voor een expliciete linebreak, maar het standaard gedrag van de editor mbt een normale enter gaan we niet aanpassen.

[Finraziel]

MazeWing schreef op woensdag 28 januari 2026 @ 13:15:
[...]

Zoals het hoort en al sinds jaar en dag gebruikelijk is, zeker op internet!

Het is gewoon onmogelijk om een BR te doen op een iOS device. Als je enter doet is het altijd een nieuwe paragraaf en druk je dan op backspace dan haalt ie de nieuwe paragraaf weg (incl. de witregel dus) en zit je weer in de vorige paragraaf. Het is zelfs onmogelijk om de witruimte te selecteren.

Dat dit ooit door de testfase heen is gekomen is onbegrijpelijk. Ik verzoek @crisp gewoon eens 1 bericht te typen met een iOS device en dan zijn ervaring te delen.

Ik heb het idee dat je voornamelijk mist dat veel mensen het helemaal niet belangrijk vinden om een enter te kunnen geven in dezelfde paragraaf... Ik vind dat persoonlijk ook niet echt mooi uitzien of prettiger lezen of zo. Het is dus geen kwestie van niet getest hebben maar gewoon niet zoveel waarde hechten aan wat jij blijkbaar een halszaak vindt.

Overigens doet Reddit het volgens mij juist nog slechter. 1 enter lijkt inderdaad een volgende regel zonder nieuwe paragraaf, maar zodra je post stript hij die enters weer weg en staat alles gewoon achter elkaar. Ik moet er daar juist altijd aan denken om twee enters te geven wat ik helemaal niet intuïtief vind.

[Vliegvlug]

crisp schreef op woensdag 28 januari 2026 @ 12:33:
[...]

Zijn er überhaupt paragraaf-based editors die dat doen?

Ik zie niet in waarom dat relevant is, of willen jullie de code van die betreffende editor dan gebruiken?

Of is er een richtlijn binnen Tweakers dat het alleen mag worden geïmplementeerd als het al ergens bestaat?
In dat geval wil ik graag mijn best doen om ergens een obscure editor te vinden waar dit wel zo werkt!

Dit is niet iets wat we op dit moment zullen overwegen.

Kan je dan uitleggen waarom niet?
Ik ben geen programmeur maar is dit iets wat heel moeilijk te implementeren is voor jullie?

Want aangezien het verder niets verandert aan de “enter is nieuwe alinea”-functionaliteit kan dat toch geen reden zijn om het niet te doen. Op die manier blijft het voor liefhebbers daarvan onveranderd en voor de niet-liefhebbers kan er tenminste met minimale inspanning omheen gewerkt worden.

Want momenteel is er voor enkelhandig gebruik van de visuele editor geen enkel manier om een zin binnen een alinea op een nieuwe regel te krijgen, nada noppes!
En op Apple devices zelfs met twee handen niet!

Lijkt met deze halsstarrige weigering en het on-the-spot afschieten van functionaliteit die dit oplost zonder enige overweging wel een bewuste actie om mensen hiermee dwars te zitten of op zijn minst totaal niet serieus te nemen.

Wellicht dat er dus nog wel een andere mogelijkheid komt om een expliciete linebreak in te voegen, maar niet via backspace vanuit een nieuwe paragraaf.

Het hoeft van mij ook niet per se op die manier maar wel op een manier waarvoor er geen dubbelhandige actie nodig is bij Android gebruikers en om het überhaupt mogelijk te maken op Apple devices.

Dus als jullie iets anders kunnen verzinnen waardoor het wel makkelijker te implementeren is, ik ga er nu maar even vanuit omdat de backspace methode categorisch geweigerd wordt deze te lastig is, dan is dat ook een optie.

En ”wellicht” klinkt me nog heel erg onzeker in de oren. Wat is hier concreet de kans van dat hier naar gekeken wordt en op welke termijn?

[MazeWing]

Typ een bericht een WhatsApp, in een notitieprogramma, Facebook, etc. En je zult zien dat het praktisch overal hetzelfde is: enter = een nieuwe regel en geen paragraaf.

De enige uitzondering is Word.

En als je het nu in alle gevallen kon ondervangen door shift+enter te doen dan was het tot daar aan toe. Maar 36-38% van de gebruikers uitsluiten en gewoon te zeggen: “het blijft zo en daarmee klaar” is zeer ongebruiksvriendelijk en ronduit kortzichtig.

[Vliegvlug]

Finraziel schreef op woensdag 28 januari 2026 @ 13:20:
[...]

Ik heb het idee dat je voornamelijk mist dat veel mensen het helemaal niet belangrijk vinden om een enter te kunnen geven in dezelfde paragraaf... Ik vind dat persoonlijk ook niet echt mooi uitzien of prettiger lezen of zo. Het is dus geen kwestie van niet getest hebben maar gewoon niet zoveel waarde hechten aan wat jij blijkbaar een halszaak vindt.

Dit is natuurlijk een kul argument, dus omdat de meerderheid het niet gebruikt noch belangrijk vindt kunnen we de wens van de minderheid gevoegelijk compleet negeren, juist ja.

Heb je nu ook door hoe stom dat klinkt?
Gelukkig werkt dit niet zo in onze samenleving.

[Mog]

MazeWing schreef op woensdag 28 januari 2026 @ 13:15:
[...]

Zoals het hoort en al sinds jaar en dag gebruikelijk is, zeker op internet!

Ik weet niet of er een standaard is hoor. Er zijn veel WYSIWYG editors die een P geven na een enter. Testje:

P na Enter:

• Word
• Medium
• Notion
• Jira
• TinyMCE (editor)
• Summernote (editor)
• Froala (editor)
• CKEditor (editor)
• ProseMirror (editor)
• ContentTools (editor)
• Redactor (editor)

BR na Enter:

• Google Docs
• Pages
• LinkedIn
• Gmail
• Quill (Editor)
• Trix (Editor)

[ Voor 23% gewijzigd door Mog op 28-01-2026 13:35 ]

[Vliegvlug]

Mog schreef op woensdag 28 januari 2026 @ 13:27:
[...]

Ik weet niet of er een standaard is hoor. Er zijn veel WYSIWYG editors die een P geven na een enter. Testje:

P na Enter:

• Word
• Medium

BR na Enter:

• Google Docs
• Pages
• LinkedIn
• Gmail

Ik zie jouw post meer als een voorbeeld dat een nieuwe regel na enter helemaal niet zo gek is als dat hier wordt voorgespiegeld door Tweakers!

[Mog]

Vliegvlug schreef op woensdag 28 januari 2026 @ 13:32:
[...]

Ik zie jouw post meer als een voorbeeld dat een nieuwe regel na enter helemaal niet zo gek is als dat hier wordt voorgespiegeld door Tweakers!

Te snel op verzenden gedrukt

[crisp]

Vliegvlug schreef op woensdag 28 januari 2026 @ 13:22:
[...]

Ik zie niet in waarom dat relevant is, of willen jullie de code van die betreffende editor dan gebruiken?

Of is er een richtlijn binnen Tweakers dat het alleen mag worden geïmplementeerd als het al ergens bestaat?
In dat geval wil ik graag mijn best doen om ergens een obscure editor te vinden waar dit wel zo werkt!

Nog heel kort hierover dan: wij gebruiken een 3rd-party editor (TipTap bovenop ProseMirror) en deze heeft nu eenmaal bepaald 'gedrag'. Dit aanpassen is technisch erg lastig of vergt zelfs aanpassingen aan de inner workings van dit externe product (wat wij zelf dus niet kunnen aanpassen, hooguit vragen of ze een pullrequest daarvoor accepteren waarvan ik de kans klein acht).

Zoals @Mog hierboven al aangeeft zijn er 2 verschillende "smaken" wat betreft entergedrag in online editors, en onze editor (ProseMirror dus) werkt nu eenmaal met paragrafen. Wij hebben voor deze editor en dit gedrag gekozen, en daarmee is voor ons (en na een jaar aan dit project gewerkt te hebben) deze discussie ook wel klaar. We gaan hier niet meer op terugkomen.

[Vliegvlug]

crisp schreef op woensdag 28 januari 2026 @ 13:18:

Verder laat ik het hierbij; wellicht komt er nog een knopje of iets anders voor een expliciete linebreak, maar het standaard gedrag van de editor mbt een normale enter gaan we niet aanpassen.

Hopelijk bedoel je hier enkel reageren op @MazeWing mee want ik zou het erg waarderen als je nog op de vragen in mijn eerdere post in kan gaan: Vliegvlug in "Wysiwyg-editor als bètafeature".
Bedankt alvast!

Een <br> knopje in de editor zou niet mijn voorkeur hebben, veel liever zie ik iets wat via het toetsenbord kan maar het is sowieso al 100 keer beter dan niets!

[Finraziel]

Vliegvlug schreef op woensdag 28 januari 2026 @ 13:27:
[...]

Dit is natuurlijk een kul argument, dus omdat de meerderheid het niet gebruikt noch belangrijk vindt kunnen we de wens van de minderheid gevoegelijk compleet negeren, juist ja.

Heb je nu ook door hoe stom dat klinkt?
Gelukkig werkt dit niet zo in onze samenleving.

Dat is anders vrij normaal in software development... Een functionaliteit waar maar een paar mensen op zitten te wachten ga je niet heel veel resources in stoppen. En het is nou ook niet alsof je helemaal niet meer kunt posten he? Je doet net alsof je leven eindigt als je geen BR zonder nieuwe paragraaf kunt geven...

[crisp]

Vliegvlug schreef op woensdag 28 januari 2026 @ 13:37:
[...]

Hopelijk bedoel je hier enkel reageren op @MazeWing mee want ik zou het erg waarderen als je nog op de vragen in mijn eerdere post in kan gaan: Vliegvlug in "Wysiwyg-editor als bètafeature".
Bedankt alvast!

Een <br> knopje in de editor zou niet mijn voorkeur hebben, veel liever zie ik iets wat via het toetsenbord kan maar het is sowieso al 100 keer beter dan niets!

Je bedoelt deze vraag nog denk ik?

En ”wellicht” klinkt me nog heel erg onzeker in de oren. Wat is hier concreet de kans van dat hier naar gekeken wordt en op welke termijn?

We gaan sowieso onderzoeken hoe we support voor [br] in UBB/RML kunnen "vertalen" naar de wysiwyg-editor. Daar is een ticket voor die we eerdaags gaan oppakken. Ik kan verder niet vooruitlopen op het resultaat daarvan.

[Vliegvlug]

crisp schreef op woensdag 28 januari 2026 @ 13:37:
[...]

Nog heel kort hierover dan: wij gebruiken een 3rd-party editor (TipTap bovenop ProseMirror) en deze heeft nu eenmaal bepaald 'gedrag'. Dit aanpassen is technisch erg lastig of vergt zelfs aanpassingen aan de inner workings van dit externe product (wat wij zelf dus niet kunnen aanpassen, hooguit vragen of ze een pullrequest daarvoor accepteren waarvan ik de kans klein acht).

Zoals @Mog hierboven al aangeeft zijn er 2 verschillende "smaken" wat betreft entergedrag in online editors, en onze editor (ProseMirror dus) werkt nu eenmaal met paragrafen. Wij hebben voor deze editor en dit gedrag gekozen, en daarmee is voor ons (en na een jaar aan dit project gewerkt te hebben) deze discussie ook wel klaar. We gaan hier niet meer op terugkomen.

Hartelijk dank voor de jouw reactie op het eerste deel van mijn post
Maar daar ging het nu net niet om, zie ook de clown smiley.

Dat het gedrag van de Enter niet gaat veranderen is duidelijk en heb ik nu al twee keer aangegeven dus hoef je echt niet nog een keer te zeggen.

Maar hoe zit het met de alternatieven om om dit gedrag heen te kunnen werken?
De rest van mijn eerdere post dus.

[Mog]

Finraziel schreef op woensdag 28 januari 2026 @ 13:38:
[...]

Dat is anders vrij normaal in software development... Een functionaliteit waar maar een paar mensen op zitten te wachten ga je niet heel veel resources in stoppen. En het is nou ook niet alsof je helemaal niet meer kunt posten he? Je doet net alsof je leven eindigt als je geen BR zonder nieuwe paragraaf kunt geven...

Jep. En je kan gewoon switchen naar 'broncode'. Die editor heeft mijn persoonlijke voorkeur. I love me some UBB tags.

[Vliegvlug]

crisp schreef op woensdag 28 januari 2026 @ 13:42:
[...]

We gaan sowieso onderzoeken hoe we support voor [br] in UBB/RML kunnen "vertalen" naar de wysiwyg-editor. Daar is een ticket voor die we eerdaags gaan oppakken. Ik kan verder niet vooruitlopen op het resultaat daarvan.

Ik zie nu pas je reactie, dank!

Hij alleen wel erg kort.
Als ik het goed begrijp was jouw eerdere tekst “Wellicht dat er dus nog wel een andere mogelijkheid komt om een expliciete linebreak in te voegen, maar niet via backspace vanuit een nieuwe paragraaf.” dus eigenlijk iets te rooskleurig.
En wordt er nu enkel gekeken naar het implementeren van een <br>-knopje maar wordt er verder niet naar andere mogelijkheden gekeken?

Of is het juist nu eerst het <br>-knopje implementeren en later nog kijken of er iets via het toetsenbord kan worden geïmplementeerd?


Ik hoop natuurlijk van harte het laatste!

[F_J_K]

Ik heb de betatest een tijd gedaan, mistte wat dingen maar de enter = alinea, daar werd ik juist heel blij van. ... Na de wen-periode natuurlijk, zoals vele hier is mijn eerste reactie bij any verandering een allergische reactie :P

Voor gewone teksten is 1 enter enorm storend. Dat leest, voor deze site grote uitzonderingen zoals een postadres daargelaten, voor geen meter. Alleen zinvol bij opsommingen en daar doet de wysiwyg het prima.

[Vliegvlug]

Mog schreef op woensdag 28 januari 2026 @ 13:35:
[...]

Te snel op verzenden gedrukt

Het is voor mij nadat je je post verder heb aangevuld eigenlijk niet anders geworden hoor, genoeg applicaties die wel enter is break implementeren, dus vind dat nog steeds geen sterk argument om het hier op Tweakers dan per se enter is nieuwe alinea te doen.

Deze uitleg van @crisp snijdt wat dat betreft meer hout crisp in "Wysiwyg-editor als bètafeature" en zie ik als goede reden om dat basis gedrag niet compleet om te gooien.

Laat onverlet dat er naar mijn menig nog wel een alternatief geboden zou moeten worden om hier op een of andere manier om heen te kunnen werken, zeker voor mensen die nu helemaal geen andere optie hebben.

[Vliegvlug]

Finraziel schreef op woensdag 28 januari 2026 @ 13:38:
[...]

Dat is anders vrij normaal in software development... Een functionaliteit waar maar een paar mensen op zitten te wachten ga je niet heel veel resources in stoppen. En het is nou ook niet alsof je helemaal niet meer kunt posten he? Je doet net alsof je leven eindigt als je geen BR zonder nieuwe paragraaf kunt geven...

Je kan alles natuurlijk in het belachelijke trekken en daarmee de discussie plat slaan en je gaat er verder gelijk vanuit dat een oplossing heel veel resources gaat kosten.

Ik snap ook wel dat er een afweging moet zijn tussen inspanningen en aantal gebruikers en daarom vraag ik ook juist of het heel lastig is om een alternatief te implementeren maar daar is nog geen duidelijkheid over gekomen.

[Finraziel]

Vliegvlug schreef op woensdag 28 januari 2026 @ 14:07:
[...]

Je kan alles natuurlijk in het belachelijke trekken en daarmee de discussie plat slaan en je gaat er verder gelijk vanuit dat een oplossing heel veel resources gaat kosten.

Ik snap ook wel dat er een afweging moet zijn tussen inspanningen en aantal gebruikers en daarom vraag ik ook juist of het heel lastig is om een alternatief te implementeren maar daar is nog geen duidelijkheid over gekomen.

Volgens mij trek ik het niet in het belachelijke?
En volgens mij heb ik Crisp al meermaals zien zeggen dat het erg lastig is om dit aan te passen in de editor die ze gebruiken.

[Vliegvlug]

F_J_K schreef op woensdag 28 januari 2026 @ 14:00:
Ik heb de betatest een tijd gedaan, mistte wat dingen maar de enter = alinea, daar werd ik juist heel blij van. ... Na de wen-periode natuurlijk, zoals vele hier is mijn eerste reactie bij any verandering een allergische reactie :P

Fijn dat het voor jou wel positief uitpakt en dat elke verandering wennen is heb je gelijk in maar ik kan je in dit geval vertellen dat ik echt weet dat ik hier niet aan ga wennen.
Al zolang dat ik Microsoft Word gebruik heb ik er al een hartgrondige hekel aan.
Ben blij dat ik daar tegenwoordig nog maar heel weinig mee hoef te werken

Voor gewone teksten is 1 enter enorm storend. Dat leest, voor deze site grote uitzonderingen zoals een postadres daargelaten, voor geen meter. Alleen zinvol bij opsommingen en daar doet de wysiwyg het prima.

Dat is dus subjectief.
Ik vind hele grote blokken tekst van aaneengesloten regels juist totaal niet fijn lezen!

[crisp]

Vliegvlug schreef op woensdag 28 januari 2026 @ 13:53:
[...]

Ik zie nu pas je reactie, dank!

Hij alleen wel erg kort.
Als ik het goed begrijp was jouw eerdere tekst “Wellicht dat er dus nog wel een andere mogelijkheid komt om een expliciete linebreak in te voegen, maar niet via backspace vanuit een nieuwe paragraaf.” dus eigenlijk iets te rooskleurig.
En wordt er nu enkel gekeken naar het implementeren van een <br>-knopje maar wordt er verder niet naar andere mogelijkheden gekeken?

Of is het juist nu eerst het <br>-knopje implementeren en later nog kijken of er iets via het toetsenbord kan worden geïmplementeerd?


Ik hoop natuurlijk van harte het laatste!

Ik kan en ga niet voortuitlopen op een researchticket dat nog niet gedaan is

[Vliegvlug]

Finraziel schreef op woensdag 28 januari 2026 @ 14:09:
[...]

Volgens mij trek ik het niet in het belachelijke?

Ik doel hier op:
”Je doet net alsof je leven eindigt als je geen BR zonder nieuwe paragraaf kunt geven...”

En volgens mij heb ik Crisp al meermaals zien zeggen dat het erg lastig is om dit aan te passen in de editor die ze gebruiken.

Je leest niet goed of je wilt het bewust niet goed begrijpen.
De enter = alinea zit standaard in het basis product wat ze afnemen en daarvan enter = line break maken is heel erg lastig.

Maar dat is dus niet waar ik het over heb, het gaat mij om een alternatief om die alinea toch te kunnen weghalen na een enter en een zin op nieuwe regel te krijgen binnen een alinea.

Dat is nu in de visuele editor met één hand onmogelijk te doen maar mensen op Android hebben nog shift-enter met gebruik van twee handen als alternatief, maar op Apple devices kan je zelfs met twee handen dit niet voor elkaar krijgen. Daar is het nu dus totaal onmogelijk.

[Vliegvlug]

crisp schreef op woensdag 28 januari 2026 @ 14:20:
[...]

Ik kan en ga niet voortuitlopen op een researchticket dat nog niet gedaan is

Oké fair, dan houd ik voorlopig nog hoop en ga ik van het positieve scenario uit!
Belooft me dat je ons hier op de hoogte houdt van de uitkomst van dat researchticket!

[Vliegvlug]

Mog schreef op woensdag 28 januari 2026 @ 13:43:
[...]

Jep. En je kan gewoon switchen naar 'broncode'.

Dat is wat ik nu doe inderdaad en op mijn iPad ook de enige manier om een zin binnen een alinea op een nieuwe regel te krijgen.

Die editor heeft mijn persoonlijke voorkeur. I love me some UBB tags.

Ik ben de huidige editor ook al helemaal gewend maar ik zie wel veel voordeel in een visuele editor, veel dingen buiten de basis zijn daarin best omslachtig.
Dingen als tabellen zijn daarin echt niet te doenen gebruik ik daarom ook haast nooit. Ik heb nog niet gekeken hoe dat in de visuele editor gaat maar daarin heb je tenminste de mogelijkheid om het in een werkbaarder manier aan te bieden.
Dat geldt in mindere mate ook voor lijstjes.

En ik zag een undo-knop in de visuele editor, dat is ook super handig!
Dus ik ben wel voorstander van een visuele boven een broncode editor maar er moet wel altijd een mogelijkheid blijven bestaan naar die laatste te kunnen wisselen.

Ik zie in de toekomst de meeste ontwikkelingen en verbeteringen echter wel in de visuele gedaan gaan worden, dat zal toch de voorkeurseditor worden van de meeste Tweakers is mijn verwachting.

[MazeWing]

crisp schreef op woensdag 28 januari 2026 @ 13:37:
[...]

Nog heel kort hierover dan: wij gebruiken een 3rd-party editor (TipTap bovenop ProseMirror) en deze heeft nu eenmaal bepaald 'gedrag'. Dit aanpassen is technisch erg lastig of vergt zelfs aanpassingen aan de inner workings van dit externe product (wat wij zelf dus niet kunnen aanpassen, hooguit vragen of ze een pullrequest daarvoor accepteren waarvan ik de kans klein acht).

Zoals @Mog hierboven al aangeeft zijn er 2 verschillende "smaken" wat betreft entergedrag in online editors, en onze editor (ProseMirror dus) werkt nu eenmaal met paragrafen. Wij hebben voor deze editor en dit gedrag gekozen, en daarmee is voor ons (en na een jaar aan dit project gewerkt te hebben) deze discussie ook wel klaar. We gaan hier niet meer op terugkomen.

Change enter to break line instead of new paragraph

code:

HardBreak.extend({
    addKeyboardShortcuts() {
        return {
            Enter: () => {
                if (this.editor.isActive('orderedList') || this.editor.isActive('bulletList')) {
                    return this.editor.chain().createParagraphNear().run();
                }
                return this.editor.commands.setHardBreak();
            },
        };
    },
}),

Hardbreak extension: https://tiptap.dev/docs/editor/extensions/nodes/hard-break
Faq mbt newline: https://tiptap.dev/docs/guides/faq

Of is dit weer te simpel gedacht?

[ Voor 21% gewijzigd door MazeWing op 28-01-2026 14:55 ]

[Mog]

Vliegvlug schreef op woensdag 28 januari 2026 @ 14:01:
[...]

Het is voor mij nadat je je post verder heb aangevuld eigenlijk niet anders geworden hoor, genoeg applicaties die wel enter is break implementeren, dus vind dat nog steeds geen sterk argument om het hier op Tweakers dan per se enter is nieuwe alinea te doen.

Het is ook niet bedoeld als argument. Ik wilde alleen aantonen dat er niet 1 web standaard is. De een doet het zus de ander zo.

[crisp]

Toppe schreef op dinsdag 27 januari 2026 @ 16:37:
Is er ook een vriendelijke manier om in de editor de code taal te zien??


@crisp deze toevallig nog gezien?

Bijvoorbeeld:
Code: YAML
Code: PHP

Nu lijkt het alsof je geen tags hebt gebruikt

edit:
Blijkbaar kan dit wel maar je ziet dit niet als resultaat in de editor:

YAML:

[Afbeelding][Afbeelding]

Ja, daar hebben we al een ticket voor 🙂

[beeldbuijs]

Na het inschakelen van de wysiwyg-editor beta en wat uitproberen op verschillende apparaten, begrijp ik nu beter wat er bedoeld wordt. Ik vermoed dat het standaardiseren in van een return als nieuwe alinea voortkomt uit het feit dat in wysiwyg html editors, zover ik ze meegemaakt heb, een <p> de norm is, niet <br>.

• Op de Mac / macOS werkt [shift ⏎] / shift return alsnog gewoon als return in plaats van nieuwe alinea.
• Op iPhone / iOS en iPadOS niet, maar door de broncode-stand te gebruiken kun je alsnog een gewone return cq newline cq <br(eak)> typen, in plaats van een return die als <p(aragraph)> cq nieuwe alinea uitpakt. Dus een newline blijft wel binnen handbereik, ook op iPhone en iPad. In Safari en Brave dan, ik heb niet alle browsers geprobeerd.

Ik begrijp wel dat een deel van de gebruikers shift-return er in wil hebben, ik wil dat ook wel, maar ik begrijp ook dat Crisp / tweakers niet een eigen branch van TipTap willen maken hiervoor.

Overigens geeft Google AI-modus deze reactie op 'is TipTap shift-return' gek genoeg aan dat het 'gedrag' van shift-return standaard een <br> geeft (wat dus niet overeenkomt met de ervaring in iOS / iPadOS), maar ook dat het in te stellen is:

In Tiptap, pressing Shift+Enter (or Shift+Return) typically inserts a "hard break" (<br>) rather than a new paragraph, allowing for a line break without separating list items or creating extra spacing. This behavior is managed by the {Link: HardBreak extension https://tiptap.dev/docs/editor/extensions/nodes/hard-break}. 

Key Details regarding Shift-Return in Tiptap: 

• Default Behavior: Shift+Enter creates a <br> tag.
• Alternative Configuration: To make Shift+Enter create a new paragraph (<p>) instead of a break, you can customize keyboard shortcuts in the configuration to use this.editor.commands.createParagraphNear() or setHardBreak.
• Code Blocks: Within code blocks, Shift+Enter (newlineInCode) inserts a new line character.
• Functionality: It acts as a "soft return" to keep content within the same block element.

javascript

code:

// Example: Customizing to make Shift-Enter behave like Enter (new paragraph)
import { Extension } from '@tiptap/core'

const ShiftEnterCreateExtension = Extension.create({
  addKeyboardShortcuts() {
    return {
      "Shift-Enter": ({ editor [nosmilies]})[/nosmilies] => {
        return editor.commands.enter(); // Instead of hard_break
      },
    };
  },
});

[Toppe]

Ik weet niet of dit al gemeld is, maar in tik altijd de smilies op m’n mobiel… de meest voorkomende weet ik wel.

Alleen maakt hij er nu automatisch een nosmilie tag er van. Is dat bewust? Ik zou dit namelijk erg graag willen (kunnen) uitschakelen.

[crisp]

Toppe schreef op vrijdag 30 januari 2026 @ 07:34:
Ik weet niet of dit al gemeld is, maar in tik altijd de smilies op m’n mobiel… de meest voorkomende weet ik wel.

Alleen maakt hij er nu automatisch een nosmilie tag er van. Is dat bewust? Ik zou dit namelijk erg graag willen (kunnen) uitschakelen.

In de wysiwyg-modus moet je na een smileycode een spatie of enter typen om hem te 'activeren'. Als je in wysiwyg geen smiley ziet, dan wordt er ook geen smiley gepost.

[F_J_K]

Of ander leesteken , zoals de komma of .

[F_J_K]

offtopic:
*knip* Of ik ben dom en had de toggle verkeerd staan op de telefoon Werkt daar ook prima.

[ Voor 95% gewijzigd door F_J_K op 30-01-2026 08:51 ]

[Toppe]

crisp schreef op vrijdag 30 januari 2026 @ 08:39:
[...]

In de wysiwyg-modus moet je na een smileycode een spatie of enter typen om hem te 'activeren'. Als je in wysiwyg geen smiley ziet, dan wordt er ook geen smiley gepost.

Edit, hij stond op Broncode

Lekker opgelet

[ Voor 24% gewijzigd door Toppe op 30-01-2026 12:44 ]

[Webgnome]

crisp schreef op vrijdag 30 januari 2026 @ 08:39:
[...]

In de wysiwyg-modus moet je na een smileycode een spatie of enter typen om hem te 'activeren'. Als je in wysiwyg geen smiley ziet, dan wordt er ook geen smiley gepost.

Gaat dit nog worden opgepakt? Ik loop nu op het forum hier vaak tegen aan dat ik op vestuur klik en dat de smily dus nog niet omgezet is naar een afbeelding. Dat zou toch snel opgelost kunnen worden lijkt mij

[crisp]

Webgnome schreef op zaterdag 31 januari 2026 @ 13:45:
[...]

Gaat dit nog worden opgepakt? Ik loop nu op het forum hier vaak tegen aan dat ik op vestuur klik en dat de smily dus nog niet omgezet is naar een afbeelding. Dat zou toch snel opgelost kunnen worden lijkt mij

Het is feitelijk by design, maar ik zit ondertussen wel te overwegen om een uitzondering te maken voor een smileycode aan het eind van een post...

[Meg]

Webgnome schreef op zaterdag 31 januari 2026 @ 13:45:
[...]

Gaat dit nog worden opgepakt? Ik loop nu op het forum hier vaak tegen aan dat ik op vestuur klik en dat de smily dus nog niet omgezet is naar een afbeelding. Dat zou toch snel opgelost kunnen worden lijkt mij

Ik mag hopen dat je snapt dat de developers ook weekend willen houden. Verwacht op zijn minst dat je tot maandag geen oplossing hebt.

@crisp ga eerst lekker genieten van het weekend, jullie werken hard genoeg voor Tweakers.

[Webgnome]

Meg schreef op zaterdag 31 januari 2026 @ 14:01:
[...]

Ik mag hopen dat je snapt dat de developers ook weekend willen houden. Verwacht op zijn minst dat je tot maandag geen oplossing hebt.

@crisp ga eerst lekker genieten van het weekend, jullie werken hard genoeg voor Tweakers.

Ik had niet de intentie dat wanneer ik nu iets hier plaats het over een uur is opgelost hoor. Dat zou ik ook niet doen tenzij er ergens bloed of rook uit komt.

@crisp take your time. Zou mooi zijn om zoals je zelf zegt bij het einde van een reactie die smilies te resolven. Dat scheelt een edit

[Meg]

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.

[crisp]

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.

We werken aan een extra alternatief voor shift+enter (o.a. voor mobiele devices).

[Meg]

crisp schreef op zaterdag 31 januari 2026 @ 18:14:
[...]

We werken aan een extra alternatief voor shift+enter (o.a. voor mobiele devices).

Ah super! Ik zie wel dat er steeds. meer nieuwe opties komen zoals [green]kleurtjes! Tof![/green]

[crisp]

Meg schreef op zaterdag 31 januari 2026 @ 18:41:
[...]

Ah super! Ik zie wel dat er steeds. meer nieuwe opties komen zoals [green]kleurtjes! Tof![/green]

En zo te zien gaat dat nog niet helemaal goed

[Meg]

crisp schreef op zaterdag 31 januari 2026 @ 18:46:
[...]

En zo te zien gaat dat nog niet helemaal goed

Kan dat komen doordat vaste opmaak geen opmaak accepteert?

[crisp]

Meg schreef op zaterdag 31 januari 2026 @ 18:47:
[...]

Kan dat komen doordat vaste opmaak geen opmaak accepteert?

In RML inderdaad niet, maar ik denk dat de instellingen in de wysiwyg-editor niet overeenkomen.

[Meg]

* Meg snapt niets meer van wat meneer dev zegt.

Komen er trouwens ook andere kleuren?

[crisp]

Meg schreef op zaterdag 31 januari 2026 @ 19:00:
* Meg snapt niets meer van wat meneer dev zegt.

Komen er trouwens ook andere kleuren?

Daar zijn geen plannen voor, en daarnaast is het gebruik van vaste kleuren ook problematisch mbt darkmode. Binnen tabellen kan je wel elke kleur gebruiken, maar daar kan je dan dan ook de achtergrond op aanpassen.

[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.