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

Fix toggle position on mobile #85289

Merged
merged 4 commits into from
May 15, 2021

Conversation

GuillaumeGomez
Copy link
Member

Before:

Screenshot from 2021-05-14 14-21-27
Screenshot from 2021-05-14 14-21-30

After:

Screenshot from 2021-05-14 15-16-54
Screenshot from 2021-05-14 15-16-59

r? @jsha

@GuillaumeGomez GuillaumeGomez added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-rustdoc-ui Area: Rustdoc UI (generated HTML) labels May 14, 2021
@rust-highfive
Copy link
Collaborator

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 14, 2021
@GuillaumeGomez GuillaumeGomez changed the title Fix toggle position mobile Fix toggle position on mobile May 14, 2021
Copy link
Contributor

@jsha jsha left a comment

Choose a reason for hiding this comment

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

Thanks for fixing this! Note that for the 700px media, there's already this rule:

.item-list > details.rustdoc-toggle > summary:not(.hideme)::before {
  left: -10px;
}

I think that should be updated to use the same selector as the one you're updating here, and the same number of pixels. Or maybe the selector you're using here should be nested under .item-list?

By the way, what I found in #84602 (which is now out of date) was that when the exact same selector is both inside a media block and outside, they have exactly equal specificity. That is, the media block doesn't add any specificity. So whichever is last wins.

So I think the most correct and thorough fix is to make sure all "default" rules are above all media-based rules, so the media-based rules can override them.

@@ -1763,7 +1770,7 @@ details.rustdoc-toggle[open] > summary.hideme > span {
}

details.rustdoc-toggle[open] > summary::before {
content: "[]";
content: "[-]";
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the change here? I think I modeled the longer dash over what was being done with the JS-style toggles previously. I don't particularly object but it seems like an unrelated diff.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh it's because the rendering was broken in puppeteer. Do you want me to revert it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Honestly I don't have an opinion - I just made sure to use the existing long dash because I assumed you cared about it. :-) Fine to leave as-is, but should have an explanation in a commit message and/or the PR description.

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 don't really care about it to be honest. I realized it was "broken" and simply changed it when adding the test and didn't pay attention when I committed.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm pretty sure the idea is that + and − have exactly the same width. We don't want the toggle to shift around when you click it.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, gonna revert this change then.

Copy link
Contributor

@notriddle notriddle May 14, 2021

Choose a reason for hiding this comment

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

Compare these three ways of writing...

3+3| plus (U+002D)

3–3| minus (U+2212)

3-3| hyphen-minus (U+002B)

On my machine, at least, the first two are perfectly aligned, and the last is a bit narrower. This is probably the same in most fonts, since the plus and minus symbols are intended to be used together.

@@ -1697,6 +1701,9 @@ details.rustdoc-toggle > summary.hideme {
cursor: pointer;
}

details.rustdoc-toggle > summary, details.undocumented > summary {
list-style: none;
Copy link
Contributor

Choose a reason for hiding this comment

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

What necessitated this? Also, assuming we go forward with this I would rather add the rustdoc-toggle class when we emit undocumented toggles, instead of having two separate CSS selectors for this.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's because of chromium. The <details> arrow is still buggy on it so it needs extra rules.

Copy link
Contributor

Choose a reason for hiding this comment

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

chromium as opposed to chrome? or both chrome and chromium?

And what's the display bug that happens without this?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, chromium specifically, not chrome and I assume not opera/safari/edge.

As for the bug, it shows the default <details> "arrow" alongside our summary text. It doesn't break the display, just looks weird.

Comment on lines 1 to 21
goto: file://|DOC_PATH|/test_docs/struct.Foo.html
size: (434, 600)
assert: (".top-doc", "open", "")
click: (8, 280) // This the position of the top doc comment toggle
assert-false: (".top-doc", "open", "")
click: (8, 280)
assert: (".top-doc", "open", "")
Copy link
Contributor

Choose a reason for hiding this comment

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

This test seems both too fragile (depends on exact pixel offsets) and not specific enough (if the position is only off by a few pixels, the click might still succeed). Do we have access to the DOM in these tests? Can we check something like "the toggle doesn't overlap with the left side of the screen" or "the toggle's calculated left position is at least N pixels away from the left side of the screen?"

Copy link
Member Author

Choose a reason for hiding this comment

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

The framework is not that smart, it doesn't allow computation. I can eventually add a click event just 1 pixel on the right of the toggle to ensure it's not there?

Copy link
Contributor

Choose a reason for hiding this comment

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

I can eventually add a click event just 1 pixel on the right of the toggle to ensure it's not there?

You mean 1 pixel to the right of the left-hand side of the screen? That seems fine, though still brittle.

In general there are a lot of things that differ in layout between desktop and mobile layouts. I don't think it's practical to write unittests for each of them. Is there a reason to write a unittest for this one? Well, maybe, since it's regressed once so far. But in general what would a test framework look like that verified certain layout properties held on mobile vs desktop? It seems like we want an entirely different paradigm for testing that. (idle thoughts; don't need to be fixed as part of this PR :-))

Copy link
Member Author

Choose a reason for hiding this comment

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

The layout of rustdoc is supposed to not change much. By checking such small details, we can ensure that no unexpected changes ocurred (which happened way too many times ><). Let me add a click on the right and left of the toggle to ensure its position then.

@GuillaumeGomez GuillaumeGomez force-pushed the fix-toggle-position-mobile branch from 01fdb74 to dfc8b60 Compare May 14, 2021 20:25
@jsha
Copy link
Contributor

jsha commented May 14, 2021

@bors r+

@bors
Copy link
Contributor

bors commented May 14, 2021

📌 Commit dfc8b60 has been approved by jsha

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 14, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request May 15, 2021
…laumeGomez

Rollup of 12 pull requests

Successful merges:

 - rust-lang#84461 (rustdoc: Remove unnecessary `StripItem` wrapper)
 - rust-lang#85067 (Minimize amount of fake `DefId`s used in rustdoc)
 - rust-lang#85207 (Fix typo in comment)
 - rust-lang#85215 (coverage bug fixes and some refactoring)
 - rust-lang#85221 (dbg macro: Discuss use in tests, and slightly clarify)
 - rust-lang#85246 (Miner code formatting)
 - rust-lang#85253 (swap function order for better read flow)
 - rust-lang#85256 (Fix display for "implementors" section)
 - rust-lang#85268 (Use my real name)
 - rust-lang#85278 (Improve match statements)
 - rust-lang#85289 (Fix toggle position on mobile)
 - rust-lang#85323 (Fix eslint errors)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 2b5ef25 into rust-lang:master May 15, 2021
@rustbot rustbot added this to the 1.54.0 milestone May 15, 2021
@GuillaumeGomez GuillaumeGomez deleted the fix-toggle-position-mobile branch May 15, 2021 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rustdoc-ui Area: Rustdoc UI (generated HTML) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants