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: #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: #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: #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: #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>
Kindly,
This fixes issue I created #60 . Note that both z-indexes had to be removed because when I kept either of them, there was still z-fighting issues.
Considering that .dropdown-actions is used elsewhere, I tested the changes also on these pages and it still (TM) works on my machine (TM).
./files/templates/home_comments.html <----- Didn't test on /comments because disabled but it is same as search.html AFAIK
./files/templates/home.html
./files/templates/log.html
./files/templates/search.html
./files/templates/submission.html
./files/templates/userpage/header.html
Reviewed-on: #96
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Previous behavior on submission_listing was clicking a thumbnail would
toggle an inline video player. This was retained for clicking the
thumbnail off the `.video-play` element; however, directly clicking
the `.video-play` did not have the `toggleVideo` onclick event attached
and would navigate the browser to the video file directly.
Aevann
mummified-corroding-granny
justcool393
Snakes