GitHub Collapsible Markdown | Hacker News Reader

GitHub Collapsible Markdown

gist.github.com

74 pointskantord25 comments

Open articleView on HN

As others have pointed out, this has nothing to do with with markdown or github.

The details and summary elements are part of HTML5.

They've been implemented in WebKit and Gecko since at least 2016.

https://html.spec.whatwg.org/multipage/interactive-elements....

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

The more you know!

If you search around, there is a handful of specific GitHub markdown tricks that (for some reason) they don't officially document on their own help docs. Here is a few I found quickly searching:

- https://github.com/mxstbr/github-markdown-tricks

- https://github.com/shaunlebron/github-markdown-hacks

- https://grantwinney.com/cool-markdown-tricks-for-github/

- https://ourcodeworld.com/articles/read/162/tips-and-tricks-t...

If you just search "github markdown tricks", you'll find some others, as well.

This is HTML5; this doesn't have anything to do with GitHub or Markdown.

Markdown passes through HTML (by default), and HTML5 includes "details". Almost all browsers support it, but IE (even IE 11) does not: https://caniuse.com/#feat=details - whether or not that matters depends on your users/customers. (You may insert your complaints about IE here :-) ).

... you mean embedded HTML in a markdown file? that's nothing new.

Here's the MDN page some of the sibling comments might want to see: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de...

The “new” thing (if you didn’t know it before) is that GitHub applies a collapse/expand behavior to <details> elements.

This is an actual HTML tag, not a github thing

https://jsbin.com/timafew/edit?html,output

Isn't that the default behavior of <details> in html documents? Am I missing something?

^ this is what I mean, yeah. Isn't that the expected behavior?

Your comment is accurate but I think its the fact that GitHub styles it in that way. I do wish it was possible to use markdown-types of elements in this way so that it could fallback on non-GitHub rendered web pages, or still look good in a text editor vs. HTML tags all over the place.

Maybe something like

^ Header

^^^

Collapsed

^^^

Similar to code blocks with the ``` syntax. I dunno.

> its the fact that GitHub styles it in that way

GitHub hardly styles it at all. It applies a margin-top on top of what normalize.css does. It's 99% your browser's default style sheet at work.

First we couldn't tell the difference between git and github. Now we can't tell the difference between browsers and github.

Dependabot (owned by GitHub) uses this to great effect on their automated PRs.

Example: https://github.com/timdorr/tesla-trip/pull/107

The show the recent release notes, changelogs, and recent commit history behind what you're about to upgrade. That's immensely helpful when deciding what you want to update in your dependency list, especially if there are breaking changes. Dependency management is much less of a pain this way.

First thing I thought of. Their use is perfect.

You know what Github markdown really needs? It needs for anchors defined in it to be actual html anchors after interpretation instead of javascript dependent false anchors that don't work without code execution.

Actual HTML anchors require code execution. Like I get that there is a culture of resentment of JS on this site, but the hyperbole is a little absurd. HTML and CSS engines execute code! They can also be made to behave poorly and slowly. JS can even be used to improve those behaviors for some things. One way that's relevant to the parent comment is that scrolling to anchors can be offset to accommodate flexible-height content that obscures them in normal HTML/CSS.

I wish more people would actually use this to wrap their 5'000 lines of console output that they copy paste into a ticket when reporting a bug instead of using markdown "format as code"

Also yes it is a "hack" and not official markdown, but for the use case I mention it has the huge advantage to not make tickets including all the comments excessively long

HTML blocks are part of the commonmark spec. The overlap between people who post too much in issues and know this feature is probably small though. Other platforms have JS that detects long code blocks and collapse all but the first few lines by default.

This is cool but I would not use this at all. I think this might just decrease discoverability/readability of READMEs that are already too long/complicated.

Reducing discoverability is it's entire purpose. I use them in comments when I veer off into a tangent. It keeps a code example from taking up a ton of vertical real estate, which is nice when threads get long and old comments become irrelevant.

What’s really cool is this even works with JavaScript disabled. It’s all html5!

Anything similar for Gitlab?

The same works:

  <details>
  <summary>Title</summary>
  ...
  </details>

Yep, and it is documented in https://docs.gitlab.com/ee/user/markdown.html#details-and-su...

This isn't markdown, it's HTML. For the love of God please don't do this. We already have HTML.

Emacs has been able to collapse markdown for a long time now. There's no reason why that can't be implemented in other renderers.

Reply on news.ycombinator.com