Fix bug #196

[kaushikpadmanaban]

Fix banner responsivity and add side-scrolling

Bug discussed here

All overflowing elements now resize responsively to screen size

As discussed in #196, this commit solves banner responsivity issues by removing its max-width attribute. In a subsequent comment, it was discussed that the contributor tab needs some fixing. The solution I have implemented here is not as sophisticated as was discussed, but will work without conflicts in the specified screen dimensions.
Once that was done, this was implemented in all further table elements, since they seemed to be malfunctioning too. I have attached relevant GIF:

[ankush]

Not sure if this is a good idea. The bot might overwrite his 🤔

We should try using the config as suggested in the linked issue.

[kaushikpadmanaban]

As for the others, this won't be a problem right? I'll remove the class for contributors table. Moreover, Jekyll is very limiting and the allcontributors configuration gives very few options. Even if we changed the contributorsPerLine to 3 (it is 4 now), the contributors tab will not change dynamically to screen size, but will show 3 per row for all screen sizes, which only looks awkward. I'll revert the ones in the contributors table.

[kaushikpadmanaban]

Please review the final commit when you're available. I am unable to continue since Github on my side is unresponsive. I think I broke it. If it is approved, I will update my fork and try some other options. If you have any other suggestions, please let me know.

Edit: I understand this is not a fix, but a step. I was also wondering if I can add overflow attribute to the table element in CSS. I will look into it and let you know.

[sglavoie]

@kaushikpadmanaban Chiming in to point out that you could wrap the table with a div (so you can give it an id as you did) as long as it's outside the tags generated by all-contributors. See: https://github.com/all-contributors/all-contributors-cli/blob/e9c1f55beb2c18391a5d5f0c9e8243dc3f89ebe3/src/generate/index.js#L5

I don't know what else you wanted to do so hopefully that bit of info is useful to you. 😄

[kaushikpadmanaban]

Thanks for the suggestion @sglavoie! I was thinking about that exactly. I was unable to do that earlier since Github kept crashing. If you don't mind, I will close this pull request and create a new one once I make all the changes. All the commits I make in my fork reflect here and it is getting spammy.

[sglavoie]

@kaushikpadmanaban I don't mind at all whatever way you go! I also see value in keeping everything related to this PR in the same place instead of starting from scratch (similar workflow explained in this article and a visual representation of squashing commits). My reasoning would be as follows:

• As long as you don't force-push on top of your existing commits, what you are doing is clear and feedback can be added incrementally along the way. If the commits have not yet been reviewed, it's not really a bad thing to force-push, rebase and clean up in general depending on the context, like fixing a typo and doing git commit --amend – that's assuming you're doing that in a separate branch no one else is using of course 😄;
• It's easy to just "squash" all your commit into one once all the necessary changes are made before merging into the master/main branch.