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

doc: CSS improvements #10849

Merged
merged 2 commits into from
Dec 13, 2013
Merged

doc: CSS improvements #10849

merged 2 commits into from
Dec 13, 2013

Conversation

adrientetar
Copy link
Contributor

rustdoc:

  • fix search-bar layout

doc: CSS:

  • switch to native pandoc toc depth
  • rm some dead code
  • clamp width to be readable (we're not Wikipedia!)
  • don't background-color titles, it's bloating
  • make syntax-highlighting colors inline with rust-lang.org
  • space indents

@alexcrichton

Now with broader compatibility.
@alexcrichton
Copy link
Member

Do you have a preview of that the CSS changes look like?

@adrientetar
Copy link
Contributor Author

@alexcrichton Yes, I've updated my copy.
No design changes for rustdoc, it should hopefully stack-up properly this time (I think it's done).

@SiegeLord
Copy link
Contributor

When I added backgrounds to the titles, it was to improve readability. I do not think the underlines work as well. Either way, the new heading padding looks bad.

@adrientetar
Copy link
Contributor Author

@SiegeLord I do think we shouldn't put too much emphasis on titles, it interferes with the actual content. Also titles with background make too much clutter esp. when you have lots of titles with not so much content.
If you look at, say Bootstrap or GitHub, they all use that kind of style.

Now don't get me wrong, I'm not set on that formatting, just thought about moving on from what we have now.
Either way, I can't see where's the primitive importance of titles. I can't think of any reason why they need to be put into blocks, because when you read documentation, you're either reading it linearly and it's content-driven, or you're looking at a specific section and you know what you're reading. In both cases, I don't see the need to make the titles stand out above all.

Have any suggestion for the paddings? Thought it looked good that way. Lower elements (h4+) are just underlined and have less padding so that it looks smaller without putting too much offset.

@alexcrichton
Copy link
Member

cc @brson

@adrientetar
Copy link
Contributor Author

Maybe a Godoc-like style should be able to put a discrete emphasis on the titles.

@brson
Copy link
Contributor

brson commented Dec 9, 2013

@adridu59 Thanks! I like that this makes the home page and the docs more consistent. Let's keep iterating.

@adrientetar
Copy link
Contributor Author

Oh right pandoc's too old for the toc-depth switch.

@adrientetar
Copy link
Contributor Author

r? @alexcrichton

Commited rust-lang/prev.rust-lang.org@9bda6bc as a bonus.

bors added a commit that referenced this pull request Dec 13, 2013
rustdoc:
- fix search-bar layout

doc: CSS:
- switch to native pandoc toc depth
- rm some dead code
- clamp width to be readable (we're not Wikipedia!)
- don't background-color titles, it's bloating
- make syntax-highlighting colors inline with rust-lang.org
- space indents

@alexcrichton
@bors bors merged commit 1999b25 into rust-lang:master Dec 13, 2013
@adrientetar adrientetar deleted the patch-css branch December 15, 2013 11:49
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jun 2, 2023
Remove lint name and category fields from the new lint issue form

changelog: none

Picking a name/category is something the implementers/reviewers tend to cover anyway, I think asking people to come up with it at the time of their suggestion is more of a barrier than it's worth

Inspired by the mention in rust-lang#10849
flip1995 pushed a commit to flip1995/rust that referenced this pull request Aug 24, 2023
new lint: `implied_bounds_in_impls`

Closes rust-lang#10849

A new lint that looks for explicitly specified bounds that are already implied by other bounds in `impl Trait` return position types.
One example, as shown in the linked example, would be
```rs
fn foo<T>(x: T) -> impl Deref<Target = T> + DerefMut<Target = T> {
    Box::new(x)
}
```
`DerefMut<Target = T>` requires  `Deref<Target = T>` to be wellformed, so specifying `Deref` there is unnecessary.

This currently "ignores" (i.e., does not lint at all) transitive supertrait bounds (e.g. `trait A {} trait B: A {} trait C: B {}`, then having an `impl A + C` type), because that seems a bit more difficult and I think this isn't technically a blocker. It leads to FNs, but shouldn't bring any FPs

changelog: new lint [`implied_bounds_in_impls`]
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