Kindly,
Currently, the vote count at the top left of any post reserves too little space leading to many reflow situations when we vote on it:
* only happens on desktop version, considering the mobile website uses different layout/code
* happens whenever our vote changes the count between 9 to 10 (?), 99 to 100, 999 to 1000. Also happens in more common situations like 81 to 82 and :marseymanysuchcases:
I did a minimalist approach by removing the margin, reserving just enough width (values between -XXX and XXXX) and lowering the vote buttons to minimize hat collision. Arguably, the vote buttons look better with the PR, because they are centered with flairs (WPD) and less off-center on rdrama with post rewards, pfp, ...
Net excess of ~10px, which I feel is borderline too much
Thanks,
granny
Reviewed-on: rDrama/rDrama#131
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Kindly,
In most pages where there are tables containing usernames, there is a space between the user icon and the username that gets underlined on hover. It happens in most tables in this app (applies both to rdrama and WPD). That automatic whitepace appears to come from the usual HTML default space between inline elements. The alternative is to change inheritence but appears cumbersome.
This PR fixes that.
Affected pages (those that render user_in_table.html):
./files/templates/admin/alts.html
./files/templates/admin/loggedin.html
./files/templates/admin/lottery.html
./files/templates/admin/patrons.html
./files/templates/admin/shadowbanned.html
./files/templates/admins.html
./files/templates/banned.html
./files/templates/chuds.html
./files/templates/grassed.html
./files/templates/hats.html
./files/templates/leaderboard.html
./files/templates/marseys.html
./files/templates/poll_votes.html
./files/templates/settings/security.html
./files/templates/special/worldcup22_leaderboard.html
./files/templates/sub/blockers.html
./files/templates/sub/exilees.html
./files/templates/sub/mods.html
./files/templates/userpage/blockers.html
./files/templates/userpage/followers.html
./files/templates/userpage/following.html
./files/templates/userpage/views.html
./files/templates/userpage/voters.html
./files/templates/votes.html
Thanks,
Granny
Reviewed-on: rDrama/rDrama#130
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Kindly,
Seems strange that posts can use nested lists with increased padding at each level while comments do not have any padding on the nested lists
EDIT: disregard branch name. A bit tipsy and just used the branch that I had in my hand
Reviewed-on: rDrama/rDrama#117
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
fix-small-tisms that I had piled up in my todo
Reviewed-on: rDrama/rDrama#109
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
I noticed there are some over-interactive tables in general on rdrama. Particularly, multiple columns in the shop tables (awards and hats), which allow you to sort by buttons, icons, … The one page for user profile views also comes to mind, because it uses relative time since last visit, is paged server-side and browsers do not know how to sort that type of data anyway.
Also I noticed there are some tables that have disabled sorting by using <td> instead of <th> for the headers as is the case of the following pages:
* @uid/followed
* @uid/following
All of these situations are accounted for but need to be changed later in a different PR, because I can't right now.
For example, the "Buy" column of the shop can be changed to the following to disable sorting:
`<th class="disable-sort-click">Buy</th>`
Reviewed-on: rDrama/rDrama#107
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Small lil PR to reduce/minimize overscroll (aka scroll chaining) when scrolling to the end of scrollable modals. Also relevant to mobile
Primary targets:
- GIFs scrollable tabs body
- EMOJI scrollable tabs body
- AWARDS scrollable tabs body
Should (TM) apply to other scrollable modals if the same HTML structure is used
Very important notes (TM):
* this does not apply to non-scrollable modals (e.g. delete and report)
* this only applies to the body of the modal where scrollable content is usually located (as per selector). Example of when it does not apply:
* if we try to scroll near the search bar (e.g. on GIFs modal), we will still scroll the background
* if we make the modal non-scrollable (e.g. limited search in emoji or its tabs), there is no overscroll protection
Why I chose this implementation:
* I have implemented this recently when all browsers started supporting it in the last months of 2022
* we cannot just disable the main body/html element scrollbar because it is likely to create headache-inducing content redraw situations
* minimalistic and it is a relatively modern way to do it
* about 300% better than some client-side javascript spaghetteh to avoid content redraws
* methodical alternative is to reimplement site-wide modals/scrolling (LMAO)
* I did not apply it to .modal-body because it does not work when we scroll in the empty area on the sides of the scrollable area (which I always do).
Reviewed-on: rDrama/rDrama#100
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>