(Translated by https://www.hiragana.jp/)
Add CSS to make top doc box have a fade, rather than hard cutoff by thomaspurchas · Pull Request #570 · apple/pkl · GitHub
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 CSS to make top doc box have a fade, rather than hard cutoff #570

Merged
merged 1 commit into from
Jul 8, 2024

Conversation

thomaspurchas
Copy link
Contributor

@thomaspurchas thomaspurchas commented Jul 7, 2024

The current hard cutoff in the docs often results in people not realising that the doc box can be expanded, and often resulting in confusion because the most helpful examples are often in the module doc box.

This change uses some simple CSS tweaks to replace the hard cut-off with a visualfade, so it's obvious that there's content hidden out of view. Doing this required removing the CSS transition, as it hard to correctly transition the height property of CSS element of unknown target height. But the improved discoverablility of the doc content seems like a worthwhile tradeoff.

Before:
image

After:
image

The current hard cutoff in the docs often results in people not
realising that the doc box can be expanded, and often resulting in
confusion because the most helpful examples are often in the module doc
box.

This change uses some simple CSS tweaks to replace the hard cut-off with
a visualfade, so it's obvious that there's content hidden out of view.
Doing this required removing the CSS transition, as it hard to correctly
transition the height property of CSS element of unknown target height.
But the improved discoverablility of the doc content seems like a
worthwhile tradeoff.
Copy link
Contributor

@StefMa StefMa left a comment

Choose a reason for hiding this comment

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

Nice one!
I also stumbled over this in the past.

However, I am not sure if there is an easier way to make this more visible to users... 🤔

My idea would be to move the arrow from top left to bottom center. I guess this is where the most people would expect an "expand/collapse indicator", didn't they?

I am not an ux/ui expert. I also have only limited knowledge about css. Just wanted to share my thoughts on this. ☺

@thomaspurchas
Copy link
Contributor Author

thomaspurchas commented Jul 7, 2024

@StefMa agree there better ways to do this. But this change only requires a few lines of CSS, so it’s quick and easy todo. I don’t consider this “good”, just better than what we have, and a solution that I could implement quickly in my spare time.

If people have suggestions for improvements, please submit a PR! Ideally I would want to do something similar to go docs, but that’s a much bigger effort than I have time for right now.

Copy link
Contributor

@holzensp holzensp left a comment

Choose a reason for hiding this comment

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

I agree with @StefMa; moving the carrot might be an even bigger improvement. That said, this is undoubtedly already an improvement for discoverability, so... if anyone wants to work on further improvements, yes please. Until then; let's ship this.

Thanks @thomaspurchas!

@holzensp holzensp merged commit cdf548c into apple:main Jul 8, 2024
4 checks passed
@thomaspurchas thomaspurchas deleted the improved-doc-box branch July 8, 2024 14:16
@StefMa
Copy link
Contributor

StefMa commented Jul 8, 2024

Just wanted to refer to this lines as I guess this is relevant in case we want to move the arrow 🙃

Also this one

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.

None yet

3 participants