LineHeight: Addio Textile, benvenuto Markdown!

Addio Textile, benvenuto Markdown!

In questi giorni ho avuto la possibilità di fare alcune chiacchierate, di vario tipo, con Andrea (ve ne parlerò approfonditamente nei prossimi giorni).
Fra i tanti argomenti che abbiamo trattato, comunque, è spuntato fuori un inaspettato scontro fra due editor di formattazione testi noti come Textile e Markdown.

Prima della segnalazione di Andrea, di Markdown conoscevo solo nome e notorietà. In effetti, è bastato uno sguardo veloce alla sintassi per farmi innamorare.

Sostanzialmente, entrambi gli editor presentano pregi e difetti sia per quel che concerne la semplicità e l'immediatezza d'uso, sia per quello che riguarda la precisione nel formattare il testo. Se devo essere sincero, è stato un'unico grande pro di Markdown a convincermi in questo improvviso cambio di rotta.

Come ho infatti accennato su spbitalia, spesso l'editor si rivela più "attento" e più facile rispetto a Textile, il quale può invece andare facilmente incontro ad errori e all'incapacità dell'utente di comprenderne la sintassi.

Se io ad esempio avessi voluto creare una lista con dei paragrafi annidati, usando la seguente sintassi:

*  Voce 1

   Paragrafo 1

   Paragrafo 2

   Paragrafo 3

   Paragrafo 4

 * Voce 2

Markdown avrebbe generato:

<ul>
<li><p>Voce 1</p>

<p>Paragrafo 1</p>

<p>Paragrafo 2</p>

<p>Paragrafo 3</p>

<p>Paragrafo 4</p></li>
<li><p>Voce 2</p></li>
</ul>

Mentre Textile avrebbe risposto, tutto indignato:

<ul>
    <li>Voce 1</li>
</ul>

  Paragrafo 1

  Paragrafo 2

  Paragrafo 3

  Paragrafo 4

<ul>
    <li>Voce 2</li>
</ul>

Per quanto ne so io, con quest'ultimo è impossibile annidare elementi dentro ad una voce di lista, a meno che questa azione non venga eseguita senza andare mai accapo.
Per me è stata una grossa limitazione, tanto che praticamente quasi tutti i messaggi di questo blog non fanno più uso dell'editor (preinstallato in Textpattern), e quindi spesso mi ritrovo a scrivere per intero anche il markup.

Un'altra cosa che non capisco è perchè Textile trasformi queste istruzioni:

* Ciao,
come
va?

in:

    <p> <ul>
    <li>Ciao,</li>
</ul><br />
come<br />
va?</p>

mentre Markdown fa la sua ganza figura con:

<ul>
<li>Ciao,
come
va?</li>
</ul>

Il comportamento più ovvio è, secondo me, il secondo. Tra l'altro, in quest'ultimo caso l'editor riporta codice aderente alle specifiche, mentre nel primo caso no, e per uno come me che cerca sempre di validare tutto il possibile (a breve passero alle tazzine di caffè...) questo è un grosso problema.

Un altro esempio che voglio mostrarvi riguarda la maniera assolutamente semantica in cui Markdown permette di creare, ad esempio, dei blocchi di citazione:

> Ciao, io sono un blocco di citazione su una riga!

> > Ciao, io sono un altro blocco annidato,

> > Ma la differenza col primo sta nel fatto che

> > Sono su più righe!

Output:

<blockquote>
  <p>Ciao, io sono un blocco di citazione su una riga!</p>

  <blockquote>
    <p>Ciao, io sono un altro blocco annidato,</p>

    <p>Ma la differenza col primo sta nel fatto che</p>

    <p>Sono su più righe!</p>
  </blockquote>
</blockquote>

Avrei potuto ottenere un blocco di citazioni anche su Textile, in questo modo:

bq. Ciao, io sono un blocco di citazione!

Ma semanticamente quanto comunica bq. rispetto a >, che è usato da tempi immemori in newsgroup e mailing lists?
Per chi è abituato a scrivere codice non è un problema, per gli altri sì.

Quindi, cosa mi ha spinto a congedare Textile in favore di Markdown?

La semplicità e immediatezza d'uso.

Fra i due editor trovo che il secondo sfrutti una sintassi più umana e comprensibile, permettendo anche ai meno preparati di capire effettivamente cosa stanno scrivendo, e come verranno presentati i loro testi.

L'unico appunto da fare a Markdown in questo contesto, come mi ha giustamente fatto notare Andrea, deriva dal fatto che, ad esempio, per marcare codice inlinea è necessario sfruttare il carattere ` (backtrip), che nelle tastiere italiane non è facile ottenere (fortuna che sulla mia linuxbox si risolve facilmente con Alt Gr + '). Textile sfrutta invece la chiocciola (@).
La precisione.

Textile tende a commettere errori più facilmente, e questo limita le mie possibilità di formattare un testo come voglio. Ne è un esempio la creazione di liste ordinate e non, che mi impedisce di annidare paragrafi in elementi <li>.
La qualità del codice.

Textile forse è più sensibile all'indentazione, ma Markdown genera codice validato in molti più casi, e pertanto per quel che mi riguarda questo fattore è decisamente rassicurante.
La varietà di presentazione dei testi.

Textile permette sicuramente molte più combinazioni, fra acronimi, apici, pedici, caratteri speciali, assegnazione di attributi come id, class, style e lang. Tuttavia, si tratta spesso di extra che spesso non sono essenziali per chi deve semplicemente scrivere e generare codice HTML nel proprio articolo in maniera semplice ma precisa.

Detto questo, concludo dicendo che in questo messaggio vi volevo illustrare pregi e difetti di entrambi gli script, ottimi in ogni caso e sicuramente più affidabili rispetto a quei mostri che la gente chiama erroneamente editor visuali. Spesso queste applicazioni semplificano la vita dello sviluppatore, portando un'innovazione.

Quando, però, un'innovazione diventa veramente progresso? Quando introduce miglioramenti che evolvono un sistema, non lo peggiorano.

PS: Indovinate come ho scritto questo articolo. ;-)

PPS: Il primo che ci riesce avrà l'onore di passare con me il capodanno, visto che non ho assolutamente voglia di andare a casa dei parenti per sorbirmi una festa di canti e balli anni '50 a ritmo di samba e cha-cha-chá! :-D

Approfondimenti

L'articolo è stato di tuo gradimento? Puoi controllare che vi sia altro di tuo interesse nelle categorie Markup e Standards, oppure iscriverti al notiziario RSS e seguirmi su Twitter per restare sempre aggiornato sulle ultime pubblicazioni.

Pubblicato sabato 30 dicembre 2006.

Discussione [8]

eKoeS aggiunge:

Ooops, mi sono appena accorto che c'era qualche problemino nei commenti, perchè non trovava più la classe Textile(). :)

Per risolvere ho semplicemente cambiato la linea 1408 di textpattern/lib/txplib_misc.php da:
```
$msg = $textile->TextileRestricted($msg, 1, $im);
```
a:
```
$msg = Markdown($msg);
```
Volendo, potete commentare la riga 1403, che non vi serve più:
```
$textile = new Textile();
```
Scusate per l'inconveniente! ;-)
Roberto aggiunge:

Guarda cosa avevo ~~ideato~~ ~~programmato~~ ~~assemblato~~ scopiazzato a destra e a manca un anno fa: http://www.rbnet.it/blog/2005/09/08/np_markdown-e-np_markdownviewer/

;)
eKoeS aggiunge:

Mi fai sentire maledettamente vecchio, Roberto. :D

Attualmente usi l'editor predefinito di Wordpress?
Roberto aggiunge:

Premessa: quello era un plugin per NucleusCMS; poi sono passato a WP ed ho abbandonato la sintassi Markdown . La minima esperienza che ho avuto con questo tipo di sintassi alternativa (textile, markdown, dokuwiki e pochi altri) mi ha portato a ritenere che il suo utilizzo sia un po' ridondante/inutile in ambienti semplici come il mio blog, dove ho bisogno giusto di qualcosa che divida in paragrafi correttamente, che mi permetta di costruire una semplice lista e l'immancabile blockquote.

Tutto questo è già decentemente integrato nell'editor di WP (che utilizzo in modalità editor testuale, non visuale): i 4 tag extra che utilizzo in più li ho pre-programmati attraverso un altro plugin che fa qualcosa di molto simile al plugin NP_AddCustomTEXT che avevo realizzato sempre per NucleusCMS un po' di tempo fa.

Resta il fatto che il codice grezzo di un articolo formattato con Markdown è 100 volte più leggibile di un articolo formattato nella maniera classica.

Ah, quasi dimenticavo! Ottimo il tuo articolo dove, come al solito, analizzi in maniera molto chiara e comprensibile pregi e difetti delle di markdown e textile ;)

CiauZ!
eKoeS aggiunge:

La minima esperienza che ho avuto con questo tipo di sintassi alternativa (textile, markdown, dokuwiki e pochi altri) mi ha portato a ritenere che il suo utilizzo sia un po' ridondante/inutile in ambienti semplici come il mio blog, dove ho bisogno giusto di qualcosa che divida in paragrafi correttamente, che mi permetta di costruire una semplice lista e l'immancabile blockquote.

Penso sia quello che pensano un pò tutti. Io per alcune esigenze tendo a sfruttare molto spesso elementi block e inline nei miei articoli, e scriverli a mano dopo un pò diventa noioso, nonchè faticoso e pesante. Markdown è stato una manna, perchè supera il blocco che ha Textile per quel che riguarda l'annidamento di elementi.

Tra l'altro, nei commenti Textile veniva usato in maniera molto restrittiva (cosa che comunque non trovo fosse poi così sbagliata). Ora con Markdown si ha qualche libertà in più. :)
Marco aggiunge:

Ho scoperto Markdown leggendo questo articolo, e escluso l'uso di determinati alias per i tag, non trovo questa gran differenza con textile. Tu parli di paragrafi in lista, ma semanticamente non è una cosa corretta, perchè una lista è un elenco, quindi un qualcosa di conciso. Sarebbe illogico scrivere una serie di paragrafi messi in lista (più logico suddividere in capitoli o pagine.) Idem il discorsi di ciao, come stai scritto su più righe. Se lista, non ha motivo di esistere su più linee. Comodo invece il blockquote gestito in questo modo e molto comodo anche l'uso dei # test # per gli headers
eKoeS aggiunge:

Tu parli di paragrafi in lista, ma semanticamente non è una cosa corretta, perchè una lista è un elenco, quindi un qualcosa di conciso.

In questo blog (e anche nel tuo) i commenti sono gestiti come lista ordinata, e il testo si trova fra paragrafi. Una lista non è esclusivamente concisa, ma è un elenco che, per il mio modo di interpretare la semantica, può essere di vari tipi.

La lista della spesa, e la lista di links; la lista (elenco) degli ultimi articoli pubblicati incluso il sommario, così come la lista (elenco) degli ultimi libri che ho letto, completa di autore, editore, e codice ISBN.

Sarebbe illogico scrivere una serie di paragrafi messi in lista (più logico suddividere in capitoli o pagine.)

Se la lista fosse veramente qualcosa di "conciso", non avremmo avuto la possibilità di annidare sottoliste a quelle principali. Dentro ad un paragrafo non posso logicamente inserire un altro paragrafo, perchè ognuno di questi definisce una porzione di testo (chiamiamola entità) unica e indipendente. Ma dentro una lista io posso inserire elementi blocco. Perchè?

Penso che la risposta consista nell'affermazione "un sito web non è un libro". In un libro, o comunque su un innocentissimo foglio, noi spesso facciamo degli elenchi che, come dici te, sono brevi e concisi, e spesso si limitano a poche voci. Una pagina web, tuttavia, non si comporta come un pezzo di carta.
Qui, per scrivere, usufruiamo della famiglia caratteri sans-serif, poichè su monitor garantisce una lettura più gradevole. Qui dobbiamo preoccuparci di supporti differenti, mentre un libro sarà sempre e comunque per tutti di determinate dimensioni e spessore.

Sono, giustamente, due campi differenti, e come tali - secondo me - i concetti alla base di essi e gli elementi che li caratterizzano, sono altrettanto diversi.

Idem il discorsi di ciao, come stai scritto su più righe. Se lista, non ha motivo di esistere su più linee.

Io preferisco un editor che mi permetta di annidare gli elementi, o anche solo suddividerli su più linee, piuttosto che propormi una sua soluzione anti-semantica e non conforme agli standards.
Marco aggiunge:

Non avevo più seguito questa discussione ed il tuo articolo. Ci sono ricapitato sopra, mentre mi studiavo il tuo sistema di archivio (upm_archive ?). La risposta che mi hai dato è perfettamente coerente e mi rendo conto di aver sbagliato nel giudicare le liste ed anche markdown.