Sou um grande fã do Markdown de John Gruber. Quando se trata de linguagens de marcação humanas para a Web, acho que ninguém acertou tão bem quanto o Sr. Gruber. Sua filosofia foi clara desde o início:
A intenção é que o Markdown seja tão fácil de ler e escrever quanto possível.
A legibilidade, no entanto, é enfatizada acima de tudo. Um documento formatado em Markdown deve poder ser publicado no estado em que se encontra, como texto simples, sem parecer que foi marcado com tags ou instruções de formatação. Embora a sintaxe do Markdown tenha sido influenciada por vários filtros de texto para HTML existentes, incluindo Setext, atx, Textile, reStructuredText, Grutatext e EtText, a maior fonte de inspiração para a sintaxe do Markdown é o formato do e-mail de texto simples.
Se o senhor gosta de ASCII de qualquer tipo, vai se sentir imediatamente à vontade com o Markdown. É tão óbvio que ele foi projetado por alguém que fez um muito de escrita on-line, já que ele se baseia em convenções comuns de texto simples que temos usado coletivamente há décadas. Sem dúvida, é muito mais intuitivo do que as alternativas que pesquisei.
Com um ano e meio de experiência real em Markdown em nosso currículo no Stack Overflow, temos sido bastante felizes. Eu diria que o Markdown é o pior forma de marcação, com exceção de todas as outras formas de marcação que já experimentei. É claro que os gostos variam, e há muitas alternativas viáveis, mas eu promoveria o Markdown sem hesitação como uma das melhores – se não a o melhores opções de marcação humana que existem.
Não que o Markdown seja perfeito, o senhor sabe. Depois de expô-lo a um grande público, tanto o Stack Overflow e o GitHub descobriram de forma independente que o Markdown tinha três características específicas que confundiam muitos usuários:
- Os URLs nunca são vinculados a hiperlinks sem que sejam colocados em algum tipo de marcação explícita.
- O sublinhado [_] pode ser usado para delimitar negrito e itálico, mas também funciona para ênfase intrapalavra. Embora um uso típico como “_italic_” seja claro, há efeitos colaterais perturbadores e inesperados em frases como “some_file_name” e “file_one and file_two”.
- Ele é orientado por parágrafo e não por linha. Os retornos não são convertidos automaticamente em quebras de linha. Em vez disso, os parágrafos são detectados como uma ou mais linhas consecutivas de texto, separadas por uma ou mais linhas em branco.
Os itens nº 1 e nº 2 são tão fundamentais e universais que acho que o merecem ser alterados na própria especificação do Markdown. Houve tanta confusão em relação à ênfase inesperada dentro da palavra e à falha no hiperlink automático de URLs que alteramos essas regras do Markdown antes mesmo de sairmos da versão beta privada. O item nº 3, a conversão de retornos em quebras de linha, é um pouco mais discutível. Estou em cima do muro com relação a esse item, mas acredito que ele seja significativo o suficiente para justificar uma escolha explícita de qualquer maneira. Deveria ser uma opção configurável padrão em todas as implementações do Markdown que o senhor pode ativar ou desativar, dependendo do público-alvo.
O Markdown foi originalmente introduzido em 2004 e, desde então, ganhou bastante força na Web. Quero dizer, não é nenhum MediaWiki (graças a Deus), mas está em uso ativo em vários sites, alguns deles bastante populares. E para uma forma de marcação tão popular, é um pouco estranho que a última atualização oficial da especificação e da implementação de referência tenha sido no final de 2004.
O que me leva ao maior problema do Markdown: John Gruber.
Não quero dizer isso como uma crítica pessoal. John é um escritor fantástico e o Markdown tem uma especificação (em sua maior parte) sólida, com uma forte declaração de visão. Mas o fato de não ter havido nenhum tipo de melhoria na especificação ou na implementação de referência do cinco anos é… um tipo de problema.
Existem alguns bugs bastante graves na antiga implementação Perl do Markdown 1.0.1 de 2004. Erros que John já corrigiu em oito betas 1.0.2 que, de alguma forma, nunca viram a luz do dia. Claro, se o senhor souber os encantamentos certos do Google, poderá obter o arquivo não lançado 1.0.2b8, postado clandestinamente em maio de 2007, e começar a extrair as correções de bugs manualmente. Foi isso que tive de fazer para corrigir bugs no nossa implementação de código aberto do C# Markdown, que foi naturalmente baseada naquela fatídica (e tecnicamente apenas) Versão 1.0.1.
Eu também esperaria que uma implementação de referência viesse com alguns conjuntos de testes básicos ou arquivos de entrada/saída de amostra para que eu possa saber se o implementei corretamente. Não tive essa sorte; os arquivos oficiais do site de Gruber incluem o arquivo Perl simples, juntamente com um leia-me e uma licença. A palavra “test” não aparece em nenhum deles. Tive que fazer muito mais pesquisas para finalmente encontrar o encontrar o MDTest 1.1. Não sei dizer de onde vieram os testes, mas eles parecem ser mantidos por Michel Fortin, o autor do implementação primária do PHP Markdown.
Mas John Gruber criou Markdown. Ele criou o conceito e a implementação inicial. Ele é, em todos os sentidos da palavra, o pai do Markdown. É o bebê dele.
Como “pai” do Markdown, John tem algumas responsabilidades importantes na condução de seu bebê à maturidade. Ou seja, liderar. Definir a direção. Além daquele impulso inicial de 2004, ele fez muito pouco de ambos. John está administrando esse projeto de código aberto específico da mesma forma que Steve Jobs administra a Apple – por pura força do ego individual. E isso é péssimo.
Desde então, tudo o que consigo encontrar é atividade esporádica em listas de discussão obscuras e um pouco de interação passivo-agressiva com a comunidade.
Em 15 de março de 2008, às 02:55, John Gruber escreveu:
Detesto o que o senhor fez com o Text::Markdown, que é mais ou menos transformá-lo em um alias para o MultiMarkdown, do qual discordo de quase todas as partes em termos de adições de sintaxe.
Uau, isso é uma linguagem muito forte. Fico feliz por estar provocando opiniões fortes, e é bom ver o senhor contribuindo ativamente para a direção do Markdown 😉
Pessoalmente, não gosto (nem uso) as extensões do MultiMarkdown. Conforme observado várias vezes na lista, eu não considero que o que fiz seja de alguma forma uma boa solução técnica/internamente em sua forma atual e, como tal
Markdown.pl ainda é uma implementação de “referência” melhor.No entanto, acho um tanto irônico que o senhor possa criticar um esforço ativo para realmente fazer o Markdown avançar (cujas falhas atuais foram reconhecidas publicamente), quando ele passa mais no seu conjunto de testes do que o seu esforço, e quando o senhor nem sequer se deu ao trabalho de atualizar seu próprio site sobre o projeto desde 2004, apesar de ter atualizado o código que pode ser encontrado em seu site (se você pesquisar) muito mais recentemente do que isso.
Não gosto de código copiado e colado e de bifurcações sem motivo (real) – ver outros dois cópias mortas do mesmo código no CPAN me deixaram triste, e por isso fiz alguma coisa para levar a situação adiante. Talvez se o senhor tivesse se esforçado para manter uma comunidade e levar o Markdown.pl adiante em qualquer momento nos últimos 4 anos, não estaria em uma situação em que as pessoas pegaram “seu bebê” e o perverteram a um ponto que o senhor despreza. Se o senhor começasse com o Markdown.pl e seguisse em frente com esse tivesse sido uma opçãoteria sido meu caminho preferido, mas não vi nenhum valor em produzir o que seria uma quinta implementação do Markdown em perl.
Está quase chegando ao ponto em que John Gruber, a própria pessoa que nos trouxe o Markdown, é o maior obstáculo que impede o Markdown de avançar e amadurecer. Fico muito triste ao ver essa negligência com os pais de código-fonte aberto. Por que trabalhar contra a comunidade quando o senhor pode trabalhar com ela? Não precisa ser assim. E não deveria ser.
Acho que o problema mais fundamental do Markdown, em retrospecto, é que a sede oficial do projeto é o um conjunto estático de páginas da Web no site do John. Gruber poderia ter hospedado o projeto Markdown de uma forma que fosse mais favorável à colaboração de código aberto do que um monte de HTML estático. Tenho certeza de que o SourceForge existia no final de 2004, e há muitas opções para hospedagem adequada de projetos de código aberto hoje – GitHub, Google Code, CodePlex e assim por diante. O que o impede de instalar Markdown em qualquer um desses sites, agora mesmo, hoje? O Markdown é o bebê de Gruber, sem dúvida, mas também é maior do que qualquer pessoa. Ele é de código aberto. Ele também pertence à comunidade.
No momento, temos o pior dos dois mundos. Falta de liderança do topo e um monte de esforços fragmentados e mal coordenados da comunidade para promover o Markdown, nenhum dos quais são oficialmente canônicos. Isso não é apenas inconveniente para quem tenta encontrar informações precisas sobre o Markdown; na verdade, está prejudicando o futuro do projeto. Talvez seja verdade que o senhor não pode matar um projeto de código aberto, mas a má educação é certamente suficiente para fazer com que ele cresça atrofiado e talvez até um pouco desajustado.
Não quero desrespeitar o senhor. Eu não falaria sobre isso se não me importasse, se não achasse que o projeto e John Gruber são eminentemente dignos. O Markdown é uma parte pequena, mas importante, do tecido de código aberto da Web, e o projeto merece uma administração melhor. Embora a comunidade possa fazer muito com os (muitos) bebês órfãos de código-fonte aberto que existem por aí, eles têm um futuro muito, muito mais brilhante quando seus pais assumem a responsabilidade por eles.