Wysiwyg-editor als bètafeature

[Vliegvlug]

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

Volgens mij trek ik het niet in het belachelijke?

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

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

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

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

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

[Vliegvlug]

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

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

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

[Vliegvlug]

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

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

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

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

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

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

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

[MazeWing]

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

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

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

Change enter to break line instead of new paragraph

code:

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

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

Of is dit weer te simpel gedacht?

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

[Mog]

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

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

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

[crisp]

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


@crisp deze toevallig nog gezien?

Bijvoorbeeld:
Code: YAML
Code: PHP

Nu lijkt het alsof je geen tags hebt gebruikt

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

YAML:

[Afbeelding][Afbeelding]

Ja, daar hebben we al een ticket voor 🙂

[beeldbuijs]

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

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

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

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

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

Key Details regarding Shift-Return in Tiptap: 

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

javascript

code:

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

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

[Toppe]

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

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

[crisp]

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

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

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

[F_J_K]

Of ander leesteken , zoals de komma of .

[F_J_K]

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

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

[Toppe]

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

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

Edit, hij stond op Broncode

Lekker opgelet

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

[Webgnome]

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

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

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

[crisp]

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

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

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

[Meg]

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

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

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

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

[Webgnome]

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

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

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

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

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

[Meg]

Ik weet niet of dit al gevraagd is maar zou wanneer je een enter geeft de mogelijkheid kunnen komen om geen witregel er tussen te hebben?

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

[crisp]

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

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

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

[Meg]

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

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

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

[crisp]

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

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

En zo te zien gaat dat nog niet helemaal goed

[Meg]

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

En zo te zien gaat dat nog niet helemaal goed

Kan dat komen doordat vaste opmaak geen opmaak accepteert?

[crisp]

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

Kan dat komen doordat vaste opmaak geen opmaak accepteert?

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

[Meg]

* Meg snapt niets meer van wat meneer dev zegt.

Komen er trouwens ook andere kleuren?

[crisp]

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

Komen er trouwens ook andere kleuren?

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

[Vliegvlug]

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

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

Ik ook dus je bent niet de enige!

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

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

[Meg]

Ah, dank @Vliegvlug!

[AW_Bos]

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

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

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

[AW_Bos]

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

wordt een smilie met een )

:twk: en :henk: worden niet geparsed

[crisp]

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

wordt een smilie met een )

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

:twk: en :henk: worden niet geparsed

Het is ook zonder dubbele punt erachter

[crisp]

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

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

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

[TheVivaldi]

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

[crisp]

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

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

[crisp]

@TheVivaldi het wordt clientside bijgehouden in local storage

[TheVivaldi]

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

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

Ik ben nogal ouderwets en gooi mijn cookies nooit weg.

[TheVivaldi]

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

Die leeg ik ook nooit.

[crisp]

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

Die leeg ik ook nooit.

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

[beeldbuijs]

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

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

[DaFeliX]

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

We hebben nu de help uitgebreid met de uitleg hoe je een witregel invoegt; en (kudo's voor @crisp !) een extra 'markdownnotatie' toegevoegd. Je kunt nu een regel eindigen met twee spaties, gevolgd door een <enter> waarna een witregel wordt ingevoerd i.p.v. een nieuwe paragraaf gestart.

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

Hopelijk helpt dit een beetje

[crisp]

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

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

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

[Sissors]

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

We hebben nu de help uitgebreid met de uitleg hoe je een witregel invoegt; en (kudo's voor @crisp !) een extra 'markdownnotatie' toegevoegd. Je kunt nu een regel eindigen met twee spaties, gevolgd door een <enter> waarna een witregel wordt ingevoerd i.p.v. een nieuwe paragraaf gestart.

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

Hopelijk helpt dit een beetje

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

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

[crisp]

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

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

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

Daarom is er ook een helpfunctie

[MazeWing]

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

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

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

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

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

[Vliegvlug]

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

We hebben nu de help uitgebreid met de uitleg hoe je een witregel invoegt; en (kudo's voor @crisp !) een extra 'markdownnotatie' toegevoegd. Je kunt nu een regel eindigen met twee spaties, gevolgd door een <enter> waarna een witregel wordt ingevoerd i.p.v. een nieuwe paragraaf gestart.

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

Hopelijk helpt dit een beetje

Dat helpt zeker!

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

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

[Vliegvlug]

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

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

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

[crisp]

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

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

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

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

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

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

[Vliegvlug]

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

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

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

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

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

[Cambionn]

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

We hebben nu de help uitgebreid met de uitleg hoe je een witregel invoegt; en (kudo's voor @crisp !) een extra 'markdownnotatie' toegevoegd. Je kunt nu een regel eindigen met twee spaties, gevolgd door een <enter> waarna een witregel wordt ingevoerd i.p.v. een nieuwe paragraaf gestart.

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

Hopelijk helpt dit een beetje

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

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

Maar verder blijft het natuurlijk dat je:

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

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

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

[crisp]

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

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

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


[...]

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

[Vliegvlug]

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

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

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

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

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

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

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

[Cambionn]

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

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

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

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

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

[sus]

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

We hebben nu de help uitgebreid met de uitleg hoe je een witregel invoegt; en (kudo's voor @crisp !) een extra 'markdownnotatie' toegevoegd. Je kunt nu een regel eindigen met twee spaties, gevolgd door een <enter> waarna een witregel wordt ingevoerd i.p.v. een nieuwe paragraaf gestart.

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

Hopelijk helpt dit een beetje

Yes! Hele dikke dikke kudo’s!

[beeldbuijs]

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

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

Ik heb het alleen op mijn iPhone (Safari).

[beeldbuijs]

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

Hopelijk helpt dit een beetje

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

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

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

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

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

[DaFeliX]

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

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

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

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

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

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

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

[crisp]

In de help noemen we het "regelafbreking"

[Meg]

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

Verder nog steeds enorm tevreden.

[crisp]

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

Verder nog steeds enorm tevreden.

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

[Meg]

Wanneer komt de functie naar DMs?

[Help!!!!]

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

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

[crisp]

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

Voordat het live gaat, staat op de to-do

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

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

[Sissors]

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

[Vliegvlug]

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

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

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

[DaFeliX]

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

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

[duvekot]

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

[DaFeliX]

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

In broncode modus werkt het overigens wel gewoon.

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

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

[harley]

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

Hét grote motortopic - Deel 28 (2026)

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

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

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

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

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

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

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

[crisp]

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

Hét grote motortopic - Deel 28 (2026)

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

[...]

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

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

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

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

[harley]

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

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

[crisp]

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

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

Je kan het tekstveld vanuit de rechteronderhoek groter slepen

[harley]

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

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

[crisp]

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

[Afbeelding]

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

[harley]

Wat is daar dan wysiwyg aan ?

[crisp]

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

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

[AW_Bos]

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

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

Voorheen werkte dat geloof ik wel.

[F_J_K]

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

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

[crisp]

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

[AW_Bos]

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

[crisp]

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

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

[AW_Bos]

Ah, dat is duidelijk.

[Vliegvlug]

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

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

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



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

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

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



Onder, dan komt hij voor het plaatje:



In broncode weergave zit de tekst er zo uit:


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

[crisp]

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

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

[...]

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

[Vliegvlug]

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

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

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

[crisp]

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

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

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

[Toppe]

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

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

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

[crisp]

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

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

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

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

[Toppe]

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

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

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

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

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

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

[crisp]

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

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

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

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

Ik heb er in ieder geval een ticket voor gemaakt.

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

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

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

[Rolfie]

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

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

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


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

[Vliegvlug]

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

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

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


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

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

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

Er gebeurt bij mij helemaal niets met italic.

Ik zit op een iPad met Firefox als browser

[F_J_K]

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

2*2 is 4 maar 4*4 niet.

[Meg]

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

[Vliegvlug]

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

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

[Hero of Time]

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

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

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

Er gebeurt bij mij helemaal niets met italic.

Ik zit op een iPad met Firefox als browser

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

[Vliegvlug]

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

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

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

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

Foute aanname van mij

[Rolfie]

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

2*2 is 4 maar 4*4 niet.

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

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

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

[Rolfie]

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

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

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

Foute aanname van mij

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

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

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

[Rolfie]

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

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

[Meg]

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

[DaFeliX]

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

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

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

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

[Toppe]

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

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

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