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

Add support for lists in attribute docstrings in markdown renderer #118

Open
aiuto opened this issue Jan 24, 2022 · 6 comments
Open

Add support for lists in attribute docstrings in markdown renderer #118

aiuto opened this issue Jan 24, 2022 · 6 comments

Comments

@aiuto
Copy link
Contributor

aiuto commented Jan 24, 2022

I want to be able to write a docstring that presents as

The attribute foo must be one of:

  • a: ...
  • b: ...

The markdown renderer puts attributes in rows of a table, but does something like

foo|The attribute foo must be one of: - a: ... -b: ... | ...

That does not render correctly because the newlines are stripped.

The standard hack for this in markdown is to embed <li>, but then stardoc escapes the element.

foo|The attribute foo must be one of: &lt;li&gt;a: ...

I think the general principal is that if you are in one language (markdown) then you should not escape things as if it were the other language (HTML).

@aiuto
Copy link
Contributor Author

aiuto commented Feb 8, 2022

Possibly a dup of #78

@brentleyjones
Copy link

I just ran into this as well. There is no way to get this to render as a list 😢

@tetromino
Copy link
Collaborator

tetromino commented Jul 25, 2023

#167 will allow html markup in table cells, so that one can at least work around the problem

tetromino added a commit that referenced this issue Aug 1, 2023
… apply it properly (#167)

In Markdown table cells, apply HTML escaping only to code blocks, and apply it properly

Since #161 removed HTML escaping for defaults and function docstrings, we should do the same for attribute and param docs in table cells.

The only limitations Markdown places on table cells are:
* no pipe characters (they must be escaped with a backslash)
* no newlines (they must be transformed into `<br>` or an HTML entity)

The latter restriction makes it impossible to have a fenced code block inside a table cell.

Therefore:
* we do not escape HTML or Markdown markup outside a fenced code block
* we keep existing logic for escaping newlines outside a fenced code block
* we fix fence detection (e.g. allowing more than 3 fence characters to support embedded code blocks in code blocks, allowing tildes as fence characters, properly handling language names, etc.);
* in code block content, we escape HTML, and we escape newlines as HTML entities (since `<br>` does not work in a `<pre><code>` block) - finally fixing code block newlines in table cells.
    
This is a followup to #161.

Partially addresses #118
@alexeagle
Copy link
Contributor

For Aspect's rulesets, our solution for this is to treat the stardoc markdown view as the "not very good presentation layer". For example https://github.com/aspect-build/rules_ts/blob/main/docs/rules.md#ts_project-srcs suffers from this problem, appearing as a paragraph that's possible but not easy to read:

  • Include all TypeScript files in the package, recursively. - If allow_js is set, include all JavaScript files in the package as well. - If resolve_json_module is set, include all JSON files in the package, but exclude package.json, package-lock.json, and tsconfig*.json.

Then we provide a much better documentation experience, akin to how https//:bazel.build documents the core Bazel libraries in a website rather than relying on stardoc markdown to produce a nice presentation on GitHub's UI. Ideally I think the Bazel project could host a docsite like https://about.readthedocs.com/ does for python or https://pkg.go.dev/ does for Go. But in the spirit of not waiting for Google, we already built that. Continuing that example above, you see the same srcs list renders properly on https://docs.aspect.build/rules/aspect_rules_ts/docs/rules#srcs-1

@aiuto
Copy link
Contributor Author

aiuto commented Sep 26, 2023

Can you contribute that renderer level back to stardoc? It is so much more convenient to depend on one documentation tool rather than a fwe of them.

@alexeagle
Copy link
Contributor

I think it's pretty complicated to contribute since it's wired up with our docusaurus docsite and node-based rendering pipeline. Also every time I try to contribute here I get stuck pinging Googlers for a year, honestly I gave up, and I have more tenacity than most. Let's get a DevRel on the project 😉

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

No branches or pull requests

4 participants