Wysiwyg-editor als bètafeature

[MazeWing]

DaFeliX schreef op maandag 15 september 2025 @ 10:33:
[...]


Ja, dit is zoals 't hoort. Zoals ik al eerder op jouw reactie reageerde, het staat hier boven uitgelegd waarom we deze keuze hebben gemaakt.

Ok en hoe ziet men het dan voor zich bij het typen van een reactie? Dat het steeds doorlopende zinnen zijn en iets op de volgende regel zetten om het leesbaar te maken enkel is te bereiken door handmatig die lege regel te verwijderen?
Dus dat deze regel standaard een nieuwe alinea was en ik handmatig de lege regel moest verwijderen?

[DaFeliX]

MazeWing schreef op maandag 15 september 2025 @ 10:36:
[...]

Ok en hoe ziet men het dan voor zich bij het typen van een reactie? Dat het steeds doorlopende zinnen zijn en iets op de volgende regel zetten om het leesbaar te maken enkel is te bereiken door handmatig die lege regel te verwijderen?
Dus dat deze regel standaard een nieuwe alinea was en ik handmatig de lege regel moest verwijderen?

In onze ervaring is het vaker zo dat mensen een nieuwe alinea willen gebruiken, dan witregels wil invoegen; vandaar dat dit de 'standaard' is als je op <Enter> drukt.

Als je een voorstel hebt hoe we dit beter kunnen doen, houden wij ons graag aanbevolen

[crisp]

We zouden kunnen opteren voor een <br>-knop in de editor (voor mobiel, waar shift-enter niet werkt), maar ook ik vraag me af wanneer je alleen een enkele linebreak zou willen in plaats van een nieuwe alinea. Het gebruik van alinea's maakt een tekst juist leesbaarder.

Text-editor apps werken ook grotendeels zo, dus ik begrijp ook niet waarom het de editor "compleet onbruikbaar" zou maken

[MazeWing]

DaFeliX schreef op maandag 15 september 2025 @ 10:39:
[...]


In onze ervaring is het vaker zo dat mensen een nieuwe alinea willen gebruiken, dan witregels wil invoegen; vandaar dat dit de 'standaard' is als je op <Enter> drukt.

Als je een voorstel hebt hoe we dit beter kunnen doen, houden wij ons graag aanbevolen

Sorry bedoelde shift+enter ipv ctrl+enter.

Op een apparaat met toetsenbord vind ik dit niet zo erg maar op mobiel is het nu de omgekeerde wereld. Daar heb je geen mogelijkheid om jullie standaard instelling te "overrulen" Wil ik echt een nieuwe regel dan zal ik hoe dan ook handmatig de extra witregel moeten verwijderen. Dat is natuurlijk onbegonnen werk als je een grote post wil maken.

Het lijkt me dan ook beter om dit of uit te schakelen voor mobiel of een optie te maken waarbij je dit kan wisselen. Ik denk dat de laatste optie voor de meeste mensen de voorkeur heeft. Ik ben namelijk iemand die groot voorstander is van "enter = de volgende regel".

[MazeWing]

crisp schreef op maandag 15 september 2025 @ 10:46:
We zouden kunnen opteren voor een <br>-knop in de editor (voor mobiel, waar shift-enter niet werkt), maar ook ik vraag me af wanneer je alleen een enkele linebreak zou willen in plaats van een nieuwe alinea. Het gebruik van alinea's maakt een tekst juist leesbaarder.

Text-editor apps werken ook grotendeels zo, dus ik begrijp ook niet waarom het de editor "compleet onbruikbaar" zou maken

Omdat er genoeg situaties te bedenken zijn waarbij je voor de leesbaarheid wel wil kiezen voor een nieuwe regel maar het ook weer niet meteen een nieuwe alinea hoeft te worden.

[crisp]

MazeWing schreef op maandag 15 september 2025 @ 10:54:
[...]

Omdat er genoeg situaties te bedenken zijn waarbij je voor de leesbaarheid wel wil kiezen voor een nieuwe regel maar het ook weer niet meteen een nieuwe alinea hoeft te worden.

Maar is het in zulke situaties dan erg dat het wel een nieuwe alinea wordt? Kan je wat concrete voorbeelden geven en duiden hoe vaak dat dan voorkomt ten opzichte van de situaties waarbij een nieuwe alinea geen probleem is?

Ik lees vooral dat het een persoonlijke voorkeur is, maar niet waarom het problematisch is.

[DaFeliX]

MazeWing schreef op maandag 15 september 2025 @ 10:49:
[...]

Sorry bedoelde shift+enter ipv ctrl+enter.

Op een apparaat met toetsenbord vind ik dit niet zo erg maar op mobiel is het nu de omgekeerde wereld. Daar heb je geen mogelijkheid om jullie standaard instelling te "overrulen" Wil ik echt een nieuwe regel dan zal ik hoe dan ook handmatig de extra witregel moeten verwijderen. Dat is natuurlijk onbegonnen werk als je een grote post wil maken.

[...]

Hmm, wel een goed punt dat een mobiel toetsenbord anders werkt dan een fysieke. Of het dan op mobiel anders zou moet werken dan op desktop, dat weet ik eigenlijk nog niet. Daar kunnen we nog wel 'ns over nadenken. Maar zo op 't eerste gezicht lijkt het mij dat consistentie belangrijk is. We zouden natuurlijk 'ns kunnen onderzoeken hoe andere systemen dat doen specifiek voor mobiel.

MazeWing schreef op maandag 15 september 2025 @ 10:49:
[...]
Het lijkt me dan ook beter om dit of uit te schakelen voor mobiel of een optie te maken waarbij je dit kan wisselen. Ik denk dat de laatste optie voor de meeste mensen de voorkeur heeft. Ik ben namelijk iemand die groot voorstander is van "enter = de volgende regel".

DaFeliX schreef op donderdag 22 mei 2025 @ 14:18:
[...]
Ik kan je in elk geval al wel vertellen dat het introduceren van een toggle voor het enter/shift+enter gedrag niet iets is wat ik zie zitten. Wat mij betreft doen we het op 1 manier, en gaan we daar geen extra code voor introduceren omdat er groep gebruikers zijn die het liever anders zien.
[...]

[MazeWing]

Volgens genootschap onze taal:
"Een alinea is een verzameling zinnen die met elkaar samenhangen. Alinea’s zijn als het ware de bouwstenen van je tekst: de kleinere eenheden binnen het geheel. Elke alinea stelt één onderwerp centraal."

Dat betekent dus dat wanneer ik een enter gebruik Tweakers denkt (en kennelijk verwacht) dat ik over een nieuw onderwerp (of kerngedachte) ga schrijven. Maar als ik het voor de leesbaarheid op een nieuw regel wil zetten (want het heeft nog wel hetzelfde onderwerp maar moet wel onderscheidend genoeg zijn) dan wordt dit feitelijk onmogelijk gemaakt door de keuze van Tweakers.

Meer info: https://www.scribbr.nl/essay/paragrafen-en-alineas-scriptie/

Voorbeeld 1:

Er zijn verschillende videokaarten. De 3 grote merken zijn Nvidia, AMD en Intel.
Nvidia heeft als grote voordeel dat ze het grootste marktaandeel hebben en veel samenwerken met game developers. Hierdoor worden er vaak nieuwe technieken zoals DLSS, Frame Generation en Nvidia Reflex toegepast.
AMD heeft als grote voordeel dat ze vaak wat goedkoper zijn en meer performance per dollar hebben. Helaas is de samenwerking met game developers kleiner waardoor nieuwe technieken zoals FSR 4 minder snel worden toegepast.
Intel heeft eigenlijk geen rol van betekenis (meer). In het begin leken ze een aardig alternatief te zijn als je een goede budget oplossing wilde hebben. Echter bleken de drivers niet heel goed te zijn waardoor performance, zeker in nieuwe spellen, vaak achterbleef bij Nvidia en AMD.

Bovenstaande is maar een klein voorbeeld. Het gaat over de 3 vidoekaartmerken (dat is het onderwerp) en vervolgens maak ik het leesbaarder door Nvidia, AMD en Intel ieder op een eigen regel te laten beginnen. Volgens jullie (lees: Tweakers) zou het dus op 1 van de volgende manieren moeten:

Voorbeeld 2 (standaard instelling wanneer je op enter drukt):

Er zijn verschillende videokaarten. De 3 grote merken zijn Nvidia, AMD en Intel.

Nvidia heeft als grote voordeel dat ze het grootste marktaandeel hebben en veel samenwerken met game developers. Hierdoor worden er vaak nieuwe technieken zoals DLSS, Frame Generation en Nvidia Reflex toegepast.

AMD heeft als grote voordeel dat ze vaak wat goedkoper zijn en meer performance per dollar hebben. Helaas is de samenwerking met game developers kleiner waardoor nieuwe technieken zoals FSR 4 minder snel worden toegepast.

Intel heeft eigenlijk geen rol van betekenis (meer). In het begin leken ze een aardig alternatief te zijn als je een goede budget oplossing wilde hebben. Echter bleken de drivers niet heel goed te zijn waardoor performance, zeker in nieuwe spellen, vaak achterbleef bij Nvidia en AMD.

of

Voorbeeld 3 (wanneer je niet handmatig witregels wil verwijderen en je dus geen enter kan gebruiken):

Er zijn verschillende videokaarten. De 3 grote merken zijn Nvidia, AMD en Intel. Nvidia heeft als grote voordeel dat ze het grootste marktaandeel hebben en veel samenwerken met game developers. Hierdoor worden er vaak nieuwe technieken zoals DLSS, Frame Generation en Nvidia Reflex toegepast. AMD heeft als grote voordeel dat ze vaak wat goedkoper zijn en meer performance per dollar hebben. Helaas is de samenwerking met game developers kleiner waardoor nieuwe technieken zoals FSR 4 minder snel worden toegepast. Intel heeft eigenlijk geen rol van betekenis (meer). In het begin leken ze een aardig alternatief te zijn als je een goede budget oplossing wilde hebben. Echter bleken de drivers niet heel goed te zijn waardoor performance, zeker in nieuwe spellen, vaak achterbleef bij Nvidia en AMD.

Is dit een duidelijk genoeg voorbeeld of moet ik er meer verzinnen? Wil ik namelijk voorbeeld 1 op mobiel typen dan zou ik handmatig alle witregels uit voorbeeld 2 eruit moeten halen. Zeker met een lap tekst is dit bijna niet te doen op een mobiel.

[ Voor 3% gewijzigd door MazeWing op 15-09-2025 11:11 ]

[BLACKfm]

crisp schreef op donderdag 21 augustus 2025 @ 20:50:
[...]
[...]maar het vereist dus inderdaad wel dat als je je post wilt eindigen met een smiley dat je dan nog even een spatie of enter moet doen.

Gezien elk normaal mens na een zin, buiten een smiley, vast ook nog wel een punt (. of wellicht een ander leesteken) gebruikt zou je eventueel die nog als trigger(s) kunnen toevoegen?

[ Voor 3% gewijzigd door BLACKfm op 15-09-2025 11:12 ]

[crisp]

BLACKfm schreef op maandag 15 september 2025 @ 11:11:
[...]


Gezien elk normaal mens na een zin, buiten een smiley, vast ook nog wel een punt (. of wellicht een ander leesteken) gebruikt zou je eventueel die nog als trigger(s) kunnen toevoegen?

Dat is technisch lastig aangezien leestekens juist vaak ook deel uitmaken van de smileycode.

Edit: dat is slechts deel van het probleem (alleen een vraagteken zou dan echt problematisch zijn op dit moment), maar het is ook zo dat in RML een smiley niet geparsed wordt na een leesteken, en dat is niet iets wat we zomaar zullen aanpassen:

.
?
,
:);
:)!

Edit2: mmm, wait wut Wel dus na een punt, komma of vraagteken... toch eens naar kijken dan...

[ Voor 30% gewijzigd door crisp op 15-09-2025 12:42 ]

[crisp]

MazeWing schreef op maandag 15 september 2025 @ 11:08:

Voorbeeld 2 (standaard instelling wanneer je op enter drukt):

[...]

Naar mijn mening is dit voorbeeld gewoon het leesbaarst, en ook gewoon correct

Dit zijn de deelonderwerpen per alinea:

alinea 1: opsomming van de 3 grote merken
alinea 2: beschrijving Nvidea
alinea 3: beschrijving AMD
alinea 4: beschrijving Intel

Als je over echt een compleet ander onderwerp wilt schrijven dan kan je je content verder indelen met koppen en dergelijke, of wellicht verdelen over meerdere posts/reacties.

[ Voor 16% gewijzigd door crisp op 15-09-2025 12:51 ]

[MazeWing]

crisp schreef op maandag 15 september 2025 @ 12:48:
[...]

Naar mijn mening is dit voorbeeld gewoon het leesbaarst, en ook gewoon correct

Dit zijn de deelonderwerpen per alinea:

alinea 1: opsomming van de 3 grote merken
alinea 2: beschrijving Nvidea
alinea 3: beschrijving AMD
alinea 4: beschrijving Intel

Als je over echt een compleet ander onderwerp wilt schrijven dan kan je je content verder indelen met koppen en dergelijke, of wellicht verdelen over meerdere posts/reacties.

Maar waarom gebruiken dan praktisch alle messenger apps, Facebook en veel andere website gewoon de “oude manier” van enter = de volgende regel?

Al sinds 1998 werkt dit ook zo bij Tweakers (en nog steeds als je kiest voor broncode) en nu opeens, na 27 jaar moet het opeens anders. Anders waarbij de mobiele gebruiker helemaal de klos is.
Ook deze zin is weer een aparte regel omdat ik dit niet achter “de klos is” wil hebben en het ook geen aparte alinea moet worden.
Hoe zien jullie het voor je als ooit het forum ook deze nieuwe editor standaard gaat gebruiken. Voor mij is het dan simpelweg onbruikbaar geworden!

[Sissors]

Maar een Messenger kan je niet vergelijken met een forum natuurlijk. En in 1998 ging volgens mij standaard een Word ook slechts naar de volgende regel bij een nieuwe alinea, terwijl tegenwoordig die standaard naar een nieuwe alinea gaat.

Dan kunnen we het natuurlijk erover hebben of een forum meer is als een messenger of als een text verwerker, maar om nou te stellen dat het onbruikbaar is omdat er misschien weleens wat nodeloze alineas inkomen? Dat lijkt mij ook vergaand.

[Paul]

Ik merk het nu pas, maar ik merk dat ik er een mening over heb: Is er bij de "knoppen" "[ visueel | broncode ]" bewust gekozen het hele gebied één grote toggle te maken, in plaats van twee knoppen om de gewenste optie te kiezen?

Ik klik op "broncode" omdat ik zeker wil weten dat het daar op staat, en de boel verspringt. Ik klik er nog een keer op, en verwacht eerlijk gezegd dat de boel blijft staan, maar het verspringt weer... En omdat er maar twee opties zijn moet ik gokken dat de groene achtergrond met donkere tekst de actieve modus is en groene tekst op donkere achtergrond de inactieve modus, in plaats van dat ik het kan zien aan de twee of meer identieke inactieve en de ene actieve.

Ik kan het uiteraard zien aan de smileys, quotes, etc., maar ik merk dat ik het lastig vind dat als ik op "broncode" klik hij de helft van de tijd naar "visueel" verspringt

[crisp]

Paul schreef op vrijdag 19 september 2025 @ 10:04:
Ik merk het nu pas, maar ik merk dat ik er een mening over heb: Is er bij de "knoppen" "[ visueel | broncode ]" bewust gekozen het hele gebied één grote toggle te maken, in plaats van twee knoppen om de gewenste optie te kiezen?

[...]

We gebruiken dergelijke toggles eigenlijk al jaren op diverse plekken op de site, en overal is hij in het geheel klikbaar. Wel zijn er soms subtiele verschillen; bij sommige toggles tonen we alleen het label van de actieve optie wanneer duidelijk is wat de andere optie is (e.g. en/of of wel/geen), en bij bijvoorbeeld wel/geen-toggles maken we de achtergrond ook rood bij de negatieve keuze.

Uiteindelijk is dit een UX-kwestie, dus wellicht dat @Femme of @bozhoyo hier nog een mening over heeft.

[Paul]

Nu je het zegt heb ik ze inderdaad ook in bijvoorbeeld PW filters gezien. Daar zijn ze wel omgedraaid; het stuk dat niet groen is, is actief (en in het groene deel staat geen tekst meer, maar "broncode" en "visueel" zijn natuurlijk een stuk minder intuitief dan wel/geen en en/of als je één van de twee woorden weg laat) terwijl in de wysiwyg editor het groene deel actief is:

(ff met paint bij elkaar gezet en de reactiebox bij een fp-artikel wat kleiner gemaakt)

Ik snap het idee en de keuzes, maar vind het nog lastig Mogelijk vooral wennen; het is niet alsof ik vaak zal switchen

[ Voor 6% gewijzigd door Paul op 19-09-2025 14:34 ]

[sus]

crisp schreef op maandag 15 september 2025 @ 12:37:
[...]

Dat is technisch lastig aangezien leestekens juist vaak ook deel uitmaken van de smileycode.

Edit: dat is slechts deel van het probleem (alleen een vraagteken zou dan echt problematisch zijn op dit moment), maar het is ook zo dat in RML een smiley niet geparsed wordt na een leesteken, en dat is niet iets wat we zomaar zullen aanpassen:

.
?
,
:);
:)!

Edit2: mmm, wait wut Wel dus na een punt, komma of vraagteken... toch eens naar kijken dan...

Toch aangepast? Ik zie dat de smilies nu gewoon omgezet worden na posten. En niet in de wysiwyg als ik een spatie doe, dan blijft de smiliecode gewoon staan.

[crisp]

sus schreef op donderdag 9 oktober 2025 @ 16:03:
[...]


Toch aangepast? Ik zie dat de smilies nu gewoon omgezet worden na posten. En niet in de wysiwyg als ik een spatie doe, dan blijft de smiliecode gewoon staan.

Niet bewust iig... Zal morgen even kijken.

[sus]

crisp schreef op donderdag 9 oktober 2025 @ 16:33:
[...]

Niet bewust iig... Zal morgen even kijken.

Nee nee, is prima nu Niks meer aan doen

[crisp]

sus schreef op donderdag 9 oktober 2025 @ 18:16:
[...]


Nee nee, is prima nu Niks meer aan doen

[laptopleon]

Als ik bij een frontpage nieuwsbericht reageer, en ik wil een stukje tekst als een quote of bijvoorbeeld bold aanmerken, dan lukt dat regelmatig niet. Gebeurt gewoon niets. Safari, iOS, iPhone Max Pro, laatste versies.



(Of kan dit beter in een apart topic omdat het niet meer beta is?)

[crisp]

laptopleon schreef op maandag 10 november 2025 @ 14:39:
Als ik bij een frontpage nieuwsbericht reageer, en ik wil een stukje tekst als een quote of bijvoorbeeld bold aanmerken, dan lukt dat regelmatig niet. Gebeurt gewoon niets. Safari, iOS, iPhone Max Pro, laatste versies.

[Afbeelding]

(Of kan dit beter in een apart topic omdat het niet meer beta is?)

Wat voor device/browser/versie is dat? Werkt het wel in wysiwyg-modus?

[Meg]

Is het al bekend wanneer de beta naar het forum komt?

[DaFeliX]

Meg schreef op maandag 10 november 2025 @ 15:27:
Is het al bekend wanneer de beta naar het forum komt?

[Meg]

DaFeliX schreef op maandag 10 november 2025 @ 15:31:
[...]


[Afbeelding]

Dank voor de update!

[AW_Bos]

DaFeliX schreef op maandag 10 november 2025 @ 15:31:
[...]


[Afbeelding]

Wat houdt dat laatste knopje met die 'bug' in? wat kunnen jullie dan zien?
Ik vermoed dat dat een developer-feature is?

[beeldbuijs]

crisp schreef op maandag 10 november 2025 @ 14:48:
[...]
Wat voor device/browser/versie is dat? Werkt het wel in wysiwyg-modus?

iPhone 16 Pro Max / Safari -> kon geen versienummer vinden, blijkt dat dit gekoppeld is aan de versie van iOS / iOS 26.1

Het lukte op dat moment niet om te wisselen qua wysiwyg omdat de visueel / broncode knopjes dan net zo min werken. Dat zat ook in het filmpje maar om er een animated gif van te maken via Whatsapp mocht hij niet langer dan 6 seconden zijn dus die scene is gesneuveld in de final cut

[ Voor 32% gewijzigd door beeldbuijs op 10-11-2025 20:49 ]

[DaFeliX]

AW_Bos in "Wysiwyg-editor als bètafeature"AW_Bos schreef op maandag 10 november 2025 @ 15:48[/message]:
[...]

Wat houdt dat laatste knopje met die 'bug' in? wat kunnen jullie dan zien?
Ik vermoed dat dat een developer-feature is?

Scherp gezien! Het is inderdaad een feature die alleen developers zien als ze de editor gebruiken.

Het knopje toont de TUT. TUT ('Tweakers tUssenTaal') is een tussentaal die we gebruiken tussen RML en de editorspecifieke representatie van een 'document'. Het is een JSON representatie van het bericht wat dicht bij de orignele RML staat. TUT kunnen we in onze backend eenvoudig omzetten van en naar RML. De editor kan ook eenvoudig van en naar TUT worden vertaald. Door het gebruik van TUT maken we het onszelf wat makkelijker. De editor ondersteund dus niet direct RML en ook het testen wordt hierdoor wat makkelijker omdat je 'tot' en 'vanaf' TUT kunt gaan testen.

Feitelijk genereert de editor dus TUT, deze zetten we in de backend om naar RML en zo wordt het bericht onderhuids alsnog als RML opgeslagen. Andersom, als een bericht bewerkt moet worden, genereert onze backend TUT die we in de editor kunnen inladen. We hadden ook kunnen kiezen om HTML te gebruiken als tussentaal (RML is immers ook eenvoudig om te zetten naar HTML), alleen de 'terugweg' (van HTML naar RML) zou veel lastiger zijn en veel aanpassingen vereisen van onze backendparsers.
We hebben in het begin wel wat werk moeten steken in onze parser om TUT te ondersteunen, maar nu we bezig zijn met het uitwerken van verschillende functionaliteiten hoeven we ons geen 'zorgen' meer te maken om de RML. We hoeven de editor "alleen" maar de juiste TUT te laten genereren, en we weten dan dat de RML vanzelf goed vertaald kan worden.

[crisp]

beeldbuijs schreef op maandag 10 november 2025 @ 20:43:
[...]

iPhone 16 Pro Max / Safari -> kon geen versienummer vinden, blijkt dat dit gekoppeld is aan de versie van iOS / iOS 26.1

Het lukte op dat moment niet om te wisselen qua wysiwyg omdat de visueel / broncode knopjes dan net zo min werken. Dat zat ook in het filmpje maar om er een animated gif van te maken via Whatsapp mocht hij niet langer dan 6 seconden zijn dus die scene is gesneuveld in de final cut

Ik heb het even getest in BrowserStack, maar kan het daar niet reproduceren. Ik weet dus niet wat er precies mis gaat of is gegaan...

[laptopleon]

crisp schreef op dinsdag 11 november 2025 @ 07:55:
[...]

Ik heb het even getest in BrowserStack, maar kan het daar niet reproduceren. Ik weet dus niet wat er precies mis gaat of is gegaan...

Het gebeurt bij mij niet consequent. Ik weet helaas ook niet wat het triggert.

[AW_Bos]

DaFeliX schreef op dinsdag 11 november 2025 @ 07:25:
[...]

Scherp gezien! Het is inderdaad een feature die alleen developers zien als ze de editor gebruiken.
Het knopje toont de TUT. TUT ('Tweakers tUssenTaal') is een tussentaal die we gebruiken tussen RML en de editorspecifieke representatie van een 'document'.
[...]

Dankjewel voor de uitleg over dit ingenieus bedachte stukje techniek. Ik zie ook dat je AJAX-requests voorbij ziet komen van rml-to-tut en tut-to-rml als je van en naar de broncode-modus naar visueel en andersom switched. Maar voor devvers is een snelle output wel zo handig, snap ik .

[Proton_]

Als ik een link naar een message plak, wordt het in de wysiwyg-editor
https://gathering.tweakers.net/forum/list_message/57493804#57493804
en met de broncode-editor
Proton_ in "Iemand ooit gemeten aan douchewarmtewisselaar (DWTW)?"
waarbij de laatste natuurlijk beter is

[crisp]

Proton_ schreef op maandag 24 november 2025 @ 12:22:
Als ik een link naar een message plak, wordt het in de wysiwyg-editor
https://gathering.tweakers.net/forum/list_message/57493804#57493804
en met de broncode-editor
Proton_ in "Iemand ooit gemeten aan douchewarmtewisselaar (DWTW)?"
waarbij de laatste natuurlijk beter is :)

Dat klopt, die staat ook nog op de to-do :)

[br00ky]

Copy-paste vanaf mobiele Firefox werkt niet zodra er een smiley in het bericht zit. Ik bevestig nick changes altijd met

Prima, bij deze

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.

[ Voor 8% gewijzigd door br00ky op 24-11-2025 13:10 ]

[DaFeliX]

Prima, bij deze

Het lijkt dus browserafhankelijk; Firefox op desktop werkt nl wel. Ik maak even een bugticket aan om dit te onderzoeken.

[MazeWing]

@crisp Komt er nog een toggle (op mobiel) voor de editor om te wisselen tussen enter=nieuwe regel of enter=nieuwe alinea?

Of gaan we 2026 een nieuw record halen voor meeste backspace gebruik ever!?

[crisp]

MazeWing schreef op donderdag 4 december 2025 @ 16:10:
@crisp Komt er nog een toggle (op mobiel) voor de editor om te wisselen tussen enter=nieuwe regel of enter=nieuwe alinea?

Of gaan we 2026 een nieuw record halen voor meeste backspace gebruik ever!?

Nee, daar zijn op dit moment geen plannen voor. Het is technisch erg bewerkelijk om dat te faciliteren, en we hebben er eigenlijk nog geen sterke use-case voor gezien.

[MazeWing]

crisp schreef op donderdag 4 december 2025 @ 18:19:
[...]

Nee, daar zijn op dit moment geen plannen voor. Het is technisch erg bewerkelijk om dat te faciliteren, en we hebben er eigenlijk nog geen sterke use-case voor gezien.

Maar hoe zie je het dan voor je als het ook op het forum actief wordt en mensen op hun mobiel een post maken. Iedere keer dat men op enter drukt komt er een nieuwe alinea en mag men op backspace drukken.

Het in “1 keer” goed doen dmv shift+enter is simpelweg niet mogelijk. Dat men hier geen use case voor ziet vind ik echt onbegrijpelijk!!

Buiten dat vraag ik me echt af wat er technisch lastig aan is. Ergens staat nu ingesteld dat een enter een nieuwe alinea is. Dit kan toch met 1 simpele regel aangepast worden naar “new line”?

[ Voor 13% gewijzigd door MazeWing op 04-12-2025 18:35 ]

[crisp]

MazeWing schreef op donderdag 4 december 2025 @ 18:33:
[...]

Maar hoe zie je het dan voor je als het ook op het forum actief wordt en mensen op hun mobiel een post maken. Iedere keer dat men op enter drukt komt er een nieuwe alinea en mag men op backspace drukken.

Het in “1 keer” goed doen dmv shift+enter is simpelweg niet mogelijk. Dat men hier geen use case voor ziet vind ik echt onbegrijpelijk!!

Buiten dat vraag ik me echt af wat er technisch lastig aan is. Ergens staat nu ingesteld dat een enter een nieuwe alinea is. Dit kan toch met 1 simpele regel aangepast worden naar “new line”?

Er is m.i. geen noodzaak om meerdere zinnen in dezelfde alinea te scheiden met een enter. Je kan na de punt gewoon een nieuwe zin schrijven. En als je het vervolgens over een ander onderwerp hebt, dan maak je een nieuwe alinea.

Kan jij een voorbeeld laten zien waar een enkele enter binnen een alinea noodzakelijk is? Ik zie het namelijk maar weinig gebeuren, en als iemand het doet had het bijna altijd ook zonder enter gekund, of was een nieuwe alinea juist beter geweest

offtopic:
Deze post is overigens op mobiel getypt in de wysiwyg-editor zonder gebruik van enters

[Proton_]

Misschien is met CCS een compromis te realiseren door een witregel halve hoogte te maken?
@crisp
Ascii art moet natuurlijk wel uitlijnen

code:

 O . O
 \___/

Maar code wordt nog niet ondersteund

[ Voor 40% gewijzigd door Proton_ op 04-12-2025 18:53 ]

[Proton_]

Ik heb ook gemerkt dat Chrome op Android bij het switchen van tabs de pagina na een tijdje half refresht (dit ligt niet aan Tweakers) en reeds getypte tekst in hetzij de wysiwyg als broncode editor blijft dan niet behouden.
Voorheen had ik daar nooit last van.

[ Voor 4% gewijzigd door Proton_ op 04-12-2025 18:53 ]

[crisp]

Proton_ schreef op donderdag 4 december 2025 @ 18:44:
Misschien is met CCS een compromis te realiseren door een witregel halve hoogte te maken?

Dat suggereert dat het motief een compactere tekst is? Vanuit leesbaarheid lijkt me dat juist onwenselijk.

@crisp
Ascii art moet natuurlijk wel uitlijnen

code:

 O . O
 \___/

Maar code wordt nog niet ondersteund

De code-, cmd- en pre-tags staan hoog op onze priolijst

[crisp]

Proton_ schreef op donderdag 4 december 2025 @ 18:47:
Ik heb ook gemerkt dat Chrome op Android bij het switchen van tabs de pagina na een tijdje half refresht (dit ligt niet aan Tweakers) en reeds getypte tekst in hetzij de wysiwyg als broncode editor blijft dan niet behouden.
Voorheen had ik daar nooit last van.

Op de frontpage geven we een waarschuwing als bij een paginaverversing er nog inhoud in de editor staat; wellicht moeten we dat op het forum ook overwegen? Geen idee of dat in jouw geval zou helpen overigens, ik herken het probleem namelijk niet.

[MazeWing]

crisp schreef op maandag 15 september 2025 @ 12:48:
[...]

Naar mijn mening is dit voorbeeld gewoon het leesbaarst, en ook gewoon correct

Dit zijn de deelonderwerpen per alinea:

alinea 1: opsomming van de 3 grote merken
alinea 2: beschrijving Nvidea
alinea 3: beschrijving AMD
alinea 4: beschrijving Intel

Als je over echt een compleet ander onderwerp wilt schrijven dan kan je je content verder indelen met koppen en dergelijke, of wellicht verdelen over meerdere posts/reacties.

Ik quote even een oude post van je, waarin we eigenlijk dezelfde soort discussie hebben gehad.
In de opsomming van alinea’s heb je geen gebruik gemaakt van een punt dus kon heenkeek naar de volgende regel met enter (of shift+enter). Hoe zou jij bovenstaande post op je mobiel hebben gedaan?

[crisp]

MazeWing schreef op donderdag 4 december 2025 @ 21:13:
[...]

Ik quote even een oude post van je, waarin we eigenlijk dezelfde soort discussie hebben gehad.
In de opsomming van alinea’s heb je geen gebruik gemaakt van een punt dus kon heenkeek naar de volgende regel met enter (of shift+enter). Hoe zou jij bovenstaande post op je mobiel hebben gedaan?

Waarschijnlijk als een lijst:

• Alinea 1: ...
• Alinea 2: ...
• Alinea 3: ...

[MazeWing]

crisp schreef op donderdag 4 december 2025 @ 22:09:
[...]

Waarschijnlijk als een lijst:

• Alinea 1: ...
• Alinea 2: ...
• Alinea 3: ...

Ja en nu zonder lijst, want kennelijk vond jij het destijds ook niet nodig een lijst te maken….

[crisp]

MazeWing schreef op donderdag 4 december 2025 @ 22:58:
[...]

Ja en nu zonder lijst, want kennelijk vond jij het destijds ook niet nodig een lijst te maken….

Ik ontdek zojuist dat shift+enter dat effect ook heeft op mijn Android tablet.
Zo dus

[Meg]

Kleine schop omhoog, maar klopt het dat de bèta live is op het forum of hebben jullie een knopje verkeerd gezet waardoor ik het nu wel heb en hoort dat niet?

Buiten dat om, het werkt fantastisch.

Ik zag het nieuwsbericht niet, had de FP nog niet open.

[ Voor 15% gewijzigd door Meg op 27-01-2026 09:33 ]

[ge-flopt]

De opmaak van de knoppenbalk is niet consequent doorgevoerd, terwijl de functies naar mijn idee hetzelfde is.
Visueel: Broncode:

Misschien dat wat gelijk trekken en dezelfde knoppen op beide is wel makkelijk. In visueel kun je ook onderdelen willen quoten vanaf de knoppenbalk bv.

[WCA]

Eerste indruk: ziet er goed uit!

code:

Dit soort zaken maakt het wel makkelijjker om precies te zien wat je doet

En CTRL enter om het codeveld te 'escapen' werkt ook netjes

Inline plaatjes toevoegen werkt ook netjes (maar ga ik hier tbv de netheid niet posten)

Zo zie je maar dat zeker niet alle verandering slecht hoeft te zijn, lekker bezig!

[AW_Bos]

Er missen nog wat name labels voor Links/Midden/Rechts uitlijnen.

Verder mooi dat deze editor als beta naar het forum gebracht is.

[ Voor 7% gewijzigd door AW_Bos op 27-01-2026 10:23 ]

[True]

@crisp valt in deze update: .plan: Wysiwygeditor als bèta in forum ook dat scrollen als je een GoT notificatie opent of een pagina terug gaat en de browser dan voor mij naar de juiste verticale plek scrollt op de pagina waar ik was?
Ik lees dit namelijk nergens terug en behalve als ik een TIA heb, is dit nieuw t.o.v. gisteren, kan dit kloppen (het nieuwe, niet de TIA)?

Edit: en als je een post plaatst scrollt de pagina ook na het posten naar beneden naar mijn post.
Edit2: en bij editen ook.
Edit3: geen TIA dus maar smooth scrolling van Chrome.

[ Voor 15% gewijzigd door True op 27-01-2026 14:09 ]

[World Citizen]

Joe!

Ik deed altijd afbeeldingen invoeren vanuit het fotoalbum, en dan in de broncode even de resolutie aanpassen zodat het geen enorme foto's worden. Maar ik weet niet meer hoe het moet nu.

Als je bv een printscreen maakt van je gsm en die upload, dan zijn het van de mega foto's.

code:

[url="https://tweakers.net/i/WIh5wW7Oehm4blVoUDWefUUa-u8=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/P3ZnCQrgjagFx6Rm9FClTMqI.png?f=user_large",,1][img=640,1391]https://tweakers.net/i/gXZ9QQzTOl1KVuFN-JEA68zpvqM=/x800/filters:strip_exif()/f/image/P3ZnCQrgjagFx6Rm9FClTMqI.png?f=fotoalbum_large[/img][/url]

Ergens zie je die [img=640,1391] tag. Vroeger veranderde ik dat en dan werd de foto wat kleiner, maar als ik dat nu doe voert de GoT kookpot iets uit waardoor hij alsnog groot blijft.
In de WYSIUWYG editor kan ik hem ook niet resizen met schalingsknopjes zover ik kan zien?

Iemand een tip? Telkens 2 afbeeldingen in thumbnail toevoegen en dan 1 afbeelding uit het tabel slopen is ook weer zo veel werk.

Thanks.

[crisp]

True schreef op dinsdag 27 januari 2026 @ 11:52:
@crisp valt in deze update: .plan: Wysiwygeditor als bèta in forum ook dat scrollen als je een GoT notificatie opent of een pagina terug gaat en de browser dan voor mij naar de juiste verticale plek scrollt op de pagina waar ik was?
Ik lees dit namelijk nergens terug en behalve als ik een TIA heb, is dit nieuw t.o.v. gisteren, kan dit kloppen (het nieuwe, niet de TIA)?

Edit: en als je een post plaatst scrollt de pagina ook na het posten naar beneden naar mijn post.
Edit2: en bij editen ook.

Dat de pagina in die situaties naar een bepaalde positie scrollt is niet nieuw, maar dat dat geanimeerd gebeurd wel. Dat is echter geen effect van de release van de nieuwe wysiwyg-editor.

[crisp]

World Citizen schreef op dinsdag 27 januari 2026 @ 12:14:
Joe!

Ik deed altijd afbeeldingen invoeren vanuit het fotoalbum, en dan in de broncode even de resolutie aanpassen zodat het geen enorme foto's worden. Maar ik weet niet meer hoe het moet nu.

Als je bv een printscreen maakt van je gsm en die upload, dan zijn het van de mega foto's.

code:

[url="https://tweakers.net/i/WIh5wW7Oehm4blVoUDWefUUa-u8=/fit-in/4000x4000/filters:no_upscale():strip_exif()/f/image/P3ZnCQrgjagFx6Rm9FClTMqI.png?f=user_large",,1][img=640,1391]https://tweakers.net/i/gXZ9QQzTOl1KVuFN-JEA68zpvqM=/x800/filters:strip_exif()/f/image/P3ZnCQrgjagFx6Rm9FClTMqI.png?f=fotoalbum_large[/img][/url]

Ergens zie je die [img=640,1391] tag. Vroeger veranderde ik dat en dan werd de foto wat kleiner, maar als ik dat nu doe voert de GoT kookpot iets uit waardoor hij alsnog groot blijft.
In de WYSIUWYG editor kan ik hem ook niet resizen met schalingsknopjes zover ik kan zien?

Iemand een tip? Telkens 2 afbeeldingen in thumbnail toevoegen en dan 1 afbeelding uit het tabel slopen is ook weer zo veel werk.

Thanks.

Via het afbeelding-knopje in de toolbar kan je de hoogte/breedte aanpassen:

[Paul]

True schreef op dinsdag 27 januari 2026 @ 11:52:
de browser dan voor mij naar de juiste verticale plek scrollt op de pagina waar ik was?

Volgens mij heeft Chrome een nieuwe "feature". chrome://flags/#smooth-scrolling op disabled zetten fixt het.

Edit: Ligt niet aan Chrome: Geanimeerde scroll? Kan dat ook uit?

[ Voor 13% gewijzigd door Paul op 27-01-2026 14:24 ]

[3_s]

crisp schreef op dinsdag 27 januari 2026 @ 12:25:
[...]

Dat de pagina in die situaties naar een bepaalde positie scrollt is niet nieuw, maar dat dat geanimeerd gebeurd wel. Dat is echter geen effect van de release van de nieuwe wysiwyg-editor.

En kan dat terug af? Is om misselijk van te worden. Of is dat ergens een instelling?

[crisp]

3_s schreef op dinsdag 27 januari 2026 @ 12:41:
[...]

En kan dat terug af? Is om misselijk van te worden. Of is dat ergens een instelling?

Je kan dit in je custom css zetten:

code:

:root {
  scroll-behavior: auto;
}

[World Citizen]

crisp schreef op dinsdag 27 januari 2026 @ 12:29:
[...]

Via het afbeelding-knopje in de toolbar kan je de hoogte/breedte aanpassen:

[Afbeelding]

Gelukt! En prima zo, fijne functie.

Dank!

[Zerora]

Nog niet alle forum tags worden goed ondersteund. De [br]-tag doet ie moeilijk mee. Nu heb ik het hier als tekst getypt in de visueel-modus. Maar als ik die tag bij broncode typ en dan terugschakel naar visueel, krijg je de onderstaande foutmelding.

[crisp]

Zerora schreef op dinsdag 27 januari 2026 @ 14:11:
Nog niet alle forum tags worden goed ondersteund. De [br]-tag doet ie moeilijk mee. Nu heb ik het hier als tekst getypt in de visueel-modus. Maar als ik die tag bij broncode typ en dan terugschakel naar visueel, krijg je de onderstaande foutmelding.

[Afbeelding]

Dat klopt en is in de .plan ook vermeld

[Toppe]

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:

[ Voor 88% gewijzigd door Toppe op 28-01-2026 15:35 ]

[_eLMo_]

Ik vind ‘m niet fijner dan de broncode editor. Ik wil vaak nog even het formaat van m’n ploatjes aanpassen en tags vind ik makkelijker te typen op mobiel dan dat ik een menu moet gebruiken waarbij m’n toetsen bord dicht klapt en hele scherm dus scrollt enzo.

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

[crisp]

Vliegvlug schreef op woensdag 28 januari 2026 @ 10:33:
[...]

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

Nee, dat heeft nooit zo gewerkt. Je kan met Shift+enter een enkele newline maken (werkt ook op mobiel - iig met Gboard op Android)

Kan dit alsjeblieft worden teruggedraaid, Please!

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

Want zo is die wysiwyg editor voor mij totaal onbruikbaar.

Wat is er precies onbruikbaar hierdoor?

[MazeWing]

crisp schreef op woensdag 28 januari 2026 @ 11:16:
Nee, dat heeft nooit zo gewerkt. Je kan met Shift+enter een enkele newline maken (werkt ook op mobiel - iig met Gboard op Android)

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.

En meer ga ik er niet meer over zeggen want het is toch aan dovemansoren gericht lijkt het….

[crisp]

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.

En meer ga ik er niet meer over zeggen want het is toch aan dovemansoren gericht lijkt het….

Tsja, het is simpelweg technisch erg lastig om het anders te implementeren, en aan de andere kant is het werken met paragrafen ook gemeengoed in veel editors en zie ik het probleem ook simpelweg niet. We hebben deze keuze gemaakt en gaan dat niet aanpassen.

Het enige waar we nog naar gaan kijken is support voor [br], wat wellicht ook een workaround kan zijn voor een enkele enter; afhankelijk van hoe we dat in de wysiwyg willen gaan faciliteren (wellicht een knopje in de toolbar).

[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
      },
    };
  },
});