Textarea vs Markdown vs Rich Text: Memilih Content Model CMS

Judul tampil normal, tetapi **teks tebal** ikut muncul mentah. Link video tersimpan, tetapi halaman publik tidak tahu harus merendernya sebagai player. Tim lalu menambah regex, kondisi khusus, dan tombol baru di editor.

Textarea bukan akar masalahnya. Yang belum beres adalah content model: sistem belum memutuskan apakah sebuah field berisi plain text, Markdown, HTML, atau dokumen terstruktur.

Keputusan ini perlu dibuat sebelum editor dipercantik. Kalau format penyimpanan, validasi, dan renderer tidak punya kontrak yang sama, editor secanggih apa pun hanya memindahkan kebingungan ke lapisan lain.

Textarea adalah input, bukan format konten

Elemen <textarea> pada HTML menerima dan mengirim nilai teks. Dokumentasi MDN untuk textarea menjelaskan bahwa isi terkini dibaca melalui properti value. Spesifikasi HTML juga menetapkan content model textarea sebagai teks.

Textarea tidak otomatis memahami bahwa:

• **tebal** harus menjadi <strong>;
• baris yang diawali ## adalah heading;
• URL YouTube perlu berubah menjadi iframe;
• blok kutipan harus punya tampilan khusus;
• sebuah gambar membutuhkan caption dan alt text.

Ia hanya menyediakan area untuk mengetik string. String itu bisa berisi plain text, Markdown, JSON, atau bahkan HTML. Arti dari string tetap ditentukan oleh aplikasi.

Karena itu, mengganti textarea dengan editor visual belum tentu menyelesaikan masalah. contenteditable="true", misalnya, membuat elemen bisa diedit dan mempertahankan formatting saat paste. MDN tentang contenteditable membedakannya dari plaintext-only, yang membuang formatting. Namun atribut tersebut tetap bukan content model, schema, sanitizer, atau renderer.

Empat pilihan yang sebenarnya sedang dipertimbangkan

Untuk CMS, pilihannya biasanya jatuh ke salah satu dari empat model berikut.

1. Plain text

Plain text cocok untuk field yang memang tidak membutuhkan struktur kaya:

• judul;
• label tombol;
• excerpt pendek;
• nama lokasi;
• catatan internal sederhana.

Keuntungannya jelas. Validasi mudah, rendering aman karena framework dapat melakukan escaping, dan datanya gampang dipakai lintas kanal.

Masalah muncul saat field plain text dipaksa menampung artikel, FAQ bertingkat, tabel, gambar, atau embed. Tim mulai menyisipkan konvensi informal yang tidak dikenali sistem. Pada titik itu, field-nya masih string, tetapi perilakunya sudah menyerupai bahasa markup tanpa parser yang jelas.

2. Markdown

Markdown juga disimpan sebagai plain text, tetapi punya syntax untuk struktur dokumen. CommonMark mendefinisikan blok dan inline seperti heading, list, emphasis, link, image, code block, dan raw HTML.

Model ini cocok ketika:

• konten dominan berupa tulisan;
• penulis nyaman dengan Markdown;
• perubahan ingin mudah dibaca di Git;
• output utamanya artikel atau dokumentasi;
• kebutuhan custom block masih terbatas.

Markdown tidak bisa diproses dengan sekadar mengganti **tebal** menjadi tag HTML lewat regex. Dokumen perlu melewati parser yang konsisten. CommonMark sendiri menjelaskan kenapa spesifikasi diperlukan: implementasi awal berbeda dalam menangani indentation, list, heading, precedence, dan banyak edge case lain.

Kalau aplikasi menerima Markdown, kontraknya harus lengkap:

Markdown source -> parser -> HTML -> sanitizer -> renderer

Parser menentukan struktur. Sanitizer membatasi output berbahaya. Renderer memastikan HTML yang sudah bersih tampil konsisten.

3. Rich text berbasis HTML

Editor WYSIWYG lama sering menyimpan HTML langsung. Model ini fleksibel karena browser memang merender HTML, tetapi fleksibilitas itu membawa dua beban.

Pertama, markup mudah menjadi tidak konsisten. Paste dari aplikasi lain dapat membawa elemen, style inline, dan atribut yang tidak dibutuhkan. Kedua, HTML dari pengguna tidak boleh langsung dipercaya.

OWASP Cross Site Scripting Prevention Cheat Sheet membedakan output encoding dan HTML sanitization. Kalau data hanya perlu tampil sebagai teks, gunakan encoding. Kalau pengguna memang boleh menulis HTML melalui editor, output encoding akan merusak formatting sehingga HTML perlu disanitasi dengan library yang dirawat.

Raw HTML masih bisa dipakai, tetapi harus ada allowlist elemen dan atribut, sanitasi setelah parsing, patch dependency berkala, serta QA untuk konten hasil paste. Untuk CMS baru, menyimpan HTML sebagai source of truth biasanya bukan pilihan pertama saya kecuali kebutuhan integrasi memang mengharuskannya.

4. Structured blocks

Structured blocks menyimpan dokumen sebagai tree atau array node. Paragraf, heading, gambar, video, quote, CTA, dan callout menjadi tipe data yang eksplisit.

Contoh sederhananya:

{
 "type": "video",
 "provider": "youtube",
 "videoId": "M7lc1UVf-VE",
 "caption": "Demo alur editor"
}

Bukan iframe mentah. Bukan pula URL yang nanti ditebak oleh renderer.

ProseMirror Guide memakai pendekatan dokumen terstruktur dengan schema. Dokumennya bukan blob HTML, melainkan struktur data yang hanya berisi elemen dan relasi yang diizinkan. Perubahan juga masuk melalui transaksi yang bisa diperiksa.

Structured blocks cocok ketika CMS membutuhkan:

• gambar dengan metadata yang konsisten;
• embed video atau media lain;
• CTA, produk, event, atau komponen bisnis;
• preview lintas kanal;
• validasi per tipe blok;
• migrasi dan transformasi konten yang terkontrol.

Biayanya lebih tinggi. Tim perlu schema, editor, renderer, migration strategy, dan fallback untuk tipe blok yang tidak dikenali. Jangan mengambil model ini hanya karena terdengar modern.

Cara memilih tanpa over-engineering

Gunakan pertanyaan operasional, bukan pertanyaan "editor mana yang paling keren".

Pilih plain text jika format memang tidak dibutuhkan

Judul, label, status, dan ringkasan satu paragraf tidak perlu rich text editor. Semakin sempit kontrak field, semakin mudah validasi dan reuse-nya.

Pilih Markdown jika konten utamanya tulisan

Untuk blog teknis, dokumentasi, knowledge base internal, atau content workflow berbasis repo, Markdown sering menjadi titik tengah yang sehat. Penulis mendapat heading, list, link, image, dan code block tanpa membawa schema editor yang besar.

Tetapkan dialect yang dipakai. Putuskan apakah raw HTML diizinkan, bagaimana tabel diproses, di mana aset disimpan, dan extension apa yang didukung. Jangan membiarkan setiap renderer memilih interpretasi sendiri.

Pilih structured blocks jika media dan komponen adalah bagian inti

Kalau penulis rutin menyisipkan video, galeri, CTA, FAQ, tabel harga, produk, atau komponen interaktif, structured blocks lebih jujur terhadap kebutuhan data.

Sebuah video, misalnya, sebaiknya disimpan sebagai provider dan ID. Dokumentasi resmi YouTube memakai pola URL embed https://www.youtube.com/embed/VIDEO_ID. Renderer dapat membentuk iframe dari data yang sudah divalidasi, membatasi provider, serta menetapkan parameter dan ukuran yang konsisten.

Pendekatan ini lebih aman daripada menerima iframe bebas dari editor. Ia juga memudahkan output alternatif. Data video yang sama dapat dirender sebagai player di web, thumbnail di email, dan link di aplikasi yang tidak mendukung embed.

Jangan campur source of truth

Satu kesalahan umum adalah menyimpan Markdown, HTML hasil render, dan JSON editor sebagai tiga versi yang semuanya dianggap benar.

Tentukan satu source of truth:

• Markdown jika Markdown adalah format authoring utama;
• structured JSON jika editor berbasis schema menjadi authoring utama;
• HTML hanya jika sistem memang memilih HTML sebagai format kanonik.

Output lain sebaiknya dianggap hasil transformasi yang dapat dibuat ulang atau cache yang bisa diinvalidate.

Misalnya, untuk Markdown:

source: article_markdown
hasil render/cache: article_html

Untuk structured blocks:

source: article_document_json
hasil render/cache: article_html

Simpan juga versi schema atau renderer bila migrasi lintas versi mungkin terjadi. Tanpa versioning, node lama bisa gagal dirender setelah tipe blok berubah.

Pipeline publish harus satu jalur

Masalah formatting sering muncul karena preview dan halaman publik memakai renderer berbeda. Editor terlihat benar, tetapi hasil live salah.

Pipeline yang lebih aman:

1. validasi source sesuai content model;
2. parse menjadi struktur yang diketahui;
3. tolak node, URL, atau atribut yang tidak diizinkan;
4. render melalui satu renderer resmi;
5. sanitasi HTML bila pipeline menghasilkan atau menerima HTML;
6. simpan atau cache output;
7. verifikasi respons API dan halaman publik.

Preview sebaiknya memanggil parser, sanitizer, dan renderer yang sama dengan production. Kalau preview memiliki implementasi sendiri, perbedaan kecil akan berubah menjadi bug yang sulit dilacak.

Migrasi dari textarea tanpa merusak konten lama

Tidak perlu mengganti seluruh CMS dalam satu sprint. Jalur bertahap lebih aman.

Audit isi yang sudah ada

Ambil sampel konten dan cari pola nyata:

• apakah **, ##, dan list sudah dipakai;
• apakah ada iframe atau HTML mentah;
• domain video apa saja yang muncul;
• apakah URL gambar punya alt text dan caption;
• format mana yang paling sering gagal di halaman publik.

Jangan memilih schema berdasarkan asumsi kalau database sudah punya bukti kebutuhan sebenarnya.

Tambahkan penanda format

Field seperti content_format dapat membedakan plain_text, markdown, html, dan blocks_v1. Renderer tidak perlu menebak dari isi string.

Menebak format dari keberadaan ** atau <p> terlihat praktis, tetapi rawan false positive. Tanda bintang bisa menjadi teks biasa. Tanda < bisa muncul dalam contoh kode.

Buat parser dan renderer per format

Konten lama tetap dirender lewat jalur lama. Konten baru memakai jalur yang sudah dipilih. Setelah QA cukup, migrasi lama dapat dilakukan batch demi batch dengan backup dan diff hasil render.

Tambahkan block baru hanya saat ada kebutuhan

Mulai dari paragraph, heading, list, link, image, dan video jika itu memang kebutuhan minimum. CTA, table, gallery, FAQ, atau embed provider lain bisa ditambahkan saat use case-nya nyata.

Schema yang terlalu luas dari awal hanya menciptakan lebih banyak komponen untuk diuji dan dipelihara.

Checklist keputusan sebelum implementasi

Sebelum mengganti editor, jawab pertanyaan berikut:

• Siapa yang menulis: developer, editor, client, atau publik?
• Apakah source perlu nyaman dibaca di Git?
• Apakah konten hanya artikel, atau juga memuat komponen bisnis?
• Embed apa yang benar-benar dibutuhkan?
• Apakah output harus dipakai di web, email, aplikasi, dan API?
• Siapa yang memegang schema migration?
• Parser dan sanitizer apa yang menjadi standar?
• Bagaimana preview memastikan hasilnya sama dengan production?
• Bagaimana konten lama dipertahankan jika migrasi gagal?
• Apa acceptance criteria halaman live?

Kesimpulan operasional

Textarea tidak bohong. Ia melakukan tugasnya sebagai input teks. Yang bermasalah adalah aplikasi yang memasukkan syntax dan media ke dalam string tanpa menetapkan kontrak konten.

Untuk field pendek, tetap gunakan plain text. Untuk artikel yang dominan tulisan dan workflow teknis, Markdown biasanya cukup. Untuk CMS yang media-rich dan banyak komponen bisnis, structured blocks memberi kontrak yang lebih kuat. Raw HTML hanya layak jika tim siap mengelola sanitasi dan konsistensinya.

Urutannya sederhana: pilih source of truth, tetapkan schema atau dialect, gunakan satu pipeline render, sanitasi pada boundary yang benar, lalu QA halaman publik. Editor dipilih setelah keputusan itu, bukan sebelumnya.