Wysiwyg-editor nu ook live op het forum

[Vliegvlug]

Ik heb gisteren de wysiwyg beta editor optie geactiveerd maar erger me nu al groen en geel aan de "enter is nieuwe alinea"-optie!

Ik lees dat @MazeWing hier ook bepaald geen voorstander van is en dat hier meermaals kenbaar heeft gemaakt maar dat daar helaas eigenlijk niet naar geluisterd wordt.

Hier schrijft MazeWing in "Wysiwyg-editor als bètafeature" iets wat ik als work-around las om die nieuwe alinea witregel weg te krijgen:
"Iedere keer dat men op enter drukt komt er een nieuwe alinea en mag men op backspace drukken."

Wat suggereerde dat een backspace indrukken die witregel zou weghalen zodat je nog relatief eenvoudig binnen een alinea op een nieuwe regel zou kunnen beginnen.
Maar helaas werkt dat bij mij in visuele modus niet.
De hele tekst komt dan weer strak achter de laatste zin van de alinea er boven.

Is er in de tussentijd iets aangepast waardoor backspace niet meer werkt om die witregel weg te krijgen?

Kan dit alsjeblieft worden teruggedraaid, Please!

Want zo is die wysiwyg editor voor mij totaal onbruikbaar.
Ik moet dan naar broncode modus om die witregel weg te halen en dan heb ik dus helemaal niets aan die wysiwyg editor en kan ik net zo goed op de oude vertrouwde RML editor blijven zitten.

Dus mijn vurige verzoek is om op zijn minst de "backspace is alinea witregel weghalen maar wel op een nieuwe regel in de huidige alinea komen" functionaliteit te bieden.

Dan verandert er voor de "enter is nieuwe alinea"-fans niets, want waarom zouden die na een enter opeens op backspace drukken, maar zijn de haters van deze feature tenminste enigszins geholpen om de wysiwyg editor bruikbaar te maken want hij biedt ook veel gemak en voordelen heb ik gemerkt.

Pretty please! 🥺

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

[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

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

[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

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

[Vliegvlug]

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

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

Stap 1.
Ik selecteer de woorden:



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



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

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

code:

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

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

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

code:

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

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

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

[Vliegvlug]

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

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

Oh, serieus!? Dat is fijn!

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

[Vliegvlug]

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

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

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

[Vliegvlug]

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

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

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

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

[Vliegvlug]

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

Haha, die is huisvlijt

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

[Vliegvlug]

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

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

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

[Vliegvlug]

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

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

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

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

[Vliegvlug]

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

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

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

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

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

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

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

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

[Vliegvlug]

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

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

Fijn dat het iets breder gaat worden.

Maar hoe kan ik het editorveld vergroten?

Ik zie er geen mogelijkheid voor namelijk:



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

[Vliegvlug]

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

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

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

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

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

edit: Switchen naar broncode lijkt de oplossing.

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

[Vliegvlug]

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

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

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

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

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

[Vliegvlug]

Ik heb het volgende waar ik tegenaan loop met de visuele editor, neem de onderstaande regel:
Dit is een tekst met opmaak, cursief eerst, dan vet.

Vervolgens bovenstaande regel kopiëren en plakken:
Dit is een tekst met opmaak, cursief eerst, dan vet.

Dan wordt de cursieve en vette opmaak dus niet meegenomen terwijl ik dat wel had verwacht.

Terwijl als ik dingen van internetpagina’s kopieer de opmaak wel wordt meegenomen, vaak zelfs terwijl ik dat liever niet zou willen.

Ik gebruik Firefox als browser op een iPad, mocht dat relevant zijn.

[Vliegvlug]

@Hero of Time dank voor het testen.

Ik heb jouw tekst gekopieerd en geplakt en dat komt het wel over met opmaak.
Maar ook iets zelf met opmaak typen en kopiëren binnen de editor lukt nu opeens wel met behoud van opmaak.

Snap er werkelijk niets van, gisteren lukte het ook niet net als eerder vanavond en nu opeens wel.

[Vliegvlug]

sus schreef op zondag 24 mei 2026 @ 09:34:
[...]

Kan het kloppen dat dit niet meer werkt? Als ik op mijn iPhone met Chrome op enter druk krijg ik weer de irritante witregel (nieuwe alinea), die was toch juist gefikst?

Enkel een enter is altijd nieuwe alinea geweest.
Bij mij op de iPad met Firefox werkt de dubbele spatie + enter nog wel voor naar nieuw regel gaan mocht je dat bedoelen.

Verder is het nog steeds storend dat echt overal * * gebruikt wordt voor vet, maar hier cursief - wat juist overal weer met _ _ gedaan wordt. Die manier van opmaak gebruikte ik al in mijn vroege IRC-tijden en kom ik in echt al mijn andere apps of websites zo tegen. Alleen hier op Tweakers gaat het “mis”.

Eens, dat vind ik ook veel logischer en is ook waar ik aan gewend ben.

[Vliegvlug]

DaFeliX schreef op dinsdag 26 mei 2026 @ 07:40:
[...]

Ik weet niet wat je met "dit" bedoelt, maar {enter}, {shift+enter} en {spatie}{spatie}{enter} werkt nu nog steeds zoals het hoort.


[...]

Voor de markdownnotatie moesten we keuzes maken. Het probleem is dat er geen 'echte' standaard is, dus hebben we vooral gekeken hoe het bij verschillende andere platformen/websites/applicaties werkt. En daar viel me de inconsistentie op. "Overal" is dus zeker niet waar, maar ik weet dat er genoeg plekken zijn waar het weer anders gaat.

Wij hebben daarom vooral gekeken naar wat er is aan standaarden, en wat er in het wild gebruikt wordt. Daarop hebben we onze eigen keuzes gemaakt en bij twijfel vooral gekeken naar standaarden.

Je hebt vast gelijk dat het niet overal hetzelfde is en dat doet me gelijk denken aan XKCD on standards.

Hetgeen jij linkt geeft nota bene ook twee opties

Type	Or	… to Get
*Italic*	_Italic_	Italic
**Bold**	__Bold__	Bold

Waarbij italic dus ook met underscore ervoor en na kan, dus zij hebben ook niet één standaard.

Denk dat het in deze vooral belangrijk is te kijken naar de doelgroep die het gebruikt, dat zijn op Tweaker/GoT voor het overgrootte deel Nederlandstaligen (Nederland/Vlaanderen) en begrijp dat er ook flink wordt ingezet om nieuwe aanwas te trekken.

Zelf hebt ik deze markdown ‘geleerd’ van Whatsapp. * voor vet en _ voor cursief en ik verwacht dat het om die reden veruit het meest bekend is in Nederland (en misschien ook Vlaanderen maar dat weet ik niet). Mijn pubers kennen bijvoorbeeld ook niet anders.

Verder kom ik zelf deze ‘standaard’ ook overwegend tegen, waarbij Confluence/Jira de eerste is waar ik nu aan kan denken en de naam van weet.

Kortom, ik zou de huidige keuze die precies omgekeerd is van want naar mijn idee bij de gemiddelde Nederlander gangbaar is, met dank aan Whatsapp (hate it or love it), nog eens sterk heroverwegen!

[Vliegvlug]

DaFeliX schreef op dinsdag 26 mei 2026 @ 09:00:
[...]

We doen juist heel bewust niet meerdere notaties ondersteunen voor dezelfde opmaak. Enerzijds is dat verwarrend, anderzijds blokkeert dat om die notatie eventueel in de toekomst voor iets anders te gebruiken.

Als er geen alternatieve opties gaan worden ondersteund vanuit principe lijkt het me nog belangrijker om er goed over na te denken.
En dan niet met een technisch bril, waarvan ik de indruk krijg dat nu het geval is, maar vooral naar de doelgroep, de gebruikers dus, en de gewenste aanwas daarvan te kijken!

Zoals ik in mijn post hierboven al aangeef zegt mijn gevoel dat het overgrote deel * voor bold en _ voor cursief kent.


Maar laat het vooral objectief onderzoeken, een poll op de FP zal waarschijnlijk al een goede indicatie geven.
Daarbij niet aangeven dat het om een keuze voor de editor gaat maar simpelweg vragen wat men het meest logisch vindt voor vet en cursief: *vet* & _cursief_ of _vet_ & *cursief* plus nog wat opties.

Ik ben geen poll maker maar die zijn er bij Tweakers vast wel zodat het een beetje objectieve resultaten geeft.
Ben erg benieuwd wat daar uitkomt.