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

[docs] Docs redesign adjustments #28203

Merged
merged 21 commits into from
Sep 10, 2021
Merged

Conversation

mnajdova
Copy link
Member

@mnajdova mnajdova commented Sep 7, 2021

Some adjustments in mind (mostly minor stuff):

  • "Refactoring" the Edit this page button: it is currently absolute positioned. Maybe it's best to have it in a flex container together with the title and description of the page for a safer responsive behavior. Here's an example of what I described.
  • Adjustments on sidenav alignment and for better-nested items, e.g: date-time picker. Here's the Figma mockup.
  • Tweak the settings drawer background color in dark mode, it is too light now. Here's the Figma mockup.
  • Get the mode toggle button in the settings drawer with capitalization (currently all lowercase).
  • Adding the bold weight for Jakarta Sans to use in headings smaller than h2.
  • Adjust ad container alignment with the rest of the page elements. It's slightly off.
  • Iterate to have an inline code for titles and normal paragraphs?! It gets messy when there's one in a heading.
  • Have the Templates and Blog links, on the Nav Drawer, with the same styles as all the others: box with an icon + arrow. On the example below, I'm using the BookOutlined and ChromeReaderModeOutlined icons. Also, make the typography variant the same and with the dividing lines.
Ad container alignment Inline code in headings
Screen Shot 2021-09-07 at 11 06 45 Screen Shot 2021-09-07 at 11 06 45

@mui-pr-bot
Copy link

mui-pr-bot commented Sep 7, 2021

No bundle size changes (experimental)

Generated by 🚫 dangerJS against afbbfad

@mnajdova

This comment has been minimized.

@mnajdova mnajdova changed the title [docs] Redesign sidebar polish [docs] Docs redesign adjustments Sep 7, 2021
@danilo-leal

This comment has been minimized.

@siriwatknp

This comment has been minimized.

Comment on lines -24 to -29
const DrawerPaper = styled(Paper)({
width: 360,
borderTopRightRadius: 0,
borderBottomRightRadius: 0,
});

Copy link
Member

@siriwatknp siriwatknp Sep 8, 2021

Choose a reason for hiding this comment

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

@mnajdova we might need to investigate more on this, it is very buggy and hard to reason. by using styled component and pass to <Drawer PaperProps={{ component: DrawerPaper, square: true, elevation: 0 }}, it is still rounded.

Copy link
Member

@siriwatknp siriwatknp Sep 8, 2021

Choose a reason for hiding this comment

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

also classname got double. elevation-1 elevation-0

Screen Shot 2564-09-08 at 13 52 37

Copy link
Member Author

Choose a reason for hiding this comment

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

Will take a look thanks for pointing it out. I think that the general problem is that the portaled components don't support the components & componentsProps which would replace the components underneath instead of aliasing it to the as property (which is what we currently do).

Copy link
Member Author

Choose a reason for hiding this comment

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

Currently what you have is: <StyledPaper as={AnotherStyledPaper} /> - which results in double classes and non-deterministic classes order in the head.

Copy link
Member Author

Choose a reason for hiding this comment

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

I would probably just set the sx prop :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Ok, we need to have some story around this in the migration guide I think. I agree it is hard to reason about.

In v4 when you provide a component it was changing the element that is rendered, but it also was adding the classes for that element, so the styles were applied.

In v5, to make it work identical, we are mapping the component prop to the as prop, so that the styles defined originally in the component would still be applied. This however does not guarantees that the styles for the component defined via the as property would win.

I think that we should specify in the migration guide, that for cases like this, when SomeComponentProps is used, we recommend sx for overriding the styles. When we add the components & componentsProps API on all components, that would add a possibility for completely replacing that slot with a new component. Note that the new component can actually be a styled version of the original component, and in that case we would be able to actually override the styles for it.

Does this summary makes sense?

Copy link
Member Author

Choose a reason for hiding this comment

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

Here is a sandbox illustrating the current behavior https://codesandbox.io/s/magical-mahavira-6p39p?file=/src/App.js

@siriwatknp

This comment has been minimized.

@siriwatknp
Copy link
Member

inline code

Is reducing font-size helps? @danilo-leal

Screen Shot 2564-09-09 at 09 54 33

@danilo-leal
Copy link
Contributor

"Refactoring" the Edit this page button

Can't make the edit page button as a part of title because the title is generated from markdown, so I make it a block instead of absolute. @danilo-leal

Way better! Thank you, Jun!

@danilo-leal
Copy link
Contributor

danilo-leal commented Sep 9, 2021

inline code

Is reducing font-size helps? @danilo-leal

Mm... Not so much I guess. I think it's more about the font-weight than anything. Ideally, we should be able to set different font-weights depending on the application of the inline code (heading or paragraph). Is it feasible?

@siriwatknp
Copy link
Member

siriwatknp commented Sep 9, 2021

inline code

Is reducing font-size helps? @danilo-leal

Mm... Not so much I guess. I think it's more about the font-weight than anything. Ideally, we should be able to set different font-weights depending on the application of the inline code (heading or paragraph). Is it feasible?

@danilo-leal so font-weight bold for inline code in the heading?

@danilo-leal
Copy link
Contributor

Mm... Not so much I guess. I think it's more about the font-weight than anything. Ideally, we should be able to set different font-weights depending on the application of the inline code (heading or paragraph). Is it feasible?

@danilo-leal so font-weight bold for inline code in the heading?

We could try that, can you make an iteration of it to see how it goes?

@siriwatknp

This comment has been minimized.

@danilo-leal
Copy link
Contributor

We could try that, can you make an iteration of it to see how it goes?

I still think that code font-size should be smaller.

Iterated a bit more, reducing just a tad the font size and standardizing the color. I think we're good to do with this one!

@siriwatknp siriwatknp merged commit 52eaf9d into mui:next Sep 10, 2021
@zannager zannager added the docs Improvements or additions to the documentation label Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Improvements or additions to the documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants