Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/pkgsite: render mermaid js #67339

Closed
trajan0x opened this issue May 13, 2024 · 11 comments
Closed

x/pkgsite: render mermaid js #67339

trajan0x opened this issue May 13, 2024 · 11 comments
Labels
Milestone

Comments

@trajan0x
Copy link

trajan0x commented May 13, 2024

What did you do?

Going to add feature request here.

While not formally included in the Github-Flavored Markdown Spec, Github supports mermaid diagrams

Given there's no good way to force these not to render on pkg.go.dev, but do render in readme's I think it'd be best if pkg.go.dev supported them.

I'll use one example from my project on how the ux can be sub-optimal otherwise.

We have a git-change-detector for go workspaces where a lot of the readme looks like this:

image

But on pkg.go.dev, it looks like this:

image

Anyway, would definitely be a nice to have

What did you see happen?

N/A

What did you expect to see?

N/A

@gopherbot gopherbot added this to the Unreleased milestone May 13, 2024
@nnzv
Copy link

nnzv commented May 14, 2024

Supporting Mermaid.js in pkgsite would likely introduce unnecessary complexity and potential performance issues without significant benefits for Go developers.

@AlexanderYastrebov
Copy link
Contributor

AlexanderYastrebov commented May 15, 2024

Maybe it makes sense to add codeblock language id to <pre>/<code> tags to enable userscript-based highlighting/rendering.

Update: this should actually work https://github.com/rsc/markdown/blob/0bf8f97ee8ef6dc359b2246680d8f48c37da77f1/code.go#L24-L39
maybe pkgsite uses old rsc.io/markdown version.

@gopherbot
Copy link

Change https://go.dev/cl/585955 mentions this issue: sanitizer: allow code block language class

@AlexanderYastrebov
Copy link
Contributor

AlexanderYastrebov commented May 16, 2024

With the change https://go.dev/cl/585955 it should be possible to enable syntax highlighting and mermaid rendering via UserScript:

// ==UserScript==
// @name        pkg.go.dev syntax highlight
// @namespace   Violentmonkey Scripts
// @description Adds syntax highlighting to code blocks
// @match       https://pkg.go.dev/*
// @resource    css https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/styles/github-dark.css
// @require     https://cdnjs.cloudflare.com/ajax/libs/highlight.js/11.9.0/highlight.min.js
// @require     https://cdn.jsdelivr.net/npm/mermaid@10.9.1/dist/mermaid.min.js
// @grant       GM_addStyle
// @grant       GM_getResourceText
// @version     1.0
// @author      https://github.com/AlexanderYastrebov
// ==/UserScript==
GM_addStyle(GM_getResourceText("css"));
(function (){
    hljs.highlightAll();
    mermaid.initialize({ startOnLoad: false, theme: 'dark' });
    mermaid.run({ querySelector: '.language-mermaid' });
})();

Screenshot from 2024-05-16 04-02-27

Screenshot from 2024-05-16 04-00-10

@matloob
Copy link
Contributor

matloob commented May 16, 2024

I don't know if it's worth making the change in https://go.dev/cl/585955 if it's only going to be used by users who enable a custom script locally.

@zikaeroh
Copy link
Contributor

Supporting Mermaid.js in pkgsite would likely introduce unnecessary complexity and potential performance issues without significant benefits for Go developers.

Given mermaid code blocks look like:

```mermaid
...
```

It seems reasonable to assume that the server/page could just not load mermaid code when there's no mermaid blocks, so I don't think this would have any overhead, no?

@AlexanderYastrebov
Copy link
Contributor

I don't know if it's worth making the change in https://go.dev/cl/585955 if it's only going to be used by users who enable a custom script locally.

@matloob
What is the problem or risk to enable already existing codeblock language metadata?
Userscript is the straightforward usecase but there might be others like hints to the crawlers or corporate pkgsite deployments with syntax highlight by default.

@nnzv
Copy link

nnzv commented May 16, 2024

I don't know if it's worth making the change in https://go.dev/cl/585955 if it's only going to be used by users who enable a custom script locally.

Absolutely, that sounds like a more appropriate approach. By utilizing a script to generate necessary files from upstream sources, you can easily place the URL file where pkgsite can display it. This strategy enables flexibility with various tools, eliminating the need to confine yourself to just one option.

@adonovan
Copy link
Member

We discussed this in our triage meeting and decided that the benefit of the feature is not worth the costs and risks. Go's pkg.go.dev site was never intended to fully simulate GitHub's markdown renderer.

@AlexanderYastrebov
Copy link
Contributor

@adonovan @matloob What are the risks of adding a css class to the html element?

@adonovan
Copy link
Member

@adonovan @matloob What are the risks of adding a css class to the html element?

The costs and risks of adding a class attribute are very low, though the value seems low also. I would not object to https://go.dev/cl/585955, though I defer to @matloob.

The feature I was referring to as "not worth the costs and risks" is the mermaid rendering that is the subject of this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants