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

Render @:api directive like code (backtickified) ? #285

Closed
armanbilge opened this issue May 1, 2022 · 3 comments · Fixed by #327
Closed

Render @:api directive like code (backtickified) ? #285

armanbilge opened this issue May 1, 2022 · 3 comments · Fixed by #327
Milestone

Comments

@armanbilge
Copy link
Member

This is a very tiny, very personal preference :) In general I feel like code things such as APIs should be in backticks. This is how many existing docs are as well, and it would be nice to migrate them to use this directive.

Probably also applies to @:source directive, but I haven't tried that.

Thanks for considering!

@jenshalm jenshalm added this to the 0.19.0 milestone May 2, 2022
@jenshalm
Copy link
Contributor

jenshalm commented May 2, 2022

I can have a look. I'm mildly worried it looks too similar too un-linked code spans then, but if that's not the case I can change it.

If not, the minimum I should do (and I just realized that when I checked the directive's impl) is to assign a class attribute to these kind of special links, e.g <a class="api"...) so that you can curlybracify it into backtickification with a single line of CSS as a default within sbt-typelevel, if that's something you'd find greentickable as a plan B.

@armanbilge
Copy link
Member Author

I'm mildly worried it looks too similar too un-linked code spans then

Yes, in my experience they do look the same unfortunately 😕 enabling CSS customization is a very reasonable fix as well 👍

I do wonder now if these should be rendered differently. Like an ordinary code span, except with a link icon or something to make it more obviously it's a link.

@jenshalm
Copy link
Contributor

jenshalm commented May 2, 2022

Yes, maybe. Nice thing is we can freely play around with it once the CSS classes are there, and then still change the default later. Since it's something I can do during the 0.19 maintenance cycle, I won't invest time before the release (beyond adding the class).

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

Successfully merging a pull request may close this issue.

2 participants