refactor(v2): reduce vertical space in doc content container

[lex111]

Motivation

At the moment, doc content is positioned bit lower compared to doc sidebar content, this inconsistency in these two columns is a bit disturbing to the eye. If you look at the blog layout, there is no such issue, so I suggest eliminating this visual discrepancy.

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

Before:

After:

Related PRs

(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/facebook/docusaurus, and link to your PR here.)

[netlify]

✔️ [V1]

🔨 Explore the source changes: 757a065

🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-1/deploys/60b9c8d48ff56d000889f203

😎 Browse the preview: https://deploy-preview-4877--docusaurus-1.netlify.app

[netlify]

✔️ [V2]

🔨 Explore the source changes: 757a065

🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/60b9c8d4f60fbc0008679b10

😎 Browse the preview: https://deploy-preview-4877--docusaurus-2.netlify.app

[github-actions]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🟠 Performance	56
🟢 Accessibility	97
🟢 Best practices	100
🟢 SEO	100
🟢 PWA	95

Lighthouse ran on https://deploy-preview-4877--docusaurus-2.netlify.app/

[github-actions]

Size Change: +1.16 kB (0%)

Total Size: 621 kB

Filename	Size	Change
website/build/assets/css/styles.********.css	88.4 kB	+244 B (0%)
website/build/assets/js/main.********.js	443 kB	+513 B (0%)
website/build/blog/2017/12/14/introducing-docusaurus/index.html	62.3 kB	+201 B (0%)
website/build/index.html	27.1 kB	+201 B (+1%)

ℹ️ View Unchanged

Filename	Size	Change
website/build/docs/introduction/index.html	235 B	0 B

_{compressed-size-action}

[slorber]

Not sure to understand why but I see also a difference in the width of the container (using a large 27" screen):

• https://docusaurus.io/docs/
• https://deploy-preview-4877--docusaurus-2.netlify.app/docs/

Before:

After:

Not a big deal imho, just wanted to highlight a potentially unwanted side-effect (due to margin collapsing maybe?)

---

Apart that, I'm not too fan of this change, I prefer to keep the additional top margin, but it's probably a matter of taste.

@yangshun any opinion?

[lex111]

I see also a difference in the width of the containe

This was done by mistake, but point of this PR is to align contents of both columns (doc sidebar and doc content) on the same visual line, as shown in the screenshot above (see MkDocs as reference below).

[lex111]

I'm also wondering, maybe we can remove the small horizontal padding from the doc content (docItemContainer) itself? We already set large padding in wrapper (docItemCol), so why add extra padding for block inside it?

Before	After

As you can see, after that a bit more content can fit into doc container without line breaks, so it is especially useful on mobiles.

UPD: Moreover, in v1, the two columns were also aligned.

[slorber]

I'm totally ok to align content on a vertical line, but it just feels weird that the content, sidebar and toc are so close to the navbar. I feel this PR removes some spacing that may be important.

V1 and MkDocs both have more spacing:

However not sure how to add this spacing considering v2 sidebar implementation.

Let's merge this for now but we can see later if there's a way to improve.

[slorber]

I'm also wondering, maybe we can remove the small horizontal padding from the doc content (docItemContainer) itself? We already set large padding in wrapper (docItemCol), so why add extra padding for block inside it?

Yes I think we can remove a duplicate padding, one is enough

[infotexture]

not sure how to add this spacing considering v2 sidebar implementation

@slorber I share your preference for the top alignment and was able to achieve the desired effect with additional top padding on nav.menu. There may be something I'm not aware of, but at first glance it seems to solve the problem.

[slorber]

Yes just tried tat locally and it looks fine.

I guess it's a matter of taste then. As long as users can achieve this easily with custom CSS, that should be fine