| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This was added to control percentage sizes, in
79956b96e875e6ba2bfa551fabda6b7896f988ac
Now, the only percentage size is [`border-radius`], which is
based on the size of the box itself, not its containing block.
This leaves the property unused.
[`border-radius`]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius
|
|
|
|
This code was added back when `border-color: currentColor` was used.
Since it was changed in ad9a89eef2857a24ef049b9eee2d1db5bcbf1d11, the
current color is not used any more.
|
|
This is very dependent on subjectivity and what screen you use,
but this change makes the radio buttons' outer circle less ugly.
This is because I could see the pixels very clearly, thanks to the
very thin line and high contrast. This change makes both less
severe, giving your browser's antialiasing algorithm more to
work with. Since it's thicker, lowering the contrast shouldn't
impact visibility.
|
|
These rules were needed for the mobile-style switches, but those
were removed in 0f3ae6218ef1d9e9b14bf983b463785b14abc205
|
|
* Changes the class names so that they all start with `setting-`.
That should make it harder to accidentally use a setting class outside
the settings popover, where loading the CSS might accidentally change
the styles of something unrelated.
* Get rid of an unnecessary wrapper DIV around the radio button line.
* Simplify CSS selectors by making the DOM easier and more intuitive
to target.
|
|
This uses less code to lay them out the same way.
|
|
Since the current version of settings.js always nests things below
a div with ID `settings`, this rule always overrode the one above.
|
|
|
|
This swaps things around so that the class that gets used more often has
the shorter name.
|
|
Obsoleted when 9625ed8be7fa66c3ee5f78180a3d5911817096f6 changed the DOM.
|
|
The switch is designed to give the application a "physical" feel, but
nothing else in here really followed through. They didn't support the
"flick" gesture that real iOS switches support, and the radio
buttons that were also used in Rustdoc Settings were a more "classic"
form element anyway.
Also, while "switches" are the exclusive toggle design on iOS (since
[Apple HIG] reserves checkboxes for Mac only), the [Google Material]
guidelines say that lists of switches are bad, and you should just use
check boxes.
[Apple HIG]: https://developer.apple.com/design/human-interface-guidelines/components/selection-and-input/toggles
[Google Material]: https://m3.material.io/components/checkbox/guidelines#6902f23d-ceba-4b19-ae3b-b78b9b01d185
|
|
|
|
These rules were copied from normalize.css 3, and are mostly redundant.
* `optgroup` isn't used in rustdoc at all
* `textarea` is only used for the "copy" button, so it's not visible
* The remaining buttons and inputs mostly have styles set anyway.
* We should never be setting `color` without also setting the
background to something. Otherwise, you get white-on-gray
text. That seems to be [the reason] why `normalize.css` changed this.
[the reason]: https://github.com/necolas/normalize.css/pull/502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously, the radio button choices for themes would wrap awkwardly on
narrow screens. With this change, the group of choices will prefer
bumping down to the next line together, leaving the setting name on its
own line.
Also fix some minor spacing issues:
- Align the setting name vertically with the radio button choices.
- Use margin instead of padding for most spacing choices.
- Use no margin/padding on the right-hand side.
|
|
This reduces the number of clicks required to change theme.
Also, simplify the UI a bit (remove setting grouping), and add a "Back"
link close to the settings icon.
|
|
|
