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: #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: #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,
Just a small lil PR to make sure the chat counts keep synchronized in /chat as users come and go
Thanks,
granny
Reviewed-on: #122
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,
As per $title:
* we add a button to the first column of each row of /formatting programatically
* programatically because table is subject to change and tedious/complicated to write it for each row
* clicking on button copies text of second row to clipboard (reusing toasts code)
* did some javascript replacing because of preserving newlines and removing extraneous tabs
Thanks,
granny
Reviewed-on: #120
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,
As per $title. This is just a suggestion implementation
Whenever we click any marsey in the speed modal, it generates an error in developer tools console because markdown() is not defined. I suspect not being available is expected because that function is for re-rendering the markdown preview (????? when I look at chat code it is all spaghette to me)
Thanks,
granny
Reviewed-on: #119
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: #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>
* about the rdrama_rules, when I changed from http:// to https:// the other day, in some browsers it now displays the protocol tag which is ugly and inconsistent. Not sure why on some browsers it did not display "http://" before
* about the sorting: I will disable sorting on more table columns later on. This is all I can do right now
Reviewed-on: #112
Co-authored-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
Co-committed-by: mummified-corroding-granny <mummified-corroding-granny@noreply.fsdfsd.net>
We currently cannot see (toggle the dropdown/button) reports that are hidden behind the "show more" (comments) button. This PR fixes that.
Example of what is happening without this PR:
1. open megathread. The thread is long includes hundreds of comments implying need to click "show more" (comments) button
2. without clicking any "show more" (comments) button, click the flaggers button on one of the first comments
3. flaggers are presented as expected
4. click the "show more" (comments) button at the end
5. click the flaggers button on one of the comments that was hidden behind the "show more" (comments) button
6. the button does nothing and has no event listenner associated
With this PR:
1. all flaggers buttons work regardless if hidden behind "Show More" (comments) or not. Tested up to two "Show More" (comments) buttons
I did the PR this way because the view_more button calls register_new_elements() and not bottom.js as a whole
There are other things using data-toggleelement like the undelete button on comments and the Preview button on /submit. Both of those still work as expected
Reviewed-on: #111
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>
Aevann
SneedBot
mummified-corroding-granny
chiobu
geese_suck