Quando você escreve example.com em uma postagem, ele funciona automaticamente como um link em uma postagem. (o que significa que parece um link e clicar nele leva você para aquele site).
Ele parece um link, mas na verdade não há link (o que significa que clicar nele não faz nada).
Isso mudou recentemente? Alguém em nosso fórum notou que temos um monte de links como este que (agora?) não estão funcionando.
NOTA: Meu exemplo acima é ao usar o editor Markdown (se isso não ficou óbvio). Quando uso o editor wysiwyg rico e apenas colo example.com na caixa de diálogo de link, o link funciona.
Tem certeza de que, por exemplo, [link](example.com) já funcionou? Sei que markdown contendo links relativos, por exemplo, [link](/u) para link para a lista de usuários em um site, funciona.
Eu não tenho! A única pista que tenho, se é que se pode chamar assim, é que tenho postado frequentemente links como esse para um site dessa forma (ou seja, sem o https://) e esta é a primeira vez que alguém menciona isso. Talvez ninguém nunca tenha clicado nos meus links!
Você concordaria que não se deve incluir o https:// em um link markdown?
Não vejo nada no padrão CommonMark que mencione isso: CommonMark Spec
example.com não é um URI válido por si só, embora se você digitar example.com por si só, ele será transformado em um link. Isso é convenção, não especificação, já que pineapple.belongson.pizza também é um nome de host válido (bem, era até eu deixar o domínio expirar), mas não é automaticamente linkado.
URI relativo (com ou sem ./) estes são markdown válidos, mas nosso parser os proíbe [relativo](../../386082) relativo [relativo](./386082) relativo [relativo](386082) relativo
URI absoluto [absoluto](https://www.example.com/foo.html) absoluto
URI sem esquema (semelhante ao relativo, mas explicitamente relativo apenas ao esquema) [sem esquema](//www.example.com/foo.html) sem esquema
Discutivelmente, este é o comportamento correto. Sem nenhum tipo de ancoragem na frente, é um caminho relativo à localização atual, o mesmo que [link](./example.com).
Sim, essa foi minha (esperançosa!) justificativa para o motivo pelo qual os links markdown também deveriam fazer isso. Mas estou lentamente aceitando o fato de que isso não vai acontecer (e que nunca aconteceu).
Acabei de tentar no Reddit e, sem o https://, ele nem sequer se torna um link.
Hmm… Não que seja um grande problema, mas também me acostumei a usar algo como [foo]() para fins de ilustração, que renderiza como foo.
Sinto que o problema aqui é a incompatibilidade de expectativas, dada a configuração do site “linkify”. Não tenho certeza de como resolver isso da melhor forma, mas vou compartilhar com as pessoas que pensam nesses casos extremos no composer para que pelo menos esteja no radar delas para consideração.
Espero que o markdown faça exatamente o que estou dizendo: [link] significa renderizar o seguinte como um link; cabe a mim colocar uma URL válida lá.
Espero que o composer faça um pouco de mágica: isso parece que deveria ser uma URL, então vou marcá-lo como um link.
Isso se tornou natural para mim, mas certamente vejo potencial para confusão. Talvez uma mágica semelhante possa ser aplicada para validar o formato dos links markdown antes de transformá-los em links.
Claro. Mas eu acho que a maioria dos usuários esperaria que [link](example.com) criasse um link para example.com. Colocar example.com na barra de URL do navegador funciona. E apenas digitá-lo em uma postagem também funciona.
estes são markdown válidos, mas nosso parser os proíbe
