You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 22, 2020. It is now read-only.
Fernando told me about this today, and said that the idea was to support regular links like [foo](https://bar) and also allow customization like [foo](https://bar){type=img width=100%} or similar.
ReST already has a generic syntax for different link "types", that get routed through the extensible "role" system. For example, you can write
:img:`foo <https://bar>`
or
:ref:`introduction`
or
:ref:`as discussed in the introduction <introduction>`
And at least for paragraph level markup it has a generic idea of arbitrary key-value arguments, though I'm not sure if there's any equivalent for inline markup. Nonetheless, maybe it would make sense to say that [foo](https://bar){type=img} was exactly the same as
:img:`foo <https://bar>`
i.e. the word img here is naming a role, not a raw HTML tag?
The text was updated successfully, but these errors were encountered:
The way pandoc uses the {} is as a place for HTML attributes (incidentally this is closely related to #6, and another issue I haven't raised yet about attributes more generally).
I think it would be reasonable to consider something richer like this, but if we can shoehorn it into a particular way to use HTML attributes (e.g., a data-rst-role=img or by using classes) we might be able to support this kind of extensibility without breaking the basic model of what markdown is supposed to mean. I think pandoc has a lot to teach us in that regard.
I guess the question is whether we want to break the basic model of what markdown is supposed to mean (a nice syntax for HTML), or break the basic model of ReST is supposed to mean (an extensible syntax for structured documents that can be rendered into multiple display formats).
See also #9 (comment), where @fperez makes the case that we shouldn't be baking in the assumption that HTML is the only output format.
Fernando told me about this today, and said that the idea was to support regular links like
[foo](https://bar)
and also allow customization like[foo](https://bar){type=img width=100%}
or similar.ReST already has a generic syntax for different link "types", that get routed through the extensible "role" system. For example, you can write
or
or
And at least for paragraph level markup it has a generic idea of arbitrary key-value arguments, though I'm not sure if there's any equivalent for inline markup. Nonetheless, maybe it would make sense to say that
[foo](https://bar){type=img}
was exactly the same asi.e. the word
img
here is naming a role, not a raw HTML tag?The text was updated successfully, but these errors were encountered: