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 markdown > alerts via markdig #10173

Open
wants to merge 4 commits into
base: dev
Choose a base branch
from
Open

Add support for markdown > alerts via markdig #10173

wants to merge 4 commits into from

Conversation

kzu
Copy link

@kzu kzu commented Sep 5, 2024

Partial fix for #10125

Markdig supports alert blocks as documented at https://github.com/xoofx/markdig/blob/master/src/Markdig.Tests/Specs/AlertBlockSpecs.md.

Bumping markdig and adding .UseAlertBlocks() now renders the expected html.

Not sure how to go about adding the styles as needed.

@kzu kzu requested a review from a team as a code owner September 5, 2024 20:33
@kzu
Copy link
Author

kzu commented Sep 5, 2024

I guess as a test PR, it showcases that for someone that can actually run the site, it should be fairly straightforward to add support for this :)

@lyndaidaii
Copy link
Contributor

I guess as a test PR, it showcases that for someone that can actually run the site, it should be fairly straightforward to add support for this :)

Thank you for your contribution. I could help to test it.

@lyndaidaii lyndaidaii self-assigned this Sep 5, 2024
@erdembayar
Copy link
Contributor

I guess as a test PR, it showcases that for someone that can actually run the site, it should be fairly straightforward to add support for this :)

Thank you for your contribution. I could help to test it.

Thanks, Lynn. Please add screenshot here.

@erdembayar
Copy link
Contributor

@lyndaidaii
Have you had chance to test this? If not then I can do it, please let me know.

@@ -1374,20 +1374,20 @@ ul.accordion {
}

ul.accordion li.accordion-item .accordion-expand-link {
background: none!important;
background: none !important;
Copy link
Contributor

@erdembayar erdembayar Sep 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this change should have been done in .less file rather than this file?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea where things are in your code base. Feel free to close this issue which was mostly a demonstration that fixing the issue is mostly adding one line of code and whichever styles you want for the site 🙏

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would you mind pointing at which .less file you're referring to?

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NuGet/gallery-team

Do you know which less file we need to make changes to? I never change any of them.

@kzu
Copy link
Author

kzu commented Sep 13, 2024

Test should be passing now. Screenshots below.

Dark mode:

image

Light mode;

image

@kzu
Copy link
Author

kzu commented Sep 16, 2024

any updates @erdembayar @lyndaidaii ?

@erdembayar
Copy link
Contributor

any updates @erdembayar @lyndaidaii ?

Sorry, we'll review this week or at the latest next week. We have other priorities at the moment and need some time.

@lyndaidaii
Copy link
Contributor

lyndaidaii commented Sep 16, 2024

@lyndaidaii Have you had chance to test this? If not then I can do it, please let me know.

I had trouble in building gallery in local since we merged a couple of repos into one. My .NET version on dev is out of date now. Haven't checked in since then. If you could build gallery in local fine, could you help take a look at UI?

@kzu
Copy link
Author

kzu commented Sep 30, 2024

Any updates?

@erdembayar erdembayar self-assigned this Oct 1, 2024
@erdembayar
Copy link
Contributor

erdembayar commented Oct 4, 2024

Any updates?

As you can see, unit tests are passing, which is good news. However, I couldn't test the actual rendering view part because our Gallery app has a binding redirect issue due to a recent package update. We need to fix it first. In the meantime, could you please upload the NuGet package with the readme you demoed to nuget.org or share the Readme.md file with me here? It would make my testing easier.
image

@erdembayar
Copy link
Contributor

erdembayar commented Oct 4, 2024

I tested your code after we fixed our code. Could you please rebase your branch using our dev latest branch?
With my testing it seems rendering is not really working. Could you please test it yourself?

image

I used below Readme.md


## About This Project

Hello this is readme file.

[!NOTE]
This is a note 2024

@lyndaidaii
Copy link
Contributor

Looks like is missing some of css file.

@kzu
Copy link
Author

kzu commented Oct 8, 2024

@erdembayar the sample package I used is available as source (pretty bare, mind you) at https://github.com/kzu/Observable.

It's basically this readme: readme.md

And a nuspec like

<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>Observable</id>
    <version>0.2.0</version>
    <authors>Daniel Cazzulino</authors>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <license type="expression">MIT</license>
    <licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
    <projectUrl>https://github.com/devlooped/Observable</projectUrl>
    <description>Sample.</description>
    <readme>readme.md</readme>
    <tags>dotnet csharp</tags>
  </metadata>
  <files>
    <file src="readme.md" target="readme.md" />
  </files>
</package>

Observable.0.2.0.nupkg.zip

which I ran nuget pack on.

@kzu
Copy link
Author

kzu commented Oct 8, 2024

I rebased, and I'm getting proper styles:

image

The app isn't requesting anything other than the fabric.css and bootstrap.min.css:

image

And those seem to be the default alert styles in bootstrap indeed:

https://getbootstrap.com/docs/3.4/components/#alerts

That's for the right version of bootstrap in use by the gallery:

image

@erdembayar
Copy link
Contributor

erdembayar commented Oct 10, 2024

I rebased, and I'm getting proper styles:

Did you push your rebased code? I don't see any commit from October. Git history shows only commits from beginning of Sep.

Thank you for your patience. I tested your change with https://github.com/kzu/Observable and it works as shown on your screenshot for all markdowns except for Note, which I had tested previously.

image

The Note should look like the one above. Currently, as shown on your screenshot, it has no coloring.

image

Additionally, could coloring needs to be stronger? To me, it looks a bit soft. It's not blocker, it's coming from bootstrap.

Markdig supports alert blocks as documented at https://github.com/xoofx/markdig/blob/master/src/Markdig.Tests/Specs/AlertBlockSpecs.md.

Bumping markdig and adding `.UseAlertBlocks()` now renders the expected html.

Fixes NuGet#10125
If we don't unset it, the default bootstrap p style turns
dark mode illegible (uses white-ish color). This seems
to be an issue specific to the very old version of Bootstrap
being used (v3.x).

When running the site locally, I could not find any other
.css (or .less) files being built or linked from the page,
so I placed the only needed style in the only other style
file other than bootstrap.
@kzu
Copy link
Author

kzu commented Oct 15, 2024

@erdembayar what I meant is that the rebase didn't make any difference. Just in case, I just pushed anyways after a new rebase.

The NOTE will never look like that because there's no such built-in style for that in bootstrap. I have no idea where you put styles that aren't bootstrap, but if you tell me where, I can add one for NOTE since extending the alert styles is pretty easy in bootstrap. But I think this is going too far. I'm not a designer :).

The PR showcases how adding support for this is straightforward. The unit test shows that the proper classes are emitted. Now all that's left is for you to bring that note style that's used elsewhere in MS docs sites and put it somewhere you like. I didn't find any place with custom styles, which is why I just put something in the fabric.css, but I've no idea if that's the "right" place.

@kzu
Copy link
Author

kzu commented Oct 15, 2024

BTW, I'm happy to just copy over from github css the style for the above, but I've no idea if that's what you want design-wise for nuget.org :)

@lyndaidaii
Copy link
Contributor

@kzu, thank you for your contribution. Great work. No worries at all. I will work on the style.

@erdembayar
Copy link
Contributor

BTW, I'm happy to just copy over from github css the style for the above, but I've no idea if that's what you want design-wise for nuget.org :)

Thank you. It looks @lyndaidaii is going to take care of Note.

@erdembayar
Copy link
Contributor

@kzu, thank you for your contribution. Great work. No worries at all. I will work on the style.

For your reference, I found actual Note sample used in our documentation which is also markdown format.
See bottom of https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu1605, also as you can see coloring is Tip little bit different too.

image

@kzu
Copy link
Author

kzu commented Oct 15, 2024

Yeah, that looks better IMO

@erdembayar erdembayar removed their assignment Oct 15, 2024
@lyndaidaii
Copy link
Contributor

lyndaidaii commented Oct 21, 2024

I updated CSS file for alert styling, here are how it looks like with these changes.
image
image

Copy link
Contributor

@erdembayar erdembayar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lyndaidaii
Thanks for driving this to a conclusion! 👏
Maybe we can to make coloring more stronger for Alert, Tip etc, not blocking, we can do it in another PR.
Please wait for a while to let other team members review.

@@ -208,6 +208,7 @@ private RenderedMarkdownResult GetHtmlFromMarkdownMarkdig(string markdownString,
.UseTaskLists()
.UseEmojiAndSmiley()
.UseAutoLinks()
.UseAlertBlocks()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's important for the markdown dialect to use with NuGet readmes should be designed with intent, rather than ad-hoc as customers want features.

NuGet.Client is in the process of adding readme support to Visual Studio's Package Manager UI:

If nuget.org supports markdown features that VS does not, that won't be good for customers, either package consumers or package authors.

cc @jgonz120

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does that align with the readme support already there in GitHub? The alert format and markup is fairly standard at this point, I'd say...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from: https://github.github.com/gfm/

GitHub Flavored Markdown, often shortened as GFM, is the dialect of Markdown that is currently supported for user content on GitHub.com and GitHub Enterprise.

so, they admit it's a specific dialect, not some kind of reference, common, or minimal set that all markdown renders are expected to implement.

How does that align with the readme support already there in GitHub?

GitHub's markdown dialect also supports things like:

If the suggestion is that NuGet should support GFM, then these are the things that have to work as well, as well as an expectation that every time GitHub add a new markdown feature, both nuget.org and NuGet client are expected to implement it as well. I don't think these features are valuable enough to warrant the complexity to have to re-implement them in both nuget.org and VS.

So, GitHub supporting something in their dialect isn't justification to me that NuGet should support it

What concerns me is that customers will expect the readme to render the same in VS as on nuget.org. If NuGet package readmes don't render "correctly" on github.com, that would be unfortunate, but it's less important to me because it's not a primary location for viewing package readmes, and not all packages use github.

If the desire is to use a single readme as both the package readme as well as the repo readme, that's understandable, so perhaps NuGet's readme dialect could be defined as a subset of GFM. Or perhaps we can encourage package authors to make the repo readme focused on contribution instructions, how to build and debug the repo locally, stuff that's not relevant to the package readme. It's still valuable for the repo readme to have a short introduction to what the package is and how to use it, but it can then have a link to nuget.org to see the full package readme, which can have more detailed information.

The alert format and markup is fairly standard at this point, I'd say...

That's fine. Then the NuGet server team can talk to the client team, get agreement that it's feasible to support the same formatting in both. I'm just saying the server team shouldn't extend the readme markdown dialect without talking to the client team.

I'm not saying don't do it. But I believe that customers are going to get a bad experience if a package author who doesn't use VS, or doesn't test their readme in VS, writes a readme that doesn't render correctly in VS. I'm sure that customers who notice the difference will report bugs to us. What should our response be in such a case? I don't want extra support costs just because a small number of package authors of open source packages on github, want to use the readme to render the same on github and nuget.org.

Therefore, I believe the readme should be considered part of the "protocol" that should have both client and server teams agree to, not one team adding it without even talking to the other team.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the suggestion is that NuGet should support GFM, then these are the things that have to work as well, as well as an expectation that every time GitHub add a new markdown feature, both nuget.org and NuGet client are expected to implement it as well.

Not at all. But alerts are a very common documentation aid and it would be entirely unproductive to make up a brand new format, or worse, continue to NOT support it at all when it's ubiquitous even in MS learn site.

So, GitHub supporting something in their dialect isn't justification to me that NuGet should support it

The main reason would be familiarity for OSS authors, IMHO.

What concerns me is that customers will expect the readme to render the same in VS as on nuget.org.

What concerns me is that you may come up with an entirely incompatible way just for the purposes of your "nuget markdown" and force authors to learn yet another flavor rather than a subset of what they already know.

If the desire is to use a single readme as both the package readme as well as the repo readme, that's understandable, so perhaps NuGet's readme dialect could be defined as a subset of GFM.

Makes sense to be. The supported URLs in links are already one such case.

The alert format and markup is fairly standard at this point, I'd say...

That's fine.

That was the point of this PR. To showcase that it's trivial to add support for it on the gallery. You could just render plain blockquotes in VS without styling in v1 for readmes of that simplifies things. I doubt anyone will have high expectations for that readme visualization since it's a non existent feature at the moment.

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

Successfully merging this pull request may close these issues.

5 participants