We are using <sup>[[up]](<<..>>.md)</sup> at top of the most of pages we create, and on positions relative to certain types of titles. There is also home. These need visual square brackets, because that sup block also contains tags with spaces. These tags work with procedural management, and are part of specification which shares the syntax with other file formats.
We also use countless amount of different inline sup buttons. (links to repositories, docs and etc)
The page overall, and those links themself, are more readable when all the links are enclosed in the brackets. Wikipedia encloses references in the same way. The brackets make the text more compatible, because if its copied from viewer (different tools, embeds, web browser), and formatting doesn’t get copied, or isn’t supported by the paste operation, there is no uncertainty about whats text, and whats a reference or navigation shortcut.
Currently in the visual editor, its possible to add such link like this: [\[<<..>>\]](<<..>>.md). But the outer (link) brackets are not hidden, and the link isn’t clickable. Only, preview is shown when hovering over it, if enabled. (Wikilinks are disabled)
Proposed solution
Please add support for Markdown in sup and sub HTML blocks, same as in other tools. (at least sup)
Please make so [[<<..>>]]( is not considered to contain a Wikilink, if Files and links\Use [[Wikilinks]] or other setting is off, or in general.
Please make [[<<..>>]]( links clickable in the visual editor.
Can you explain, why you are using <sup> in this manner? IIRC Wikipedia uses <sup> for footnotes.
How do you expect the notation <sup>[[up]](<<..>>.md)</sup> to render? It looks like an undefined mix of wikilink and Markdown link. You could resolve some of the ambiguity by escaping square brackets: <sup>[\[up\]](<<..>>.md)</sup>.
How should we read <<..>>.md? Do you your file names look like <<catandmouse>>.md or like catandmouse.md?
What are “inline sup buttons”?
If you prefer certain links to render with square brackets, you could add those brackets in CSS with ::before and ::after and content:.
The <sup> makes the tags/references not intrusive. Having the tags/references as basic text, distracts user from: the context statements, or content of the page (when at title). It’s use inline, also allows to use no-Sup [<<..>>] for development tags, and rendered placeholder text. Wikipedia uses <sup> inline: at references to Footnotes, ‘needs a source’ and other tags, and i saw it used for notes/comments.
We expect <sup>[[up]](<<..>>.md)</sup> to be rendered as a Markdown link with [up] text shown (same as [[<<..>>]]:, but we don’t have reasoning/need for it), that is achievable by making Markdown links take priority over Wikilinks, as suggested in this and the linked threads. That also can have ability to be disabled/enabled trough settings. (the setting, or specific escaping, would be needed for [[<<..>>]]:)
Currently, [\[<<..>>\]](<<..>>.md) is not fully supported in the visual editor either.
<<..>> means any text which is compatible with it’s subject context. By “buttons” i mean the links in the subject form.
We don’t prefer them to render, those brackets have actual meanings in the text (even for machine-processing). Markdown was designed as a plain-text compatible markup, that is: one of it’s main properties, and the reason we are using it.
I find this feature request difficult to understand.
The erratic rendering of nested square brackets is already being discussed elsewhere.
In order to make something “not intrusive”, I’d choose CSS instead of HTML. It is possible to change the visual design of tags with custom CSS snippets. See this post for an advanced example.
Are you aware, that Obsidian Flavored Markdown explicitly rules out the rendering of Markdown inside HTML:
Obsidian does not support using Markdown formatting or blank lines inside of HTML tags.
This means, whatever you place inside HTML tags like <sup> should be rendered literally.
In my understanding, the examples from Wikipedia all fall in the category of footnotes. They either link to a footnote or explain the need for still missing footnote. Footnotes are supported in Obsidian Flavored Markdown.
Of course you can use some HTML in Obsidian (see link in a previous post).
H<sub>2</sub>O is rendered as H2O.
But whatever you place between HTML tags is rendered as plain text. Any Markdown command will be ignored.
So Obsidian will render <sup>[[up]](<<..>>.md)</sup> as [[up]](<<…>>.md) and not as a link.
Are you aware what the HTML specs say about <sub> and <sup> (my emphasis)?
These elements must be used only to mark up typographical conventions with specific meanings, not for typographical presentation for presentation’s sake. (…) In general, authors should use these elements only if the absence of those elements would change the meaning of the content.
So it’s the HTML community, and not Obsidian’s developers, who say, that <sub> and <sup> are not meant to just make “the tags/references not intrusive.”
(In Wikipedia the links in <sup> do have a special meaning. They are related to missing footnotes.)
Making links not Superscript changes their meaning, because they become a part of text instead of being a list of references. Square brackets can help against this, but that still decreases ergonomics alot.
Also, if you like specs that much, get this from Markdown:
Unlike block-level HTML tags, Markdown syntax is processed within span-level tags.
Though those specs don’t matter here. And, GitHub and Markdown-It are great examples of supporting Markdown in the block level HTML.
Here, take this example and try to make a more ergonomic version.
If I wanted such a design, I’d use a CSS snippet. For example, I’d add a keyword as <title> that describes what makes these links special. I chose “quickref” because I assume that the use case here is to provide some quick references to external sources:
That makes it incompatible with all other Markdown renderers, including GitHub. And in source code form, that is much less readable.
Rendering Markdown inside <span>…</span> is not what the Markdown spec says. Wild guess: maybe you meant rendering when surrounded by any of the most of tags.
The -- on 1st line allows to put a hint for recognizing item which the name refers to, or specify a verdict.
Actually the optional link title is compatible with CommonMark and Github Flavored Markdown. I took the notation from their specs.
Rendering Markdown inside <span>…</span> is just a feature I’d like to see in Obsidian, exactly for use cases, where typography matters. It would provide additional selectors for CSS.
IMO, your use case doesn’t need any changes in Obsidian at all, because your links seem to target external resources. Why not simply write plain HTML?
Even if GitHub would provide ability to use custom CSS for Markdown, which AFAIK it doesn’t. Requiring each user to use specific custom CSS in Obsidian, on GitHub, and in every other f* case is nothing about a solution, as far i see.
Because the links obviously don’t always target internet resources.?
