Da un paio di anni a questa parte utilizzo Markdown per appuntarmi idee che poi spesso finiscono in un mio post da qualche parte, come ad esempio qui, su Inchiostro Virtuale.
Cos’è il Markdown, e perché ho scelto proprio questo linguaggio di editing?
Non so se avete presente l’html, quella roba infarcita di cose tipo:
ecco due parole scritte <b>in grassetto</b>
in cui due tag delimitano le parole da visualizzare in grassetto sul web (b sta per bold).
Bene, Markdown consente di raggiungere lo stesso scopo in un modo molto più leggibile e veloce, così:
ecco due parole scritte **in grassetto**
per poi tradurre in html per il web.
In questo caso, tra l’altro, utilizza i moderni tag <strong> e </strong> per aprire e chiudere il grassetto, al posto degli storici <b> e </b>.
Il risultato, sia per l’html che per il Markdown, è questo:
ecco due parole scritte in grassetto
Un solo asterisco (*così*) avrebbe reso il testo incluso come corsivo.
Altro esempio. Per inserire un titolo con il linguaggio Markdown, scrivo semplicemente:
#### Questo è un titolo
Invece dell’html:
<h4>Questo è un titolo</h4>
Il vantaggio è che, mentre annoto le mie idee sull’editor, magari con lo smartphone come sto facendo in questo momento, posso già inserire la formattazione base del testo, come titoli, corsivo, grassetto, liste, link. Il tutto senza litigare con <, >, slash e compagnia varia, e lasciando il testo perfettamente leggibile anche nell’editor.
Un’idea simile è stata realizzata recentemente da Whatsapp, che consente di inserire testo in grassetto (*ciao*), corsivo (_ciao_) o barrato (~ciao~).
Il linguaggio è nato nel 2004 da un’idea di John Gruber, blogger e sviluppatore web, e Aaron Swartz, sfortunato contributore al successo di Reddit.
Ha poi avuto una vita turbolenta, con proliferazione di dialetti, nascita di editor non del tutto compatibili tra di loro, conflittualità.
Alla base della Babele c’è l’assenza iniziale di una specifica formale. Ciò non ne impedisce l’utilizzo pratico, basta scegliersi un editor e seguire le sue regole.
Può però risultare complicato il caso in cui si scriva con un editor e poi se ne utilizzi uno diverso per tradurre in html. E non si tratta di un caso remoto: potrei scrivere sullo smartphone e tradurre sul pc, ad esempio.
Solo adesso, a 13 anni dalla sua nascita, il linguaggio sta per essere finalmente formalizzato con il nome di Commonmark. Già, perché anche sul nome c’è stata guerra.
Perché serve il Markdown?
Nel 2002, John Gruber e Aaron Swartz affrontano il problema di un nuovo modo di produrre html, che agevoli il lavoro di chi scrive materiale tecnico per il web.
Dalla nascita dell’html sono passati alcuni anni, e lo scenario è decisamente cambiato. Si era partiti dall’esigenza di marcare un testo con le informazioni che consentissero di:
- evidenziare attributi legati al contenuto del testo stesso (grassetto, corsivo, liste, titoli, collegamenti, immagini, citazioni, etc.);
- definire aspetti legati alla presentazione del testo (tipo, colore e dimensione dei caratteri, disposizione in una o più colonne, etc.).
Poi, con la nascita delle piattaforme di siti e blog, si è reso necessario soddisfare la seconda esigenza prescindendo dal testo, definendo dei template per offrire presentazioni diverse a uno stesso testo. Nascono così i fogli di stile, in gergo CSS, che rendono più semplice la scelta tra differenti progetti grafici e l’adattamento a terminali diversi dal pc (smartphone, tablet).
A questo punto è rimasto all’autore la marcatura legata al contenuto del testo, e l’html si rivela più pesante di quanto sia strettamente necessario.
Se lo scopo rimane quello di scrivere per il web, si vorrebbe quindi evitare la complessità dell’html, lasciando il testo leggibile mentre lo si scrive, ancora prima di visualizzarlo come html.
E, al tempo stesso, trattandosi di materiale tecnico, occorre poter citare facilmente tag e pezzi di codice da visualizzare come testo.
La nascita del Markdown
Il lavoro dei due produce nel 2004 una specifica di alto livello e uno script perl. Si tratta del primo semplice programma di editing Markdown e traduzione in html, su cui Gruber e Swartz fanno un test intensivo.
Il successo è immediato. Il programma e la descrizione del linguaggio diventano i riferimenti su cui altri sviluppano nuovi programmi Markdown, che a loro volta favoriscono la diffusione del linguaggio.
Gruber rende anche immediatamente visibile la versione Markdown della sua specifica, cosa che rende ancora più semplice adottare il nuovo linguaggio.
Fa da apripista Linux, Windows rimane un po’ indietro.
La torre di Babele e lo sforzo per uno standard
In realtà la specifica non è completa ma lascia delle ambiguità nella traduzione in html. Alcuni casi particolari non sono stati completamente specificati, e chi sviluppa nuovi editor Markdown si trova di fronte a un bivio:
- implementare il comportamento che ritiene corretto;
- copiare il comportamento dello script perl di Gruber e Swartz.
Il risultato è che uno stesso testo Markdown può risultare tradotto in html in modi differenti, alcuni con effetto diverso da quello voluto dall’autore del testo.
A fine 2012 un gruppo di esperti decide di mettere mano alla formalizzazione del linguaggio, in modo da poter avere in circolazione editor diversi ma coerenti con uno standard.
Questo il gruppo dei rifondatori:
- John MacFarlane, jgm@berkeley.edu
- David Greenspan, david@meteor.com
- Vicent Marti, vicent@github.com
- Neil Williams, neil@reddit.com
- Benjamin Dumke-von der Ehe, ben@stackexchange.com
- Jeff Atwood, jatwood@codinghorror.com
L’impresa è ardua. In otto anni è stata prodotta una vasta mole di documenti in Markdown, e inevitabilmente alcuni risulteranno incompatibili con lo standard. Occorre quindi che, per ogni decisione nella formalizzazione, si valuti il costo che comporterà.
Gli inizi del progetto
Jeff Atwood racconta come si svolsero i fatti.
Il gruppo invia un’email a Gruber nel novembre del 2012, per invitarlo a partecipare al progetto. Non ricevendo risposta, assume che Gruber non intenda partecipare, ma che comunque non abbia nulla in contrario al progetto stesso.
Non viene contattato Swartz, che è nel pieno della personale tragedia che lo porterà al suicidio agli inizi di gennaio, ad appena 26 anni.
Aaron Swartz, ragazzo prodigio in informatica (a 14 anni entrò nel working group che avrebbe definito lo standard RSS 1.0), sta infatti per vedersi definitivamente rifiutata la sua proposta di patteggiamento della condanna pendente a 35 anni di carcere e un milione di dollari di multa.
Il suo delitto consiste nell’aver illecitamente scaricato dai server del MIT un’enorme quantità di articoli accessibili a pagamento. L’intento di Swartz, tra gli architetti delle regole Common Creative quando era ancora teenager, era quello di rendere pubblici gli articoli.
Di fronte alla prospettiva di scontare una pena che ritiene fortemente ingiusta, Swartz si toglie la vita l’11 gennaio, impiccandosi. Sul sito di Wikipedia in inglese una sua biografia più completa.
Markdown, anzi no, CommonMark
Il lavoro di definizione dello standard comincia, dando per scontato il tacito consenso del padre del Markdown, John Gruber.
Viene registrato il dominio standardmarkdown.com e John MacFarlane crea un sito web, BabelMark, per cominciare a mettere ordine tra le varie implementazioni.
Come funziona BabelMark?
Il presupposto è che il sito di ogni implementazione renda disponibile un servizio di traduzione in html on demand.
BabelMark sottopone a questo servizio dei file Markdown di test e raccoglie il risultato.
In modo molto semplice è possibile quindi censire come funzionano le varie implementazioni, e verificarne nel tempo l’adeguamento al nascente standard.
Il lavoro procede ragionevolmente spedito, quando nel settembre del 2014, proprio mentre il progetto entra nel vivo, spunta Gruber, infuriato. Non gli sta bene l’utilizzo del termine Markdown, che ritiene una sua creatura.
Il gruppo deve cambiare rotta. Lascia un messaggio di cortesia sul sito standardmarkdown.com e registra un nuovo dominio per il progetto: commonmark.org. È qui che trasloca il progetto, compresa la specifica in via di definizione.
Quali editor ci sono in giro?
Il gruppo di lavoro conta di completare lo standard entro il 2017. Già oggi, comunque, le più popolari applicazioni di editing per Markdown sono CommonMark compliant.
Ciò che differenzia i vari prodotti sono fondamentalmente due aspetti:
- i costrutti supportati in modo nativo (quelli che mancano vanno inseriti come tag html);
|
Esempi:
|
- accanto alla traduzione in html, gli editor più evoluti offrono anche la traduzione in formato .pdf e .doc
Il mio primo approccio è stato con Markdown Here, un’estensione di Firefox per la scrittura di email.
Nel mio utilizzo l’esperienza è stata decisamente primordiale: avevo bloccato una finestra Firefox con un codice javascript come url a fare da editor:
data:text/html, <body contenteditable style="font: 1rem/1.5 monospace; max-width:60rem;margin:0 auto;padding:4rem;">
Inserivo il testo in Markdown, un click sull’estensione Firefox, e passavo da Markdown a html. Seleziona, copia, incolla da un’altra parte.
Poi mi sono evoluto, scoprendo il Markdown della BrowserNative, un’applicazione Chrome.
Infine la folgorazione! L’app Android (ma nata per IOS) iA Writer, documentazione sul sito.
Al momento uso quest’ultima per l’editing (con Huawey P9, reggi-smartphone home made e tastiera bluetooth), mentre Markdown della BrowserNative mi serve sul Chromebook per riprendere il file dal G-Drive, fare ritocchi e correzioni, tradurlo in html e copiarlo in WordPress, in modalità testo.
L’ app iA Writer è molto bella, potente e flessibile. Basta non usare le cose che dà, ma che mancano sull’app di BrowserNative.
Applicazioni per Windows se ne trovano, personalmente però anche qui suggerisco la app di Chrome.
Destreggiarsi con il Markdown in pochi minuti
Sembra un titolo acchiappa-click, ma le cose stanno esattamente così. Poche istruzioni e si è in grado di cominciare a scrivere testi per il web utilizzando il Markdown.
La specifica iniziale di John Gruber è ancora oggi il modo migliore per partire, bastano davvero pochi minuti per scorrerla. Guide introduttive al Markdown si trovano qui e qui. Un articolo sui vantaggi del Markdown si trova invece qui.
Altra lettura suggerita è, naturalmente, la guida dell’editor che si sceglie.
Le regole basilari del Markdown sono comunque poche e semplici.
Titoli
I titoli occupano da soli una riga; la sintassi è:
# Questo è un titolo di livello 1
###### Questo è un titolo di livello 6.
Il livello può variare da 1 a 6. Esiste un modo alternativo per i primi due livelli, ma lo ignoro per semplicità.
A capo e paragrafi
Il semplice a capo (INVIO) non viene interpretato come interruzione di linea, esattamente come avviene per l’html.
Per andare a capo vanno inseriti due spazi prima dell’INVIO. Non sempre ci si ricorda di farlo, ma poi ci si prende la mano.
Per chiudere un paragrafo e aprirne un altro, si lascia una riga vuota (due volte INVIO di seguito).
Liste
Per iniziare una lista numerata, si digita 1. qui comincia il primo elemento, quindi INVIO. Gli altri elementi vanno inseriti allo stesso modo, uno dopo l’altro. La numerazione è decisa dal primo elemento, sui successivi si potrebbe anche inserire numeri a caso.
Per una lista non numerata si digita - bla bla. Il carattere di apertura può essere anche * oppure +
Per inserire una lista in un’altra lista si lasciano da 1 a 3 spazi in più in testa agli elementi della lista più interna.
Si possono mischiare liste numerate e non numerate.
Linee orizzontali
Per inserie una linea orizzontale (html: <hr />) basta inserire in una riga almeno tre caratteri “-“, oppure “*”, da soli.
Link
La modalità di inserimento dei link è la cosa che più mi piace di Markdown.
In genere, quando scrivo una nota, ho come spunto delle pagine web di cui ho l’indirizzo, ma non so ancora in quale punto del testo voglio inserire il rimando.
Con Markdown si può inserire dove si vuole (io preferisco in fondo al file) gli indirizzi delle pagine, con questa sintassi:
[abc]: http://www. ... .com
dove abc è un identificatore scelto da chi scrive. Poi, nel testo, si aggiungerà il link così:
il link va inserito [qui] [abc]
È evidente la flessibilità di Markdown: spostare un link è questione di un attimo, basta traslocare l’identificatore e sistemare le parentesi.
Un link può essere anche inserito in linea, così:
il link va inserito [qui] (http://www. ... .com)
Ma si perde molta della flessibilità del primo metodo.
Immagini
Per inserire un’immagine si usa una sintassi simile a quella del link:
![alt text][abc]
[abc]: http://.... .jpg
Citazioni
Per inserire una citazione è sufficiente inserire come primo carattere >, da inserire all’inizio di ogni paragrafo (o anche linea) della citazione.
Codice
Per visualizzare il codice in modo testuale va interrotta la traduzione in html.
Markdown consente di farlo in uno di due modi:
- inserendo almeno 4 spazi all’inizio di una riga;
- aprendo e chiudendo il pezzo di codice con il carattere backtick, ( ` ); è il metodo che ho seguito in questo post per visualizzare codice all’interno di linee di testo.
Altro
Alcuni editor consentono di semplificare l’inserimento di molti altri elementi html. iA Writer consente, ad esempio, di inserire tabelle in Markdown.
Finora ho preferito evitare di usare gli extra di iA Writer, per evitare sorprese nel passaggio al Chromebook e quindi al Markdown della BrowserNative.
Una postazione vacanziera
Lo smartphone ormai è un’alternativa valida al pc in molti utilizzi, compresa la scrittura.
Una postazione di lavoro leggera dovrà però comprendere anche una tastiera bluetooth comoda e un qualcosa che tenga lo smartphone in posizione comoda.
Dopo aver cercato un supporto per smartphone che andasse bene (compreso giro all’Ikea), ho deciso di farmelo in casa, ricavandolo dal fondo di una bottiglia di acqua minerale. Preferibile sceglierne una di acqua frizzante, sono più robuste.
La bottiglia va tagliata con comuni forbici all’altezza giusta, spesso c’è una marcatura che può servire da guida per un taglio preciso. Poi, si ricavano due tagli a “U” sui lati, con un’inclinazione che ho scelto di 45° (a occhio, la foto mostra quanto la mia precisione non sia il massimo).
Il fondo è in genere sagomato con cinque appoggi (perché un numero dispari? ci farò un post!). Praticare i due tagli lasciando due appoggi da una parte e tre dall’altra. Per avere stabilità i tagli devono essere inclinati in modo che la zona da tre appoggi rimanga dietro, una volta che lo smartphone sia stato inserito e rivolto verso chi scrive.
All’interno del reggi-smartphone trovano comodamente posto gli auricolari, che altrimenti non si sa mai dove riporre.
Per la tastiera ho scelto su Amazon una che avesse il layout italiano, non volevo impazzire a cercare chiocciole, punti e virgola e simboli vari.
La terza foto è uno screenshot dell’app iA Writer, che dà un’idea di come funzioni.
Bene, fine del post.
Non mi rimane che aprire il file dal Chromebook, tradurlo in html con un paio di click e caricarlo su WordPress.
Buona lettura!
Articoli correlati:
Mi chiamo Pasquale Petrosino, radici campane, da alcuni anni sulle rive del lago di Lecco, dopo aver lungamente vissuto a Ivrea.
Ho attraversato 40 anni di tecnologia informatica, da quando progettavo hardware maneggiando i primi microprocessori, la memoria si misurava in kByte, e Ethernet era una novità fresca fresca, fino alla comparsa ed esplosione di Internet.
Tre passioni: la Tecnologia, la Matematica per diletto e le mie tre donne: la piccola Luna, Orsella e Valentina.
Potete contattarmi scrivendo a: p.petrosino@inchiostrovirtuale.it
