While there is no Markdown spec, inline HTML is supported by most markdown implementations. Notably, Github. Comparisons will be made.
I bring this up because no markdown implementation supports some kind of anchor construct outside of hyperlinks. This makes it impossible to link to particular segments of a README or add a nice internally linked table of contents without adding your own raw HTML anchor tags. My READMEs kind of fell apart after migrating to Bitbucket, because it doesn't support raw tags.
maybe this relates more to #6322 which is only about the anchor links. But that was closed as duplicate of this one.
The headers in the HTML generated from the markdown get an id-property.
Bitbucket seems to prepend "markdown-header" to the text of the header, strip all special characters (./#), transform to lower case, and replace whitespace with a dash.
So as a work-around, I hardcode these IDs as my anchor links
e.g. my markdown looks like this.
The forward anchor link
1. **[Link to Header](#markdown-header-1-header)**: some
Somewhere else in the document, the actual anchor.
## 1. Header
The header tag in the generated html looks something like this.
The anchor link will work correctly. It's hacky I know - and presumable only works because of bitbucket's particular html-generator, but at least it gets the anchor links working. It's probably not the most robust forward-compatible solution though.
For any markup that is not covered by Markdown’s syntax,
you simply use HTML itself.
There’s no need to preface it or delimit it to indicate
that you’re switching from Markdown to HTML;
you just use the tags.
Even if you decide not to include the feature, it would be good to have the differences documented somewhere.
For folks trying to create a table of contents note that putting
in the document will do this automatically. This doesn't eliminate the desirability of embedded HTML (e.g. for better list control) but it does solve one important use case.
Is the use of HTML entities such ® not going to be supported either?
Not sure this is a duplicate. First of all duplicate issue is about supporting "small subset" of HTML and "strike" tag in particular, and this issue has a wider scope. Secondly, this issue has bigger amount of votes. I would reverse duplicate relationship between those 2 issues.
Also, as a note on only supporting a subset of HTML tags, I use emacs org-mode for my documentation, which can export to markdown, but assumes a full set of HTML tags are available. It would be incredibly helpful to have the full set of tags available, since this is the assumption in general, and it would make bitbucket compatible with any number of tools that can export to markdown.
I'd concur with @Kirill Muzykov. The markdown spec encourages full access to HTML; obviously this is a tall order if you're compiling other peoples' arbitrary markdown the way Bitbucket is. There has to be a blacklist/whitelist. On the other hand, it's not clear which tags people on this issue want supported, but it's a lot more than <strike>.
Perhaps we can start to list the tags we'd like to have access to, so that they have a starting point? I, for one, would love full access to the anchor element, with internal linking, and all tags I'm likely to embed inside a link (as markdown won't process markdown inside raw HTML).
Alternatively, what's a reasonable blacklist of HTML elements?
I'm not sure why there has to be a blacklist.. I understand it may not be an insignificant amount of work to implement, but there could be an option to use a library like PageDown for rendering.
I don't want to be presumptuous, since I don't know how bitbucket's backend for rendering markdown currently works, but they are already rendering the markdown to html. just leave the HTML in markdown files alone, and send it to the browser to render. it undoubtedly takes more than just that to integrate HTML in the current rendering engine, but i can't imagine there isn't a generic solution to recognizing and embedding html.
The only tags I can think that should be blacklisted are <script> and other tags that bring security concerns.
BitBucket (as mentioned in #4412) uses Python Markdown for it's markdown rendering. Looking at the documentation, (specifically about safe_mode) the authors comment:
See Also: HTML sanitizers (like Bleach) may provide a better solution for dealing with markdown text submitted by untrusted users. That way, both the HTML generated by Markdown and user submited raw HTML are fully sanitized.
There's no reason to have the community whitelist/blacklist tags, when a library (recommended by the authors of the currently used markdown library) exists to do exactly what we want.
As noted in #4412, we rely on https://github.com/waylan/Python-Markdown for our Markdown rendering. We intentionally do not support HTML for security reasons. Ideally, things like strikethrough or other elements should be added to Markdown or to an extension. Please continue to vote and comment about your specific needs to help us understand how to prioritize.
Do the developers have any feelings about solutions such as Bleach? I would assume it would need to go through some sort of security audit before it would be able to be used; though what I'm more interested in knowing, I guess, is if a sanitization solution like that would meet security requirements, or if instead only a whitelist like solution is the only acceptable route.
As a side note, I completely understand the tradeoffs that need to be made with regards to security. Frankly, I'm just excited this issue is getting attention. (And, I'll completely accept a whitelist if that's what's mandated.) It would just be nice to know the context to have a useful discussion within.
Strike. Please, add strike. In Atlassian world, people who file issues may be smart enough to create separate issues, but us in the real world frequently have to deal with folks who try to cram a list of 10 points into a single issue, and short of taking half an hour to separate all those out into separate issues, using strikeout is the best way of depicting which points have been addressed.
tl;dr -- not having strike imposes a somewhat-serious usability issue for some users.
<pre>, <code> tags with the ability to use formatting like <b>, <i>, etc. within them.
Say I have /path1/path2/path3/path4/file.ext maybe by itself or as part of a larger code block, and I want to emphasize the path4/file.ext part. I don't see any way to do this with the existing wiki languages.
Honestly, I don't see a sane way to do that. What if you're writing C code?
How is the wiki syntax supposed to differentiate between an un-closed bold syntax, or a pointer to a pointer? Using the html tags makes it even worse; you can never put html code in a code block if you do that.
@Paul Rupe Markdown has never supported extra emphasis tags inside code blocks. If you think about it, that's entirely counterintuitive to the purpose of <pre>.
This issue isn't about inventing a new markup syntax. It's also not asking Bitbucket to support a single new tag, such as <strike>. It's about the existing markdown parser, which fails to comply with a well-defined spec where all of these considerations are already addressed:
For any markup that is not covered by Markdown’s syntax, you simply use HTML itself. There’s no need to preface it or delimit it to indicate that you’re switching from Markdown to HTML; you just use the tags.
The only restrictions are that block-level HTML elements — e.g. <div>, <table>, <pre>, <p>, etc. — must be separated from surrounding content by blank lines, and the start and end tags of the block should not be indented with tabs or spaces.
I agree with @Paul Rupe, it would be nice to allow HTML <pre><code> with embedded <b> and <i>. Sometimes you need to provide an example of working in shell and highlight user input. With indented code block it's not possible by design, so using <pre> is the only option.
I am using inline svg in my markdown… well I was using it, as it seems now. :>
What I like is the principle of some markdown processor to allow the author to use any kind of html within a <div> or <span> tag.
If you fear the security risks, maybe it's an option to allow it at least for private repositories.
The glacial pace at which Atlassian is working to resolve this is more than a little bit unsettling... The new ~~ and ++ symbols should be removed and HTML allowed. That's really all there is to it. I now regret advocating for something as simple as strikeout earlier on, didn't realise it would create such a completely-ignored regressive issue...
Please, please, please, just disable 'safe_mode' and use a proper tool like bleach for HTML sanitation like the author of Python-Markdown suggests. I can understand the need to sanitize but the inability to add simple entities like copyright and trademark symbols is baffling to a lot of users. Some might go so far as to say the situation is "stupid."
Alternatively, switch to a superior version of markdown, like Github-Flavored-Markdown. Sure, it's Github, yeah yeah, but it is a superior variant.
I was a bit shocked to find out that my <br/>'s were not being rendered as actual line breaks. Even more shocked to find out that it is actually not possible to insert line breaks into a table. The funny thing here is that a white list would take any normal dev team, even for a massive project like bitbucket, only a few weeks at most to implement. Years later, everyone still scratching their heads on how various simple HTML markups are not supported.
When this issue was created, I don't think that CommonMark was a thing, yet. If I were re-evaluating the Markdown parsing of any major project today, I'd embrace it as the most future-proof, inter-operable choice of technology. There's a Python implementation, and as a plus it eliminates the burden of maintenance and questions of feature-support from the organization using it by deferring to a community standard.
Just signed up with bitbucket for the nice opportunity to have private repos. I also imported all my public repos from github, but all my carefully crafted README files definitely fell apart big time, since i totally rely on HTML in there. I feel like a beautifull README is the inviting entry point to your repo and therefore not totally unimportant at least for public repos. HTML often means the difference between only neutral and informative (without) and designed and inviting (with). Would be great to see it enabled here.
I find it ridiculous not being able to color the fonts in my documentation.
In my opinion this should be somewhat a key feature since colors are the best way to highlight parts and drawing the readers attention (if for eg. someone wanted to note a bug/issue which is realy important to read).
The not so adequate markdown is a major reason for me to switch back to GitHub since in my opinion wikis and documentations are realy important, especially for open-source projects. Can't work without it anymore.
I am also looking forward to <kbd> support like @Alexandre Alves de Sá, though I don't usually write in Markdown but reStructuredText.
I want to bring up an issue on GitHub, which has been supporting the tag in reST for nearly three months. Hopefully, this would give the staff another reason to implement something, even the issue was about reST.
@ Bitbucket staff
Frankly, I don't think the staff should mark other issues which specifically request certain tags unless someone is maintaining a list of tags here. For now, it's very ambiguous about what tags are in request and messy about the rationales users brought to the staff.
This issue is flooded with many comments, which could have been left to those issues rather than all mixed up here. I myself only care about <kbd> even I don't write in Markdown, <br> and <pre> ain't needed in reST. And I am expected to receive comments, which I don't care to read, after I comment.
So, wouldn't it be better to leave those issues open?
The problem is that my IDE (intellij/android studio) eliminates all the extra spaces at the end of each line so a <br> tag would be more handy. But I don't thing what you're saying is valid anywas stylig
I find myself on this page often, copying and pasting a unicode pipe doppleganger while trying to document parameters, using industry standard notation, in table cells on the wiki linked to, yes, a source code repository.
We're working on improvements to our Markdown handling that will allow use of more HTML elements. Early testing has revealed some performance impacts, so we're working out those kinks. I hope to have more to share soon!
Thanks for CommonMark support. Has anyone got links to good doc about it? CM has a detailed spec (to which I have linked from Wikipedia), but I'd appreciate something that focuses on the differences between CM and "old-school BB Markdown." From this issue and the latest CM spec, I'm guessing the main difference is raw HTML, but I'm also guessing BB is not gonna support all/any HTML--am I missing something?
@Brian Edwards I figured out how to enable "CommonMark", but it did not solve my problems:
I mostly care about the Overview page for my repository - switching default file viewer does not seem to affect that.
I want others who visit my repository to see HTML entities like Ö rendered correctly - because otherwise my name is not rendered correctly. Switching my default file viewer does not seem to affect other users.
Please please please consider adding HTML entities support (Ö, etc.) to the Bitbucket Overview page. It's the most portable way to get non-ASCII characters I know of and most Markdown implementations support it well.
As an aside, CommonMark seems to dramatically increase page loading/rendering time when viewing Markdown files.
CommonMarkdown is broken ("Failed to get raw source: Bitbucket API status=401, data="), https://bitbucket-commonmark.atlassian.io/ 404s. This issue has been open for 4 years and there is still no fix in sight, for something as trivial as rendering Markdown into HTML. Bitbucket, maybe you should try a little harder?
Also really wish this was supported. Most of our product documentation is written in HTML and then compiled into appropriate docs leaving me with either not using markdown or somehow integrating it via inline includes which is not supported by bitbucket :(
Another would be to re-write all our docs in markdown and then reverse inject into html at build but that would suck even more as we then have to convert each project :(
This is embarrassing -- my mirrored repos, from Github and Gitlab, all include README's with T.O.C links. It looks absolutely horrendous on Bitbucket and I feel sorry for any user having to interact with it from your web UI.
At this point, it's quite clear that the BB team is no longer paying any attention to this bug (or, for example, Issue #6569), so perhaps a new strategy is in order.
Don't waste your time adding new "+1"s to this report, but rather let's find out who works at BB that can influence a decision on this, and make efforts to contact her/him. If anyone has any contact info of such people, pass it along so we can directly ask them about it.
On the other hand, unless you're forced to use BB for work, maybe it's better to advocate against it and just choose an alternative service for now.
@Mark Edgington Switching to Github is what I did in the end. It's a very small thing, but as you imply, BB is not paying attention, so better be off being somewhere where they hopefully will pay attention to their product.
We use our README also in the docs that are generated by jazzy. We have tables in our README and we add some custom css classes to them inside jazzy. To do that, we can't use markdown tables (even if they were supported by bitbucket), because we need to add our classes. While GitHub and GitLab can easily deal with inline HTML, it looks crappy in bitbucket.
I only clicked on the email this time so I could unfollow 6322 because I'm tired of getting emails for an issue that obviously will not be fixed.
I have given up on anything happening here. After 5 years, how many other users might be in that bucket? How many other users like me have decided not to try other Atlassian products as a result?
@Claire Bianchi I also vote for fixing no inline HTML support as it's de facto standard violation. My use cases range from rendering of HTML comments to anchor links.
I can give you a number of very popular Markdown documents whose rendering on BB is just disaster. Their authors go with your competitors, because they simply cannot use BB as rendered Markdowns are not readable. This is where you lose users and customers.