Gânduri despre Markdown

Markdown este a doua natură pentru mulți dintre noi. Privind în urmă, îmi amintesc că am început să scriu Markdown la scurt timp după ce John Gruber și-a lansat primul analizor bazat pe Perl în 2004, după ce a colaborat la limbaj cu Aaron Swartz.

Sintaxa lui Markdown este destinată unui singur scop: să fie folosită ca format de scriere pentru web.

— John Gruber

Asta a fost acum aproape 20 de ani - da! Ceea ce a început ca o sintaxă mai prietenoasă cu scriitorii și cititorii pentru HTML a devenit un drag pentru cum să scrieți și să stocați proză tehnică pentru programatori și oameni cunoscători de tehnologie.

Markdown este un semnificant pentru cultura dezvoltatorului și a textului. Dar de la introducerea sa, lumea conținutului digital s-a schimbat și ea. Deși Markdown este încă în regulă pentru unele lucruri, nu cred că ar trebui să mai fie punctul de plecare pentru conținut.

Există două motive principale pentru aceasta:

1. Markdown nu a fost conceput pentru a satisface nevoile actuale de conținut.
2. Markdown reține experiența editorială.

Desigur, această poziție este influențată de lucrul pentru o platformă pentru conținut structurat. La Sanity.io, ne petrecem cea mai mare parte a zilelor gândindu-ne la modul în care conținutul ca date deblochează multă valoare și petrecem mult timp gândindu-ne profund la experiențele editorului și la cum să economisim timp oamenilor și să facem lucrul cu conținut digital plăcut. . Deci, există piele în joc, dar sper că sunt capabil să descriu că, deși voi argumenta împotriva Markdown ca format de bază pentru conținut, încă am o apreciere profundă pentru semnificația, aplicarea și moștenirea acestuia.

Înainte de actualul meu concert, am lucrat ca consultant tehnologic la o agenție în care a trebuit să luptăm literalmente cu CMS-urile care blocau conținutul clientului nostru prin încorporarea acestuia în modele de prezentare și de date complexe (da, chiar și cele open-source). Am observat că oamenii se luptă cu sintaxa Markdown și sunt demotivați în slujbele lor de editori și creatori de conținut. Am cheltuit ore întregi (și banii clienților) pentru a construi etichete de redare personalizate care nu au fost niciodată folosite pentru că oamenii nu au timp sau motivație să folosească sintaxa. Chiar și eu, când sunt foarte motivat, am renunțat să contribui la documentația open-source, deoarece implementarea Markdown bazată pe componente a introdus prea multe fricțiuni.

Dar văd și cealaltă față a monedei. Markdown vine cu un ecosistem impresionant și, din punctul de vedere al dezvoltatorului, există o simplitate elegantă pentru fișierele text simplu și o sintaxă ușor de analizat pentru oamenii care sunt obișnuiți să citească cod. Odată am petrecut zile întregi construind un impresionant MultiMarkdown -> LaTeX -> real-time-PDF-preview-pipeline în Sublime Text pentru scrisul meu academic. Și are sens ca un fișier README.md să poată fi deschis și editat într-un editor de cod și redat frumos pe GitHub. Nu există nicio îndoială că Markdown aduce comoditate pentru dezvoltatori în unele cazuri de utilizare.

De aceea, vreau să-mi construiesc sfatul împotriva Markdown, privind înapoi la motivul pentru care a fost introdus în primul rând și parcurgând unele dintre evoluțiile majore ale conținutului de pe web. Pentru mulți dintre noi, bănuiesc că Markdown este ceva pe care pur și simplu luăm de la sine înțeles ca un „lucru care există”. Dar toată tehnologia are o istorie și este un produs al interacțiunii umane. Acest lucru este important de reținut când dvs., cititorul, dezvoltați tehnologie pe care să o utilizeze alții.

Arome și specificații

Markdown a fost conceput pentru a face mai ușor pentru scriitorii web să lucreze cu articole într-o epocă în care publicarea web necesita scrierea HTML. Deci, intenția a fost de a simplifica interfața cu formatarea textului în HTML. Nu a fost prima sintaxă simplificată de pe planetă, dar a fost cea care a câștigat cel mai mult de-a lungul anilor. Astăzi, utilizarea Markdown a crescut cu mult dincolo de intenția sa de proiectare pentru a fi o modalitate mai simplă de a citi și scrie HTML, pentru a deveni o abordare de marcare a textului simplu în multe contexte diferite. Sigur, tehnologiile și ideile pot evolua dincolo de intenția lor, dar tensiunea în utilizarea Markdown de astăzi poate fi urmărită la această origine și la constrângerile puse în designul său.

Pentru cei care nu sunt familiarizați cu sintaxa, luați următorul conținut HTML:

 <p>The <a href=”https://daringfireball.net/projects/markdown/syntax#philosophy”>Markdown syntax</a> is designed to be <em>easy-to-read</em> and <em>easy-to.write</em>.</p>

Cu Markdown, puteți exprima aceeași formatare ca:

 The [Markdown syntax](https://daringfireball.net/projects/markdown/syntax#philosophy) is designed to be _easy-to-read_ and _easy-to-write_.

Este ca o lege a naturii că adoptarea tehnologiei vine cu presiunea de a evolua și de a adăuga funcții. Popularitatea crescândă a lui Markdown a însemnat că oamenii au dorit să-l adapteze pentru cazurile lor de utilizare. Au vrut mai multe funcții, cum ar fi suport pentru note de subsol și tabele. Implementarea inițială a venit cu o poziție cu opinie, care la momentul respectiv era rezonabilă pentru intenția de proiectare:

Pentru orice marcaj care nu este acoperit de sintaxa Markdown, pur și simplu utilizați HTML în sine. Nu este nevoie să o prefațați sau să o delimitați pentru a indica faptul că treceți de la Markdown la HTML; folosești doar etichetele.

— John Gruber

Cu alte cuvinte, dacă doriți un tabel, atunci utilizați <table></table> . Veți descoperi că acesta este încă cazul pentru implementarea inițială. Unul dintre succesorii spirituali ai lui Markdown, MDX, a adoptat același principiu, dar l-a extins la JSX, un limbaj de șabloane bazat pe JS.

De la Markdown la Markdown?

Poate părea că atracția lui Markdown pentru mulți nu a fost atât legătura sa cu HTML, ci ergonomia textului simplu și sintaxa simplă pentru formatare. Unii creatori de conținut au dorit să folosească Markdown pentru alte cazuri de utilizare decât articolele simple de pe web. Implementări precum MultiMarkdown au introdus avantaje pentru scriitorii academicieni care doreau să folosească fișiere text simplu, dar aveau nevoie de mai multe funcții. În curând, veți avea o gamă de aplicații de scriere care acceptau sintaxa Markdown, fără a o transforma neapărat în HTML sau chiar să folosiți sintaxa Markdown ca format de stocare.

În multe aplicații, veți găsi editori care vă oferă un set limitat de opțiuni de formatare, iar unele dintre ele sunt mai „inspirate” de sintaxa originală. De fapt, unul dintre feedback-urile pe care le-am primit cu privire la o versiune nefinalizată a acestui articol a fost că, până acum, „Markdown” ar trebui să fie cu litere mici, deoarece a devenit atât de comun, și pentru a-l face distinct de implementarea inițială. Pentru că ceea ce recunoaștem drept reducere a devenit, de asemenea, foarte divers.

CommonMark: O încercare de a îmblânzi Markdown

Ca și înghețata, Markdown vine în o mulțime de arome, unele mai populare decât altele. Când oamenii au început să schimbe implementarea originală și să-i adauge funcții, s-au întâmplat două lucruri:

1. A devenit mai imprevizibil ceea ce tu, ca scriitor, ai putea și nu ai putut face cu Markdown.
2. Dezvoltatorii de software au trebuit să ia decizii cu privire la ce implementare să adopte pentru software-ul lor. Implementarea inițială conținea, de asemenea, unele inconsecvențe care adăugau fricțiuni pentru persoanele care doreau să o folosească în mod programatic.

Acest lucru a început conversații despre oficializarea Markdown într-o specificație propriu-zisă. Ceva la care Gruber a rezistat și încă îl face, interesant, pentru că a recunoscut că oamenii doreau să folosească Markdown în scopuri diferite și „Nimeni sintaxa nu i-ar face pe toți fericiți”. Este o poziție interesantă având în vedere că Markdown se traduce în HTML, care este o specificație care evoluează pentru a se potrivi diferitelor nevoi.

Chiar dacă implementarea inițială a Markdown este acoperită de o licență „asemănătoare BSD”, se mai spune „Nici numele Markdown și nici numele colaboratorilor săi nu pot fi folosite pentru a susține sau promova produse derivate din acest software fără permisiunea scrisă prealabilă specifică. ” Putem presupune cu siguranță că majoritatea produselor care folosesc „Markdown” ca parte a materialelor lor de marketing nu au obținut această permisiune scrisă.

Cea mai reușită încercare de a aduce Markdown într-o specificație comună este ceea ce astăzi este cunoscut sub numele de CommonMark. A fost condus de Jeff Atwood (cunoscut pentru co-fondatorul Stack Overflow and Discourse) și John McFarlane (profesor de filozofie la Berkely, care este în spatele Babelmark și pandoc). L-au lansat inițial ca „Standard Markdown”, dar l-au schimbat în „CommonMark” după ce au primit critici de la Gruber. A cărui poziție a fost consecventă, intenția lui Markdown este de a fi o simplă sintaxă de autor care se traduce în HTML:

@davewiner Și asta este defectul cu CommonMark. Ei vor să ușureze lucrurile pentru programatori ca obiectiv principal. Ei ratează ideea.

— John Gruber (@gruber) 8 septembrie 2014

Cred că acest lucru a marcat și punctul în care Markdown a intrat în domeniul public. Chiar dacă CommonMark nu este marcat ca „Markdown”, (conform licenței) această specificație este recunoscută și denumită „markdown”. Astăzi, veți găsi CommonMark ca implementare de bază pentru software precum Discourse, GitHub, GitLab, Reddit, Qt, Stack Overflow și Swift. Proiecte precum unified.js sintaxele prin traducerea lor în arbori de sintaxă abstractă, de asemenea, se bazează pe CommonMark pentru suportul lor de reducere.

CommonMark a adus multă unificare în ceea ce privește modul de implementare a reducerii și, în multe feluri, a simplificat pentru programatori să integreze suportul pentru reduceri în software. Dar nu a adus aceeași unificare a modului în care este scris și utilizat markdown-ul. Luați GitHub Flavoured Markdown (GFM). Se bazează pe CommonMark, dar îl extinde cu mai multe funcții (cum ar fi tabele, liste de sarcini și baraj). Reddit descrie „Reddit Flavored Markdown” ca „o variație a GFM” și introduce caracteristici precum sintaxa pentru marcarea spoilerelor. Cred că putem concluziona cu siguranță că atât grupul din spatele CommonMark, cât și Gruber au avut dreptate: cu siguranță ajută cu specificațiile partajate, dar da, oamenii vor să folosească Markdown pentru diferite lucruri specifice.

Markdown ca o comandă rapidă de formatare

Gruber s-a opus oficializării Markdown într-o specificație partajată, deoarece a presupus că ar face din acesta mai puțin un instrument pentru scriitori și mai mult un instrument pentru programatori. Am văzut deja că, chiar și cu adoptarea pe scară largă a unei specificații, nu obținem automat o sintaxă care să funcționeze la fel în diferite contexte. Și specificații precum CommonMark, oricât de populare sunt, au, de asemenea, un succes limitat. Un exemplu evident este implementarea markdown de la Slack (numită mrkdown ) care se traduce *this* în puternic/aldin, și nu accent/italic și nu acceptă sintaxa [link](https://slack.com) , dar folosește <link|https://slack.com> în schimb.

Veți descoperi, de asemenea, că puteți utiliza sintaxa de tip Markdown pentru a inițializa formatarea în editorii de text îmbogățit în software precum Notion, Dropbox Paper, Craft și, într-o anumită măsură, Google Docs (de exemplu, asterisk + space pe o linie nouă se vor transforma într-un listă cu puncte). Ce este susținut și ce este tradus în ceea ce variază. Deci, nu vă puteți lua neapărat memoria musculară cu dvs. în aceste aplicații. Pentru unii oameni, acest lucru este bine și se pot adapta. Pentru alții, aceasta este o tăiere pe hârtie și îi împiedică să folosească aceste caracteristici. Care pune întrebarea pentru cine a fost conceput Markdown și cine sunt utilizatorii săi astăzi?

Cine ar trebui să fie utilizatorii Markdown?

Am văzut că markdown-ul există într-o tensiune între diferite cazuri de utilizare, audiențe și noțiuni despre cine sunt utilizatorii săi. Ceea ce a început ca un limbaj de marcare pentru scriitorii web pricepuți în HTML, a devenit un dragut pentru tipurile de dezvoltatori.

În 2014, scriitorii web au început să se îndepărteze de la mutarea fișierelor prin analizoare în Perl și FTP. Sistemele de management al conținutului (CMS) precum WordPress, Drupal și Moveable Type (pe care cred că Gruber încă le folosește) au crescut constant pentru a deveni instrumentele de bază pentru publicarea web. Au oferit avantaje precum editorii de text bogat pe care scriitorii web le puteau folosi în browserele lor.

Acești editori de text îmbogățit au presupus în continuare HTML și Markdown drept sintaxa de bază a textului îmbogățit, dar au eliminat o parte din suprasarcina cognitivă prin adăugarea de butoane pentru a insera această sintaxă în editor. Și din ce în ce mai mult, scriitorii nu erau și nu trebuiau să fie versați în HTML. Pun pariu că dacă ai făcut dezvoltare web cu CMS-uri în anii 2010, probabil că ai avut de-a face cu „HTML nedorit” care a venit prin aceste editori când oamenii au lipit direct din Word.

Astăzi, voi argumenta că utilizatorii principali ai Markdown sunt dezvoltatorii și oamenii care sunt interesați de cod. Nu este o coincidență că Slack a făcut din WYSIWYG modul de intrare implicit, odată ce software-ul lor a fost folosit de mai multe persoane din afara departamentelor tehnice. Iar faptul că aceasta a fost o decizie controversată, atât de mult încât au fost nevoiți să o aducă înapoi ca opțiune, arată cât de adâncă este dragostea pentru markdown în comunitatea dezvoltatorilor. Nu s-a sărbătorit prea mult ca Slack să încerce să-l facă mai ușor și mai accesibil pentru toată lumea. Și acesta este miezul problemei.

Ideologia lui Markdown

Faptul că markdown-ul a devenit stilul de scriere lingua franca și ceea ce se referă la majoritatea cadrelor de site-uri web, este, de asemenea, principalul motiv pentru care am fost puțin supărat în ceea ce privește publicarea acestui lucru. Deseori se vorbește despre el ca pe un bun inerent și de netăgăduit. Markdown a devenit un semn distinctiv pentru a fi prietenos cu dezvoltatorii. Oamenii inteligenți și pricepuți au investit o mulțime de ore colective pentru a permite reducerea în tot felul de contexte. Așadar, contestarea hegemoniei acesteia îi va enerva cu siguranță pe unii. Dar, sperăm, poate genera o discuție fructuoasă despre un lucru care este adesea considerat de la sine înțeles.

Impresia mea este că amabilitatea dezvoltatorilor pe care oamenii o relaționează cu Markdown are de-a face în principal cu 3 factori:

1. Abstracția confortabilă a unui fișier text simplu.
2. Există un ecosistem de scule.
3. Vă puteți păstra conținutul aproape de fluxul de lucru de dezvoltare.

Nu spun că aceste poziții sunt greșite, dar voi sugera că vin cu compromisuri și unele presupuneri nerezonabile.

Modelul mental simplu al unui fișier text simplu

Bazele de date sunt lucruri uimitoare. Dar au avut și o reputație câștigată de a fi greu și inaccesibil pentru dezvoltatorii de front-end. Am cunoscut o mulțime de dezvoltatori grozavi care se feresc de codul backend și bazele de date, deoarece reprezintă o complexitate pe care nu vor să-și petreacă timpul. Chiar și cu WordPress, care face foarte mult din cutie pentru a vă împiedica să aveți de-a face cu baza sa de date după configurare, a fost suprasolicitarea pornirii.

Cu toate acestea, fișierele text simplu sunt mai tangibile și sunt destul de simplu de raționat (atâta timp cât sunteți obișnuit cu gestionarea fișierelor). Mai ales în comparație cu un sistem care vă va împărți conținutul în mai multe tabele într-o bază de date relațională cu o structură proprie. Pentru cazurile de utilizare limitate, cum ar fi postările de blog cu text îmbogățit simplu, cu imagini și linkuri, markdown-ul va face treaba. Puteți copia fișierul și îl puteți lipi într-un folder sau îl puteți verifica în git. Conținutul este al tău din cauza tangibilității fișierelor. Chiar dacă sunt găzduiți pe GitHub, care este un software ca serviciu cu scop profit deținut de Microsoft și, prin urmare, acoperit de termenii și condițiile lor.

În epoca în care a trebuit de fapt să creați o bază de date locală pentru a începe dezvoltarea locală și pentru a vă ocupa de sincronizarea acesteia cu telecomandă, atractia fișierelor text simplu este de înțeles. Dar acea eră a dispărut aproape odată cu apariția backend-urilor ca serviciu. Servicii și instrumente precum Fauna, Firestore, Hasura, Prisma, PlanetScale și Sanity's Content Lake, investesc mult în experiența dezvoltatorilor. Chiar și operarea bazelor de date tradiționale privind dezvoltarea locală a devenit mai puțin complicată în comparație cu doar 10 ani în urmă.

Dacă te gândești bine, deții mai puțin conținutul tău dacă este găzduit într-o bază de date? Și experiența dezvoltatorilor de a trata bazele de date nu a devenit semnificativ mai simplă odată cu apariția instrumentelor SaaS? Și este corect să spunem că tehnologia proprietății baze de date afectează portabilitatea conținutului tău? Astăzi, puteți lansa ceea ce este în esență o bază de date Postgres fără abilități de administrator de sistem, puteți să vă creați tabelele și coloanele, să vă puneți conținutul în ea și, în orice moment, să îl exportați ca un dump .sql .

Portabilitatea conținutului are mult mai mult de-a face cu modul în care structurați acel conținut în primul rând. Luați WordPress, este complet open-source, vă puteți găzdui propria DB. Are chiar și un format de export standardizat în XML. Dar oricine a încercat să iasă dintr-o instalare WordPress matură știe cât de puțin ajută acest lucru dacă încerci să scapi de WordPress.

Un ecosistem vast... Pentru dezvoltatori

Am atins deja vastul ecosistem de reduceri. Dacă te uiți la cadrele web contemporane, majoritatea dintre ele presupun markdown ca format de conținut principal, unele dintre ele, singurul format. De exemplu, Hugo, generatorul de site-uri static folosit de Smashing Magazine, încă mai necesită fișiere de markdown pentru publicarea paginată. Înseamnă că, dacă Smashing Magazine dorește să folosească un CMS pentru a stoca articole, trebuie să interacționeze cu fișierele markdown sau să convertească tot conținutul în fișiere markdown. Dacă te uiți în documentația pentru Next.js, Nuxt.js, VuePress, Gatsby.js și așa mai departe, markdown-ul va fi vizibil. Este, de asemenea, sintaxa implicită pentru fișierele README de pe GitHub, care o folosește și pentru formatarea în notele și comentariile Pull Request.

Există câteva mențiuni onorabile ale inițiativelor pentru a aduce ergonomia reducerii în masă. Netlify CMS și TinaCMS (descendentul spiritual al Forestry) vă vor oferi interfețe cu utilizatorul în care sintaxa de reducere este în mare parte abstrasă pentru editori. În mod obișnuit, veți descoperi că editorii bazați pe markdown din CMS vă oferă funcționalitate de previzualizare pentru formatare. Unii editori, cum ar fi cei de la Notion, vă vor permite să lipiți sintaxa markdown și o vor traduce în formatarea lor nativă. Dar cred că este sigur să spun că energia care s-a îndreptat spre inovare pentru markdown nu i-a favorizat pe cei care nu doresc să-i scrie sintaxa. Nu s-a scurs în stiva, așa cum ar fi.

Fluxuri de lucru de conținut sau fluxuri de lucru pentru dezvoltatori?

Pentru un dezvoltator care își creează blogul, folosirea fișierelor de reducere reduce o parte din cheltuielile generale legate de pornirea acestuia și de funcționare, deoarece cadrele vin adesea cu analizare încorporată sau îl oferă de obicei ca parte a codului de pornire. Și nu este nimic suplimentar la care să vă înscrieți. Puteți folosi git pentru a comite aceste fișiere alături de codul dvs. Dacă vă simțiți confortabil cu git diffs, veți avea chiar și controlul reviziilor așa cum v-ați obișnuit cu programarea. Cu alte cuvinte, deoarece fișierele markdown sunt în text simplu, ele pot fi integrate cu fluxul de lucru pentru dezvoltatori.

Dar dincolo de aceasta, experiența dezvoltatorului devine în curând mai complexă. Și ajungeți să compromiteți experiența utilizatorului echipei dvs. în calitate de creatori de conținut, iar propria noastră experiență de dezvoltator este blocată cu reduceri pentru a rezolva probleme care depășesc cu mult intenția sa de proiectare.

Da, ar putea fi grozav dacă îi convingi pe echipa ta de conținut să folosească git și să verifice modificările lor, dar, în același timp, este aceasta cea mai bună utilizare a timpului lor? Chiar vrei ca editorii tăi să se lovească de conflictele de îmbinare sau cum să rebazeze ramurile? Git este suficient de greu pentru dezvoltatorii care îl folosesc în fiecare zi. Și această configurație reprezintă într-adevăr cel mai bun flux de lucru pentru oamenii care lucrează în principal cu conținut? Nu este acesta un caz în care experiența dezvoltatorului a depășit experiența editorului și nu este costul, timpul și efortul care ar putea face ceva mai bun pentru utilizatori?

Deoarece așteptările și nevoile din mediile de conținut și de editare au evoluat, nu cred că markdown va face acest lucru pentru noi. Nu văd cum unele dintre ergonomiile dezvoltatorilor ajung să-i favorizeze pe non-dezvoltatori și cred că chiar și pentru dezvoltatori, markdown-ul împiedică crearea de conținut și nevoile noastre. Pentru că conținutul de pe web s-a schimbat semnificativ de la începutul anilor 2000.

De la Paragrafe La Blocuri

Markdown a avut întotdeauna opțiunea de a renunța la HTML dacă doriți lucruri mai complexe. Acest lucru a funcționat bine când autorul era și webmaster, sau cel puțin cunoștea HTML. De asemenea, a funcționat bine, deoarece site-urile web erau de obicei HTML și CSS. Modul în care ați proiectat site-urile web a fost în principal prin crearea unor aspecte întregi de pagină. Puteți transforma Markdown în marcajul HTML și îl puteți pune alături de fișierul style.css . Desigur, am avut CMS-uri și generatoare de site-uri statice și în anii 2000, dar în cea mai mare parte au funcționat la fel, prin inserarea conținutului HTML în interiorul șabloanelor fără nicio trecere de „recuzite” între componente.

Dar cei mai mulți dintre noi nu mai scriem HTML ca pe vremuri. Conținutul de pe web a evoluat de la a fi în mare parte articole cu formatare simplă de text îmbogățit la componente multimedia compuse și specializate, adesea cu interactivitate cu utilizatorul (care este un mod elegant de a spune „îndemnul de înscriere la buletin informativ”).

De la articole la aplicații

La începutul anilor 2010, Web 2.0 a fost în perioada sa de glorie, iar companiile Software as a Service au început să folosească web-ul pentru aplicații cu volum mare de date. HTML, CSS și JavaScript au fost din ce în ce mai folosite pentru a conduce interfețe interactive. Twitter cu sursă deschisă Bootstrap, cadrul lor pentru construirea de interfețe de utilizator mai consistente și mai rezistente. Acest lucru a condus ceea ce putem numi „componentizarea” designului web. A schimbat modul în care construim pentru web într-un mod fundamental.

Diferitele cadre CSS care au apărut în această eră (de exemplu, Bootstrap și Foundation) au avut tendința de a utiliza nume de clase standardizate și au presupus structuri HTML specifice pentru a face mai puțin dificilă realizarea de interfețe de utilizator rezistente și receptive. Cu filozofia de design web a Atomic Design și convențiile de nume de clasă, cum ar fi Block-Element-Modifier (BEM), implicit a fost schimbat de la gândirea mai întâi a aspectului paginii, la a vedea paginile ca o colecție de elemente de design repetabile și compatibile.

Indiferent de conținut pe care îl aveți în cadrul markdown-ului, nu este compatibil cu acesta. Cu excepția cazului în care ați coborât în ​​gaura iepurelui de a interjecta parserele de reducere și l-ați ajustat pentru a scoate sintaxa dorită (mai multe despre asta mai târziu). Nu e de mirare, Markdown a fost conceput pentru a fi articole simple cu text îmbogățit cu elemente HTML native pe care le-ai viza cu o foaie de stil.

Aceasta este încă o problemă pentru persoanele care folosesc Markdown pentru a genera conținut pentru site-urile lor.

Web-ul încorporabil

Dar ceva s-a întâmplat și cu conținutul nostru. Nu numai că am putea începe să-l găsim în afara etichetelor HTML semantice <article> , dar a început să conțină mai multe... lucruri. O mare parte din conținutul nostru a fost mutat din LiveJournals și bloguri și în rețelele sociale: Facebook, Twitter, tumblr, YouTube. Pentru a reintroduce fragmentele de conținut în articolele noastre, trebuia să le putem încorpora. Convenția HTML a început să folosească eticheta <iframe> pentru a canaliza playerul video de pe YouTube sau chiar pentru a introduce o casetă de tweet între paragrafele dvs. de text. Unele sisteme au început să abstractizeze acest lucru în „coduri scurte”, cel mai adesea paranteze care conțin un cuvânt cheie pentru a identifica ce bloc de conținut ar trebui să reprezinte și unele atribute cheie-valoare. De exemplu, dev.to a activat sintaxa din lichidul limbajului de șablon pentru a fi inserată în editorul Markdown:

 {% youtube dQw4w9WgXcQ %}

Desigur, acest lucru necesită să utilizați un parser Markdown personalizat și să aveți o logică specială pentru a vă asigura că HTML-ul potrivit a fost inserat atunci când sintaxa a fost transformată în HTML. Iar creatorii tăi de conținut vor trebui să-și amintească aceste coduri (cu excepția cazului în care exista un fel de bară de instrumente pentru a le insera automat). Și dacă un parantez este șters sau încurcat, acest lucru ar putea distruge site-ul.

Dar ce zici de MDX?

O încercare de a rezolva nevoia de conținut bloc este MDX, prezentat cu sloganul „Markdown pentru era componentelor”. MDX vă permite să utilizați limbajul de șabloane JSX, precum și JavaScript, intercalate în sintaxa markdown. Există o mulțime de inginerie impresionantă în comunitatea din jurul MDX, inclusiv Unified.js , care este specializată în analizarea diferitelor sintaxe în arbori de sintaxă abstractă (AST), astfel încât acestea să fie mai accesibile pentru a fi utilizate programatic. Rețineți că standardizarea markdown-ului ar simplifica munca celor din spatele Unified.js și a utilizatorilor săi, deoarece există mai puține cazuri marginale de care să se ocupe.

MDX aduce cu siguranță o experiență mai bună pentru dezvoltatori în integrarea componentelor în Markdown. Dar nu aduce o experiență mai bună a editorului, deoarece adaugă multă suprasarcină cognitivă producției și editării conținutului:

 import {Chart} from './snowfall.js' export const year = 2018 # Last year's snowfall In {year}, the snowfall was above average. It was followed by a warm spring which caused flood conditions in many of the nearby rivers. <Chart year={year} color="#fcb32c" />

Cantitatea de cunoștințe presupuse doar pentru acest exemplu simplu este substanțială. Trebuie să știți despre modulele ES6, variabilele JavaScript, sintaxa șablonului JSX și cum să utilizați elementele de recuzită, codurile hexadecimale și tipurile de date și trebuie să fiți familiarizat cu componentele pe care le puteți utiliza și cum să le utilizați. Și trebuie să-l tastați corect și într-un mediu care vă oferă un fel de feedback. Nu am nicio îndoială că vor exista instrumente de autor mai accesibile pe deasupra MDX, se simte ca și cum ai rezolva ceva care nu trebuie să fie o problemă în primul rând.

Cu excepția cazului în care sunteți extrem de diligent în modul în care compuneți și numiți componentele dvs. MDX, acesta vă leagă și conținutul de o anumită prezentare. Luați exemplul de mai sus adus de pe prima pagină a MDX. Veți găsi un cod hexagonal de culoare hard-coded pentru diagramă. Când vă reproiectați site-ul, este posibil ca culoarea respectivă să nu fie compatibilă cu noul dvs. sistem de design. Desigur, nimic nu vă împiedică să abstrageți acest lucru și să utilizați color=”primary” , dar nu există nici nimic în instrument care vă determină să luați decizii înțelepte ca aceasta.

Încorporarea preocupărilor specifice de prezentare în conținutul dvs. a devenit din ce în ce mai mult o responsabilitate și ceva care va împiedica adaptarea, iterația și mutarea rapidă a conținutului dvs. Îl blochează în moduri care sunt mult mai subtile decât a avea conținut într-o bază de date. Riscați să ajungeți în același loc cu mutarea dintr-o instalare WordPress matură cu pluginuri. Este greoi să nu amestecați structura și prezentarea.

Cererea de conținut structurat

Cu site-uri și călătorii ale utilizatorilor mai complexe, vedem, de asemenea, nevoia de a prezenta aceleași piese de conținut pe un site web. Dacă rulați un site de comerț electronic, doriți să încorporați informații despre produs în mai multe locuri în afara unei singure pagini de produs. Dacă conduceți un site de marketing modern, doriți să puteți partaja aceeași copie în mai multe vizualizări personalizate.

Pentru a face acest lucru eficient și fiabil, va trebui să adaptați conținutul structurat. Aceasta înseamnă că conținutul dvs. trebuie să fie încorporat cu metadate și împărțit în moduri care să facă posibilă analizarea pentru intenție. Dacă un dezvoltator vede doar „pagina” cu „conținut”, aceasta face foarte dificilă includerea lucrurilor potrivite în locurile potrivite. Dacă pot ajunge la toate „descrierile produselor” cu un API sau o interogare, asta face totul mai ușor.

Cu markdown, sunteți limitat la exprimarea taxonomiilor și a conținutului structurat fie într-un fel de organizare de foldere (făcând dificilă introducerea aceleiași piese de conținut în mai multe taxonomii), fie trebuie să măriți sintaxa cu altceva.

Jekyll, un generator de site static (SSG) timpuriu construit pentru fișierele de reducere, a introdus „Front Matter” ca o modalitate de a adăuga metadate la postări folosind YAML (un format cheie-valoare simplu care folosește spații pentru a crea domeniul de aplicare) între trei liniuțe în partea de sus a dosarului. Deci, acum veți avea două sintaxe de rezolvat. YAML are și reputația de a fi răutăcios (mai ales dacă ești din Norvegia). Cu toate acestea, alte SSG-uri au adoptat această convenție, precum și CMS-uri bazate pe git care folosesc markdown ca format de conținut.

Când trebuie să adăugați o sintaxă suplimentară fișierelor simple pentru a obține unele dintre avantajele conținutului structurat, s-ar putea să începeți să vă întrebați dacă merită cu adevărat. Și pentru cine este formatul și pe cine exclude.

Dacă te gândești bine, multe din ceea ce facem pe web nu consumă doar conținut, ci îl creăm! În prezent, scriu acest articol lung într-un procesor de text avansat în browserul meu.

Există o așteptare tot mai mare că ar trebui să puteți, de asemenea, să creați conținut blocat în aplicațiile de conținut moderne. Oamenii au început să se obișnuiască cu experiențe de utilizator încântătoare, care funcționează și arată frumos și în care nu trebuie să înveți sintaxă specializată. Medium a popularizat ideea că ați putea crea conținut încântător și intuitiv pe web. Și vorbind despre „noțiune”, populara aplicație de note a folosit conținutul bloc și le permite utilizatorilor să amestece maxim dintr-o gamă largă de tipuri diferite. Cele mai multe dintre aceste blocuri depășesc markdown-ul și elementele native ale HTML.

Este de remarcat faptul că Notion, care descrie procesul lor de a-și face conținutul accesibil prin intermediul API-ului foarte anticipat, remarcă în alegerea formatului de conținut, că:

Documentele dintr-un editor Markdown vor analiza și reda adesea diferit într-o altă aplicație. Incoerența tinde să fie gestionabilă pentru documente simple, dar este o mare problemă pentru biblioteca bogată de blocuri și opțiuni de formatare inline a Notion, dintre care multe pur și simplu nu sunt acceptate în nicio implementare Markdown utilizată pe scară largă.

Noțiunea a mers cu un format bazat pe JSON, care le permite să se exprime ca date structurate. Argumentul lor este că face mai ușor și mai previzibil interacțiunea cu dezvoltatorii care doresc să-și construiască propria prezentare a conținutului bloc care iese din API-urile Notion.

Dacă nu Markdown, atunci ce?

Bănuiesc că proeminența Markdown a împiedicat inovația și progresul pentru conținutul digital. Așadar, când susțin că ar trebui să încetăm să-l alegem ca modalitate principală de stocare a conținutului, este greu să dăm un răspuns clar la ce ar trebui să-l înlocuiască. Ceea ce știm, totuși, este la ce ar trebui să ne așteptăm de la formatele de conținut moderne și instrumentele de creație.

Să investim în experiențe de autor accesibile

Utilizarea markdown-ului necesită să înveți sintaxa și, adesea, mai multe sintaxe și etichete personalizate pentru a fi practic cu așteptările moderne. Astăzi, asta pare o așteptare complet inutilă pentru majoritatea oamenilor. Mi-aș dori să putem îndrepta mai multă energie pentru a face experiențe editoriale accesibile și încântătoare, care să producă formate moderne de conținut portabil.

Chiar dacă este notoriu de dificil să construiești editori grozavi de conținut în bloc, există câteva opțiuni viabile care pot fi extinse și personalizate pentru cazul tău de utilizare (de exemplu Slate.js, Quill.js sau Prosemirror). Apoi, din nou, investițiile în comunitățile din jurul acestor instrumente ar putea ajuta, de asemenea, dezvoltarea lor în continuare.

Din ce în ce mai mult, oamenii se vor aștepta ca instrumentele de creație să fie accesibile, în timp real și colaborative. De ce ar trebui să apăsați un buton de salvare pe web în 2021? De ce nu ar fi posibil să faci o modificare într-un document fără a risca o condiție de cursă, pentru că colegul tău s-a întâmplat să aibă documentul deschis într-o filă? Ar trebui să ne așteptăm ca autorii să aibă de-a face cu conflictele de îmbinare? Și nu ar trebui să le facilităm creatorilor de conținut să lucreze cu conținut structurat cu posibilități vizuale care au sens?

Pentru a fi puțin polemic: inovațiile din ultimul deceniu în cadrele JavaScript reactive și componentele UI sunt perfecte pentru crearea unor instrumente de creație extraordinare. În loc să le folosiți pentru a transpila Markdown în HTML și într-un arbore de sintaxă abstractă pentru a-l integra apoi într-un limbaj de șablon JavaScript care scoate HTML.

Blocarea conținutului ar trebui să respecte o specificație

Nu am menționat editorii WYSIWYG pentru HTML. Pentru că sunt un lucru greșit. Editorii moderni de conținut în bloc ar trebui să interacționeze de preferință cu un format specificat. Editorii menționați mai sus au cel puțin un model de document intern sensibil care poate fi transformat în ceva mai portabil. If you look at the content management system landscape, you start to see various JSON-based block content formats emerge. Some of them are still tied to HTML assumptions or overly concerned with character positions. And none of them aren't really offered as a generic specification.

At Sanity.io, we decided early that the block content format should never assume HTML as neither input nor output, and that we could use algorithms to synchronize text strings. More importantly, was it that block content and rich text should be deeply typed and queryable. The result was the open specification Portable Text. Its structure not only makes it flexible enough to accommodate custom data structures as blocks and inline spans; it's also fully queryable with open-source query languages like GROQ.

Portable Text isn't design to be written or be easily readable in its raw form; it's designed to be produced by an user interface, manipulated by code, and to be serialized and rendered where ever it needs to go. For example, you can use it to express content for voice assistants.

 { "style": "normal", "_type": "block", "children": [ { "_type": "span", "marks": ["a-key", "emphasis"], "text": "some text" } ], "markDefs": [ { "_key": "a-key", "_type": "markType", "extraData": "some data" } ] }

An interesting side-effect of turning block content into structured data is exactly that: It becomes data! And data can be queried and processed. That can be highly useful and practical, and it lets you ask your content repository questions that would be otherwise harder and more errorprone in formats like Markdown.

For example, if I for some reason wanted to know what programming languages we've covered in examples on Sanity's blog, that's within reach with a short query. You can imagine how trivial it is to build specialized tools and views on top of this that can be helpful for content editors:

 distinct( *["code" in body[]._type] .body[_type == "code"] .language ) // output [ "text", "javascript", "json", "html", "markdown", "sh", "groq", "jsx", "bash", "css", "typescript", "tsx", "scss" ]

Example: Get a distinct list of all programming languages that you have code blocks of.

Portable Text is also serializable, meaning that you can recursively loop through it, and make an API that exposes its nodes in callback functions mapped to block types, marked-up spans, and so on. We have spent the last years learning a lot about how it works and how it can be improved, and plan to take it to 1.0 in the near future. The next step is to offer an editor experience outside of Sanity Studio. As we have learned from Markdown, the design intent is important.

Of course, whatever the alternative to markdown is, it doesn't need to be Portable Text, but it needs to be portable text. And it needs to share a lot of its characteristics. There have been a couple of other JSON-based block content format popping up the last few years, but a lot of them seem to bring with them a lot of “HTMLism.” The convenience is understandable, since a lot of content still ends up on the web serialized into HTML, but the convenience limits the portability and the potential for reuse.

You can disregard my short pitch for something we made at Sanity, as long as you embrace the idea of structured content and formats that let you move between systems in a fundamental manner. For example, a goal for Portable Text will be improved compatibility with Unified.js, so it's easier to travel between formats.

Embracing The Legacy Of Markdown

Markdown în toate aromele, interpretările și furculițele sale nu va dispărea. I suspect that plain text files will always have a place in developers' note apps, blogs, docs, and digital gardens. As a writer who has used markdown for almost two decades, I've become accustomed to “markdown shortcuts” that are available in many rich text editors and am frequently stumped from Google Docs' lack of markdownisms. But I'm not sure if the next generation of content creators and even developers will be as bought in on markdown, and nor should they have to be.

I also think that markdown captured a culture of savvy tinkerers who love text, markup, and automation. I'd love to see that creative energy expand and move into collectively figuring out how we can make better and more accessible block content editors, and building out an ecosystem around specifications that can express block content that's agnostic to HTML. Structured data formats for block content might not have the same plain text ergonomics, but they are highly “tinkerable” and open for a lot of creativity of expression and authoring.

If you are a developer, product owner, or a decision-maker, I really want you to be circumspect of how you want to store and format your content going forward. If you're going for markdown, at least consider the following trade-offs:

Markdown is not great for the developer experience in modern stacks :

• It can be a hassle to parse and validate, even with great tooling.
• Even if you adopt CommonMark, you aren't guaranteed compatibility with tooling or people's expectations.
• It's not great for structured content, YAML frontmatter only takes you so far.

Markdown is not great for editorial experience :

• Most content creators don't want to learn syntax, their time is better spent on other things.
• Most markdown systems are brittle, especially when people get syntax wrong (which they will).
• It's hard to accommodate great collaborative user experiences for block content on top of markdown.

Markdown is not great in block content age , and shouldn't be forced into it. Block content needs to:

• Be untangled from HTMLisms and presentation agnostic.
• Accommodate structured content, so it can be easily used wherever it needs to be used.
• Have stable specification(s), so it's possible to build on.
• Support real-time collaborative systems.

What's common for people like me who challenge the prevalence of markdown, and those who are really into the simple way of expressing text formating is an appreciation of how we transcribe intent into code. That's where I think we can all meet. But I do think it's time to look at the landscape and the emerging content formats that try to encompass modern needs, and ask how we can make sure that we build something that truly caters to editorial experience, and that can speak to developer experience as well.

I want to express my gratitude to Titus Wormer (@wooorm) for his insightful feedback on my first draft of this post, and for the great work he and the Unified.js team have done for the web community.